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
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).
> Brian Barrett
> Open MPI developer
Open MPI developer