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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>