On Wed, Apr 02, 2008 at 03:06:19PM -0700, Christoph Lameter wrote: > On Thu, 3 Apr 2008, Andrea Arcangeli wrote: > > > That would work for #v10 if I remove the invalidate_range_start from > > try_to_unmap_cluster, it can't work for EMM because you've > > emm_invalidate_start firing anywhere outside the context of the > > current task (even regular rmap code, not just nonlinear corner case > > will trigger the race). In short the single threaded approach would be > > But in that case it will be firing for a callback to another mm_struct. > The notifiers are bound to mm_structs and keep separate contexts.
Why can't it fire on the mm_struct where GRU just registered? That mm_struct existed way before GRU registered, and VM is free to unmap it w/o mmap_sem if there was any memory pressure. > You could flush in _begin and free on _end? I thought you are taking a > refcount on the page? You can drop the refcount only on _end to ensure > that the page does not go away before. we're going to lock + flush on begin and unlock on _end w/o refcounting to microoptimize. Free is done by unmap_vmas/madvise/munmap at will. That's a very slow path, inflating the balloon is not problematic. But invalidate_page allows to avoid blocking page faults during swapping so minor faults can happen and refresh the pte young bits etc... When the VM unmaps the page while holding the page pin, there's no race and that's where invalidate_page is being used to generate lower invalidation overhead. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
