In my MTT testing it looks ok, too.
Brad Benton wrote:
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
<brbar...@open-mpi.org <mailto:brbar...@open-mpi.org>> 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
de...@open-mpi.org <mailto:de...@open-mpi.org>
http://www.open-mpi.org/mailman/listinfo.cgi/devel
------------------------------------------------------------------------
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
