[ofa-general] Re: New proposal for memory management

Jeff Squyres jsquyres at cisco.com
Thu Apr 30 06:52:32 PDT 2009


I think Jason is the only one who is remaining at least somewhat on- 
topic here.

My goal for this thread was to open discussion about solving the  
broken memory management model for OpenFabrics.  Specifically, I'm  
looking for a software solution for today's hardware (both IB and  
iWARP).

While MPI is currently the biggest victim, this broken memory  
management model is also an enormous roadblock for any other  
application or ULP to write to verbs.

On-demand paging, while the desired end result sounds great, will  
definitely require new hardware and will likely be a very complex  
design conversation that takes a long, long time.  That's great if my  
proposal [finally] seriously inspires people to tackle this problem  
(and/or other hardware-assisted ideas), but I consider those to be  
longer-term solutions.

I'm looking for a) a much shorter-term solution that is b) workable on  
current hardware.

Thanks.


On Apr 29, 2009, at 6:44 PM, Jason Gunthorpe wrote:

> On Wed, Apr 29, 2009 at 03:28:00PM -0700, Ralph Campbell wrote:
>
> > Besides, mmap() only allocates a virtual address range in the user's
> > address space. It doesn't fault in all the pages into physical  
> memory.
> > That happens when the application tries to read or write memory in
> > the VA range of the mmap. The IB memory registrations need physical
> > addresses and it would be impractical to do this for every mmap or
> > brk.
>
> If your goal is to keep the mr consistent then you only need to fault
> and pin pages from the new mmap that intersect with pre-existing
> memory registrations.
>
> I chucked out 3 things to consider:
>  - Pin and register all process memory (no swap!)
>  - Keep the MR consistent by pinning and registering new mmaps
>    that intersect with pre-existing memory registrations
>  - Keep the MR consistent by preventing the kernel from returning
>    new mmaps that overlap existing memory registrations.
>
> Jason
>


-- 
Jeff Squyres
Cisco Systems




More information about the general mailing list