I think you'd like to know more than just how many procs are local.
E.g., if the chunk or eager limits are changed much, that would impact
how much memory you'd like to allocate.
A phone chat is all right for me, though so far all I've heard is that
no one understands the code!
But, maybe w
I also know little about that part of the code, but agree that does
seem weird. Seeing as we know how many local procs there are before we
get to this point, I would think we could be smart about our memory
pool size. You might not need to dive into the sm BTL to get the info
you need - if
Ya, that does seem weird to me, but I never fully grokked the whole
mpool / allocator scheme (I haven't had to interact with that part of
the code much).
Would it be useful to get on the phone and discuss this stuff?
On Jan 14, 2009, at 1:11 AM, Eugene Loh wrote:
Thanks for the reply. I
Thanks for the reply. I kind of understand, but it's rather weird. The
BTL calls mca_mpool_base_module_create() to create a pool of memory, but
the BTL has no say how big of a pool to create? Could you imagine
having a memory allocation routine ("malloc" or something) that didn't
allow you t
The simple answer is you can't. The mpool is loaded before the BTLs
and on Linux the loader use the RTLD_NOW flag (i.e. all symbols have
to be defined or the dlopen call will fail).
Moreover, there is no way in Open MPI to exchange information between
components except a global variable or
With the sm BTL, there is a file that each process mmaps in for shared
memory.
I'm trying to get mpool_sm to size the file appropriately. So, I would
like mpool_sm to call some mca_btl_sm function that provides a good
guess of the size. (mpool_sm creates and mmaps the file, but the size
dep
