In my MTT testing it looks ok, too.
Brad Benton wrote:
> This is working smoothly now: both the configuration/build and
> execution. So,
> from my standpoint, it looks good for inclusion into the trunk.
> On Wed, Jun 11, 2008 at 4:50 PM, Brian W. Barrett
> <brbarret_at_[hidden] <mailto: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
> 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 to
> > commit the changes on Friday evening, if I haven't heard any
> > 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
> >> standalone library. If the user wants to use ptmalloc2, he
> only has to add
> >> -lopenmpi-malloc to his link line. Even when standalone and
> >> 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
> >> 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] <mailto:devel_at_[hidden]>
> devel mailing list