Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] Memory hooks change testing
From: Brad Benton (bradford.benton_at_[hidden])
Date: 2008-06-12 10:12:41


Brian,

This is working smoothly now: both the configuration/build and execution.
So,
from my standpoint, it looks good for inclusion into the trunk.

--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
>