np...i'll give it another try (and will correspondingly endeavor to mollify
the mercurial gods
as best i can).
On Wed, Jun 11, 2008 at 4:50 PM, Brian W. Barrett <brbarret_at_[hidden]>
> 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,
> On Wed, 11 Jun 2008, Brian Barrett wrote:
> > Did anyone get a chance to test (or think about testing) this? I'd like
> > 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
> >> -lopenmpi-malloc to his link line. Even when standalone and
> >> is not linked in, we'll still intercept munmap as it's needed for
> >> (below) and we've never had any trouble with that part of ptmalloc2
> >> easy to intercept).
> >> As a *CHANGE* in behavior, if leave_pinned support is turned on and
> >> no ptmalloc2 support, we will automatically enable mallopt. As a
> >> in behavior, if the user disables mallopt or mallopt is not available
> >> leave pinned is requested, we'll abort. I think these both make sense
> >> 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
> >> 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
> >> and exists only to allow users to enable mallopt while not building the
> >> ptmalloc2 component at all. Previously, our mallopt support was lacking
> >> that it didn't cover the case where users explicitly called munmap in
> >> 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
> >> 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