On Tue, Dec 4, 2018 at 4:58 PM John Hubbard <jhubbard@xxxxxxxxxx> wrote: > > On 12/4/18 3:03 PM, Dan Williams wrote: > > On Tue, Dec 4, 2018 at 1:56 PM John Hubbard <jhubbard@xxxxxxxxxx> wrote: [..] > > Ok, sorry, I mis-remembered. So, you're effectively trying to capture > > the end of the page pin event separate from the final 'put' of the > > page? Makes sense. > > > > Yes, that's it exactly. > > >> I was not able to actually find any place where a single additional page > >> bit would help our situation, which is why this still uses LRU fields for > >> both the two bits required (the RFC [1] still applies), and the dma_pinned_count. > > > > Except the LRU fields are already in use for ZONE_DEVICE pages... how > > does this proposal interact with those? > > Very badly: page->pgmap and page->hmm_data both get corrupted. Is there an entire > use case I'm missing: calling get_user_pages() on ZONE_DEVICE pages? Said another > way: is it reasonable to disallow calling get_user_pages() on ZONE_DEVICE pages? > > If we have to support get_user_pages() on ZONE_DEVICE pages, then the whole > LRU field approach is unusable. Unfortunately, the entire motivation for ZONE_DEVICE was to support get_user_pages() for persistent memory.
