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. Cheers, Ben. -- 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
