lkml.org 
[lkml]   [2009]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] SLQB slab allocator
    On Wed, Jan 14, 2009 at 12:01:32PM -0600, Christoph Lameter wrote:
    > On Wed, 14 Jan 2009, Nick Piggin wrote:
    >
    > > Right, but that regression isn't my only problem with SLUB. I think
    > > higher order allocations could be much more damaging for more a wider
    > > class of users. It is less common to see higher order allocation failure
    > > reports in places other than lkml, where people tend to have systems
    > > stay up longer and/or do a wider range of things with them.
    >
    > The higher orders can fail and will then result in the allocator doing
    > order 0 allocs. It is not a failure condition.

    But they increase pressure on the resource and reduce availability to
    other higher order allocations. They accelerate the breakdown of the
    anti-frag heuristics, and they make slab internal fragmentation worse.
    They also simply cost more to allocate and free and reclaim.


    > Higher orders are an
    > advantage because they localize variables of the same type and therefore
    > reduce TLB pressure.

    They are also a disadvantage. The disadvantages are very real. The
    advantage is a bit theoretical (how much really is it going to help
    going from 4K to 32K, if you still have hundreds or thousands of
    slabs anyway?). Also, there is no reason why the other allocators
    cannot use higher orer allocations, but their big advantage is that
    they don't need to.


    > > The idea of removing queues doesn't seem so good to me. Queues are good.
    > > You amortize or avoid all sorts of things with queues. We have them
    > > everywhere in the kernel ;)
    >
    > Queues require maintenance which introduces variability because queue
    > cleaning has to be done periodically and the queues grow in number if NUMA
    > scenarios have to be handled effectively. This is a big problem for low
    > latency applications (like in HPC). Spending far too much time optimizing
    > queue cleaning in SLAB lead to the SLUB idea.

    I'd like to see any real numbers showing this is a problem. Queue
    trimming in SLQB can easily be scaled or tweaked to change latency
    characteristics. The fact is that it isn't a very critical or highly
    tuned operation. It happens _very_ infrequently in the large scheme
    of things, and could easily be changed if there is a problem.

    What you have in SLUB IMO is not obviously better because it effectively
    has sizeable queues in higher order partial and free pages and the
    active page, which simply never get trimmed, AFAIKS. This can be harmful
    for slab internal fragmentation as well in some situations.



    \
     
     \ /
      Last update: 2009-01-15 07:05    [W:3.109 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site