On 08/15/2011 10:15 AM, Benjamin Herrenschmidt wrote: > On Mon, 2011-08-15 at 10:03 -0500, Scott Wood wrote: >> On 08/13/2011 10:14 AM, Benjamin Herrenschmidt wrote: >>> On Mon, 2011-07-18 at 11:18 -0500, Scott Wood wrote: >>> >>>>> Does this work? Why do we need to set them dirty in the first place? If >>>>> the shared tlb pages are on file backed storage, we're screwed under >>>>> memory pressure either way and they'd just get evicted despite us writing >>>>> to them. Or does vmap pin them? Either way, they're either pinned or not. >>>>> And if they're not, dirtying them here shouldn't really buy us anything, >>>>> no? >>>> >>>> They're pinned by get_user_pages_fast(). We (potentially) write to them, >>>> so >>>> we should mark them dirty, because they are dirty. It's up to the rest >>>> of Linux what to do with that. Will being pinned stop updates from being >>>> written out if it is file-backed? And eventually the vm will be destroyed >>>> (or the tlb reconfigured) and the pages will be unpinned. >>> >>> Note that gup or gup_fast won't guarantee that the virtual->physical >>> mapping remains. >>> >>> IE. the backing page itself will remain around, but it could be broken >>> off the mapping and another page can have taken its place in qemu >>> address space. >>> >>> (Think page migration for example). >> >> How would that work if gup is being used to implement read()? Wouldn't >> the data be written to the wrong place? > > If it drops the mm_sem, I suppose so. You'll have to talk to the vm > folks, they are the ones who warned me against gup.
It seems that migration does check page_count and insist that there be no unexpected references before migrating. See step 7 in Documentation/vm/page_migration. Likewise with swap -- see is_page_cache_freeable() and __remove_mapping(). KVM is already using gup in a very similar way for the guest's memory pages. -Scott -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
