[Mpi-22] [Mpi-forum] MPI 2.2 proposal: resolving MPI_Request_free issues

[Erez Haba]

I agree with you 100%

On windows pinning down the memory for registration cache is enabled by having a callback from the OS when the memory is actually freed (returned back to the OS); thus enabling the implementation of a safe registration cache with no segv or memory leak.

.Erez

-----Original Message-----
From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Greg Lindahl
Sent: Thursday, July 17, 2008 12:12 PM
To: mpi-22_at_[hidden]
Subject: Re: [Mpi-22] [Mpi-forum] MPI 2.2 proposal: resolving MPI_Request_free issues

On Thu, Jul 17, 2008 at 02:51:10PM -0400, Richard Treumann wrote:

> Also, in most systems support for malloc/free, the free() call does not
> change the ability of the adapter or VMM to modify the status of the
> address range.  The address range that had been exposed to application use
> before the free() is simply added back to the heap and stays there until
> another malloc needs it.

glibc issues individual mmap()s for large allocations. These are
returned to the OS on free. Also, if the top of the heap of small
allocations is all free (rare due to fragmentation), it will sbrk
backwards. Adaptors which have to maintain virt->phys mappings all
struggle with this, in one way or another.

I'm finding this whole discussion confusing. On all of the
interconnects that I'm familiar with, freeing and modifying the buffer
are both unsafe before the wait, and safe after. There's no free
lunch.  Am I not thinking of some important example?

-- greg

_______________________________________________
mpi-22 mailing list
mpi-22_at_[hidden]
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22