[lkml]   [2010]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH 6/8] mm: handle_speculative_fault()

    On Thu, 7 Jan 2010, Peter Zijlstra wrote:
    > I haven't yet looked at the patch, but isn't expand_stack() kinda like
    > what you want? That serializes using anon_vma_lock().

    Yeah, that sounds like the right thing to do. It is the same operation,
    after all (and has the same effects, especially for the special case of
    upwards-growing stacks).

    So basically the idea is to extend that stack expansion to brk(), and
    possibly mmap() in general.

    Doing the same for munmap() (or shrinking thigns in general, which you can
    do with brk but not with the stack) is quite a bit harder. As can be seen
    by the fact that all the problems with the speculative approach are in the
    unmap cases.

    But the good news is that shrinking mappings is _much_ less common than
    growing them. Many memory allocators never shrink at all, or shrink only
    when they hit certain big chunks. In a lot of cases, the only time you
    shrink a mapping ends up being at the final exit, which doesn't have any
    locking issues anyway, since even if we take the mmap_sem lock for
    writing, there aren't going to be any readers possibly left.

    And a lot of growing mmaps end up just extending an old one. No, not
    always, but I suspect that if we really put some effort into it, we could
    probably make the write-lock frequency go down by something like an order
    of magnitude on many loads.

    Not all loads, no. Some loads will do a lot of file mmap's, or use
    MAP_FIXED and/or mprotect to split vma's on purpose. But that is certainly
    not likely to be the common case.


     \ /
      Last update: 2010-01-07 23:37    [W:0.023 / U:55.372 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site