Re: [LSF/MM TOPIC] Un-addressable device memory and block/fs implications

[Dave Hansen <dave.hansen@intel.com>]

On 12/13/2016 01:24 PM, Jerome Glisse wrote:
> 
>>> > > From kernel point of view such memory is almost like any other, it
>>> > > has a struct page and most of the mm code is non the wiser, nor need
>>> > > to be about it. CPU access trigger a migration back to regular CPU
>>> > > accessible page.
>> > 
>> > That sounds ... complex. Page migration on page cache access inside
>> > the filesytem IO path locking during read()/write() sounds like
>> > a great way to cause deadlocks....
> There are few restriction on device page, no one can do GUP on them and
> thus no one can pin them. Hence they can always be migrated back. Yes
> each fs need modification, most of it (if not all) is isolated in common
> filemap helpers.

Huh, that's pretty different from the other ZONE_DEVICE uses.  For
those, you *can* do get_user_pages().

I'd be really interested to see the feature set that these pages have
and how it differs from regular memory and the ZONE_DEVICE memory that
have have in-kernel today.

BTW, how is this restriction implemented?  I would have expected to see
follow_page_pte() or vm_normal_page() getting modified.  I don't see a
single reference to get_user_pages or "GUP" in any of the latest HMM
patch set or the changelogs.

As best I can tell, the slow GUP path will get stuck in a loop inside
follow_page_pte(), while the fast GUP path will allow you to acquire a
reference to the page.  But, maybe I'm reading the code wrong.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>