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] Memory hooks change testing
From: Brad Benton (bradford.benton_at_[hidden])
Date: 2008-06-11 17:57:54


np...i'll give it another try (and will correspondingly endeavor to mollify
the mercurial gods
as best i can).

thx,
--brad

On Wed, Jun 11, 2008 at 4:50 PM, Brian W. Barrett <brbarret_at_[hidden]>
wrote:

> Brad unfortunately figured out I had done something to annoy the gods of
> mercurial and the repository below didn't contain all the changes
> advertised (and in fact didn't work). I've since rebuilt the repository
> and verified it works now. I'd recommend deleting your existing clones of
> the repository below and starting over.
>
> Sorry about that,
>
> Brian
>
>
> On Wed, 11 Jun 2008, Brian Barrett wrote:
>
> > Did anyone get a chance to test (or think about testing) this? I'd like
> to
> > commit the changes on Friday evening, if I haven't heard any negative
> > feedback.
> >
> > Brian
> >
> > On Jun 9, 2008, at 8:56 PM, Brian Barrett wrote:
> >
> >> Hi all -
> >>
> >> Per the RFC I sent out last week, I've implemented a revised behavior of
> >> the memory hooks for high speed networks. It's a bit different than the
> >> RFC proposed, but still very minor and fairly straight foward.
> >>
> >> The default is to build ptmalloc2 support, but as an almost complete
> >> standalone library. If the user wants to use ptmalloc2, he only has to
> add
> >> -lopenmpi-malloc to his link line. Even when standalone and
> openmpi-malloc
> >> is not linked in, we'll still intercept munmap as it's needed for
> mallopt
> >> (below) and we've never had any trouble with that part of ptmalloc2
> (it's
> >> easy to intercept).
> >>
> >> As a *CHANGE* in behavior, if leave_pinned support is turned on and
> there's
> >> no ptmalloc2 support, we will automatically enable mallopt. As a
> *CHANGE*
> >> in behavior, if the user disables mallopt or mallopt is not available
> and
> >> leave pinned is requested, we'll abort. I think these both make sense
> and
> >> are closest to expected behavior, but wanted to point them out. It is
> >> possible for the user to disable mallopt and enable leave_pinned, but
> that
> >> will *only* work if there is some other mechanism for intercepting free
> >> (basically, it allows a way to ensure your using ptmalloc2 instead of
> >> mallopt).
> >>
> >> There is also a new memory component, mallopt, which only intercepts
> munmap
> >> and exists only to allow users to enable mallopt while not building the
> >> ptmalloc2 component at all. Previously, our mallopt support was lacking
> in
> >> that it didn't cover the case where users explicitly called munmap in
> their
> >> applications. Now, it does.
> >>
> >> The changes are fairly small and can be seen/tested in the HG repository
> >> bwb/mem-hooks, URL below. I think this would be a good thing to push to
> >> 1.3, as it will solve an ongoing problem on Linux (basically, users
> getting
> >> screwed by our ptmalloc2 implementation).
> >>
> >> http://www.open-mpi.org/hg/hgwebdir.cgi/bwb/mem-hooks/
> >>
> >> Brian
> >>
> >> --
> >> Brian Barrett
> >> Open MPI developer
> >> http://www.open-mpi.org/
> >>
> >>
> >
> >
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>