lkml.org 
[lkml]   [2008]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 08 of 11] anon-vma-rwsem
    On Wed, May 07, 2008 at 06:57:05PM -0700, Linus Torvalds wrote:
    > Take five minutes. Take a deep breadth. And *think* about actually reading
    > what I wrote.
    >
    > The bitflag *can* prevent taking the same lock twice. It just needs to be
    > in the right place.

    It's not that I didn't read it, but to do it I've to grow every
    anon_vma by 8 bytes. I thought it was implicit that the conclusion of
    your email is that it couldn't possibly make sense to grow the size of
    each anon_vma by 33%, when nobody loaded the kvm or gru or xpmem
    kernel modules. It surely isn't my preferred solution, while capping
    the number of vmas to 1024 means sort() will make around 10240 steps,
    Matt call tell the exact number. The big cost shouldn't be in
    sort. Even 512 vmas will be more than enough for us infact. Note that
    I've a cond_resched in the sort compare function and I can re-add the
    signal_pending check. I had the signal_pending check in the original
    version that didn't use sort() but was doing an inner loop, I thought
    signal_pending wasn't necessary after speeding it up with sort(). But
    I can add it again, so then we'll only fail to abort inside sort() and
    we'll be able to break the loop while taking all the spinlocks, but
    with such as small array that can't be an issue and the result will
    surely run faster than stop_machine with zero ram and cpu overhead for
    the VM (besides stop_machine can't work or we'd need to disable
    preemption between invalidate_range_start/end, even removing the xpmem
    schedule-inside-mmu-notifier requirement).


    \
     
     \ /
      Last update: 2008-05-08 04:27    [W:4.166 / U:0.724 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site