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/
--
Brian Barrett
Open MPI developer
http://www.open-mpi.org/
