[lkml]   [2008]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 08 of 11] anon-vma-rwsem
    On Thu, May 08, 2008 at 09:28:38AM +1000, Benjamin Herrenschmidt wrote:
    > On Thu, 2008-05-08 at 00:44 +0200, Andrea Arcangeli wrote:
    > >
    > > Please note, we can't allow a thread to be in the middle of
    > > zap_page_range while mmu_notifier_register runs.
    > You said yourself that mmu_notifier_register can be as slow as you
    > want ... what about you use stop_machine for it ? I'm not even joking
    > here :-)

    We can put a cap of time + a cap of vmas. It's not important if it
    fails, the only useful case we know it, and it won't be slow at
    all. The failure can happen because the cap of time or the cap of vmas
    or the cap vmas triggers or there's a vmalloc shortage. We handle the
    failure in userland of course. There are zillon of allocations needed
    anyway, any one of them can fail, so this isn't a new fail path, is
    the same fail path that always existed before mmu_notifiers existed.

    I can't possibly see how adding a new global wide lock that forces all
    truncate to be serialized against each other, practically eliminating
    the need of the i_mmap_lock, could be superior to an approach that
    doesn't cause the overhead to the VM at all, and only require kvm to
    pay for an additional cost when it startup.

    Furthermore the only reason I had to implement mm_lock was to fix the
    invalidate_range_start/end model, if we go with only invalidate_page
    and invalidate_pages called inside the PT lock and we use the PT lock
    to serialize, we don't need a mm_lock anymore and no new lock from the
    VM either. I tried to push for that, but everyone else wanted
    invalidate_range_start/end. I only did the only possible thing to do:
    to make invalidate_range_start safe to make everyone happy without
    slowing down the VM.

     \ /
      Last update: 2008-05-08 01:47    [W:0.021 / U:18.624 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site