[lkml]   [2010]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 6/8] mm: compaction: Perform a faster scan in try_to_compact_pages()
    On Thu, Nov 18, 2010 at 06:50:46PM +0000, Mel Gorman wrote:
    > For THP in general, I think we can abuse __GFP_NO_KSWAPD. For other callers,
    > I'm not sure it's fair to push the responsibility of async/sync to them. We
    > don't do it for reclaim for example and I'd worry the wrong decisions would
    > be made or that they'd always select async for "performance" and then bitch
    > about an allocation failure.

    Ok, let's leave the __GFP and let's stick to the simplest for now
    without alloc_pages caller knowledge.

    > My only whinge about the lack of reclaimcompact_zone_order is that it
    > makes it harder to even contemplate lumpy compaction in the future but
    > it could always be reintroduced if absolutely necessary.

    Ok. I don't know the plan of lumpy compaction and that's probably why
    I didn't appreciate it...

    So my preference as usual would be to remove lumpy. BTW, everything up
    to patch 3 included should work fine with THP and solve my problem
    with lumpy, thanks!

    > GFP flags would be my last preference.

    yep. I'm just probably too paranoid at being lowlatency in the
    hugepage allocation because I know it's the only spot where THP may
    actually introduce a regression for short lived tasks if we do too
    much work to create the hugepage. OTOH even for short lived allocation
    on my westmire a bzero(1g) runs 250% (not 50% faster like in the older
    hardware I was using) faster just thanks to the page being huge and
    I'm talking about super short lived allocation here (the troublesome
    one if we spend too much time in compaction and reclaim before
    failing). Plus it only makes a difference when hugepages are so spread
    across the whole system and it's still doing purely short lived
    allocations. So again let's worry about the GFP flag later if
    something... this is already an huge latency improvement (very
    appreciated) compared to current upstream even without GPF flag ;)
    like your .ps files show clearly.

     \ /
      Last update: 2010-11-18 20:11    [W:0.020 / U:3.712 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site