lkml.org 
[lkml]   [2008]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: EMM: Require single threadedness for registration.
    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.


    \
     
     \ /
      Last update: 2008-04-03 00:19    [from the cache]
    ©2003-2014 Jasper Spaans. Advertise on this site