[ofa-general] New proposal for memory management
Aaron Fabbri
aafabbri at cisco.com
Fri May 1 11:40:30 PDT 2009
Pavel Shamis (Pasha <pashash <at> gmail.com> writes:
>
> Aaron Fabbri (aafabbri) wrote:
> > 3. Rip out your registration cache. Make malloc'd buffers go really
> > slow (register in fast path) and mpi_alloc_mem() buffers go really fast.
> > People will migrate.
> People will migrate to what ? (A) new malloc ? Or (B) other interconnect
> platform
> that does not require from user to change his application in order to
> get reasonable performance ?
> I'm not sure that people will chose (A)
>
Agreed. As I said, getting all MPIs to agree would be the hard part. Given
that, I think a new malloc() is easier than porting to non-MPI middleware.
My point is this:
- Verbs works well for a number of applications (Roland and I have each written
multiple, for example).
- IMHO, there is a problem with your API that should be fixed (the messaging
layer needs to manage network buf allocation). If you required mpi_alloc_mem,
you would get rid of a whole layer of complicated crap. It may not be feasible
for you, but it is the right thing to do from an engineering perspective,
right?
- "MPI" doesn't want to fix the problem, but instead is asking other people to
make kernel changes for them and saying things like "verbs is broken".
I totally see your guys' problem and feel for you. Either way it comes down to
politics; getting some MPI-specific code into the Linux Kernel (fun?), or
getting MPI users to have to change crusty old scientific code (very fun?).
Could you use the silent corruption problems as leverage to get MPI to move to
mpi_malloc_mem?
Final point I want to make is that this is open source, so you can always try
submitting some elite patches and get the changes you need.
Aaron
More information about the general
mailing list