Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r26106
From: Rolf vandeVaart (rvandevaart_at_[hidden])
Date: 2012-03-09 16:52:59

[Comment at bottom]
>-----Original Message-----
>From: devel-bounces_at_[hidden] [mailto:devel-bounces_at_[hidden]]
>On Behalf Of Nathan Hjelm
>Sent: Friday, March 09, 2012 2:23 PM
>To: Open MPI Developers
>Subject: Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r26106
>On Fri, 9 Mar 2012, Jeffrey Squyres wrote:
>> On Mar 9, 2012, at 1:32 PM, Nathan Hjelm wrote:
>>> An mpool that is aware of local processes lru's will solve the problem in
>most cases (all that I have seen)
>> I agree -- don't let words in my emails make you think otherwise. I think this
>will fix "most" problems, but undoubtedly, some will still occur.
>> What's your timeline for having this ready -- should it go to 1.5.5, or 1.6?
>> More specifically: if it's immanent, and can go to v1.5, then the openib
>message is irrelevant and should not be used (and backed out of the trunk). If
>it's going to take a little bit, I'm ok leaving the message in v1.5.5 for now.
>I wrote the prototype yesterday (after finding that limiting the lru doesn't
>work for uGNI-- @256 pes we could only register ~1400 item instead of the
>3600 max we saw @128). I should have a version ready for review next week
>and a final version by the end of the month.
>BTW, can anyone tell me why each mpool defines
>mca_mpool_base_resources_t instead of defining
>mca_mpool_blah_resources_t. The current design makes it impossible to
>support more than one mpool in a btl. I can delete a bunch of code if I can
>make a btl fall back on the rdma mpool if leave_pinned is not set.

I ran into this same issue about wanting to use more than one mpool in a btl. I expected that there might be a base resource structure that was extended by each mpool. I talked with Jeff and he told me (if I recall correctly) that the reason was because there was no common information in any of the mca_mpool_base_resources_t structures so there was no need to have a base structure. I do not think there is any reason we cannot do it as you suggest.

[The one other place I have seen it done like this in the library is the mca_btl_base_endpoint_t which is defined differently for each BTL]

This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.