[lkml]   [2011]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: kernel 3.0: BUG: soft lockup: find_get_pages+0x51/0x110
    On Sat, Oct 22, 2011 at 01:52:22PM +0800, Nai Xia wrote:
    > BTW, I am curious about what benchmark did you run and " x10 boost"
    > meaning compared to Hugh's anon_vma_locking fix?

    I was referring to the mremap optimizations I pushed in -mm.

    > This patch and together with the reasoning looks good to me.
    > But I wondering this patch can make the anon_vma chain ordering game more
    > complex and harder to play in the future.

    Well we don't know yet what future will bring... at least this adds
    some documentation on the fact the order matters for
    fork/mremap/migrate/split_huge_page. As far as I can tell they're the
    4 pieces of the VM where the rmap_walk order matters. And
    split_huge_page and migrate are the only two where if the rmap_walk
    fails we can't safely continue and have to BUG_ON.

    > However, if it does bring much perfomance benefit, I vote for this patch
    > because it balances all three requirements here: bug free, performance &
    > no two VMAs stay not merged for no good reason.

    I suppose it should bring an SMP performance benefit as the critical
    section is reduced but we'll have to do some more list_del/add_tail
    than if we take the global lock...

    > Our situation again makes me have the strong feeling that we are really
    > in bad need of a computer aided way to travel all possible state space.
    > There are some guys around me who do automatic software testing research.
    > But I am afraid our problem is too much "real world" for them... sigh...

    Also the code changes too fast for that...

    I'll send the patch again with signoff.

     \ /
      Last update: 2011-10-31 18:59    [W:2.043 / U:37.732 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site