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? -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
