[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <06A5381F-9D03-4854-ABEB-B2025620E379@Sun.COM>
Date: Wed, 14 Apr 2010 07:18:20 +0200
From: Håkon Bugge <Haakon.Bugge@....COM>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Roland Dreier <rdreier@...co.com>,
Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Eric B Munson <ebmunson@...ibm.com>,
linux-kernel@...r.kernel.org, linux-rdma@...r.kernel.org,
rolandd@...co.com, pavel@....cz, mingo@...e.hu, jsquyres@...co.com
Subject: Re: [PATCH] ummunotify: Userspace support for MMU notifications
On Apr 13, 2010, at 20:02 , Peter Zijlstra wrote:
>
> Yeah, virtual<->physical maps can change through swapping, page
> migration, memory compaction, huge-page aggregation (the latter two not
> yet being upstream).
Assuming this holds true, RDMA will not work. And with no RDMA, we do not need ummunotify. Is that your argument?
Seriously, RDMA requires the virtual to physical mapping to remain constant for a period of time. And that time period is from memory registration to de-registration. If the virtual to physical mapping changes in that period for the registered memory area, I can't see how an HCA can handle that.
For MPI applications, the MPI API defines that the buffers used in communication cannot be changed or freed while a non-blocking transfer is in progress. So far, we are good. But memory registration (and in particular de-registration) is a costly process. Since MPI is about performance, the MPI library would like to re-use earlier memory registrations for other transfers. The MPI library records earlier memory mappings (VA+bound) and checks if the VA+bound of a new transfer is already contained in memory revisions registered earlier.
The problem with this approach is that _normal_ activity _between_ the transfers changes the virtual to physical mapping and ruins previous memory registrations. The problem is to catch these. I simply argue that they should be caught the simplest possible way; a call-back from the system calls affecting the virtual to physical mapping.
>
> Even mlock() doesn't pin virtual<->physical maps.
Can you elaborate on what you mean here?
Thanks, Håkon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists