Messages in this thread | | | Subject | Re: [patch 3/3] mm: fault handler to replace nopage and populate | From | Benjamin Herrenschmidt <> | Date | Mon, 09 Oct 2006 22:07:50 +1000 |
| |
On Mon, 2006-10-09 at 13:58 +0200, Nick Piggin wrote: > On Mon, Oct 09, 2006 at 09:49:31PM +1000, Benjamin Herrenschmidt wrote: > > On Mon, 2006-10-09 at 13:45 +0200, Nick Piggin wrote: > > > On Mon, Oct 09, 2006 at 09:32:59PM +1000, Benjamin Herrenschmidt wrote: > > > > > > > > > > You'll want to clear VM_PFNMAP after unmapping all pages from it, before > > > > > switching to struct page backing. > > > > > > > > Which means having a list of all vma's ... I suppose I can look at the > > > > truncate code to do that race free but I was hoping I could avoid it > > > > (that's the whole point of using unmap_mapping_range() in fact). > > > > > > Yeah I don't think there is any other way to do it. > > > > What is the problem if I always keep VM_PFNMAP set ? > > The VM won't see that you have struct pages backing the ptes, and won't > do the right refcounting or rmap stuff... But for file backed mappings, > all the critical rmap stuff should be set up at mmap time, so you might > have another option to simply always do the nopfn thing, as far as the > VM is concerned (ie. even when you do have a struct page)
Any reason why it wouldn't work to flip that bit on the first no_page() after a migration ? A migration always involves destroying all PTEs and is done with a per-object mutex held that no_page() takes too, so we can be pretty sure that the first nopage can set that bit before any PTE is actually inserted in the mapping after all the previous ones have been invalidated... That would avoid having to walk the vma's.
Ben.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |