On 12/13/2016 01:24 PM, Jerome Glisse wrote:

quoted

quoted

quoted

quoted

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.