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> 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 > http://www.open-mpi.org/mailman/listinfo.cgi/devel >
