[lkml]   [2010]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC V2 SLEB 00/14] The Enhanced(hopefully) Slab Allocator
    On Tue, May 25, 2010 at 08:02:32PM +0300, Pekka Enberg wrote:
    > Hi Nick,
    > On Tue, May 25, 2010 at 6:43 PM, Nick Piggin <> wrote:
    > > As far as I can see, there was never a good reason to replace SLAB
    > > rather than clean up its code and make incremental improvements.
    > I'm not totally convinced but I guess we're about to find that out.
    > How do you propose we benchmark SLAB while we clean it up

    Well the first pass will be code cleanups, bootstrap simplifications.
    Then looking at what debugging features were implemented in SLUB but not
    SLAB and what will be useful to bring over from there.

    At this point the aim would be for actual allocation behaviour with
    non-debug settings to be unchanged. Hopefully this removes everyone's
    (apparently) largest gripe that code is crufty.

    Next would be to add some options to tweak queue sizes and disable
    cache reaping at runtime, for the benfit of the low jitter crowd,
    see if any further hotplug fixes are required.

    Then would be to propose incremental improvements to actual algorithm.
    For example, replacing the alien cache crossbar with a lighter weight
    or more scalable structure.

    > and change
    > things to make sure we don't make the same mistakes as we did with
    > SLUB (i.e. miss an important workload like TPC-C)?

    Obviously it is impossible to make forward progress and also catch
    all regressions before release. This fact means that we have to be
    able to cope with them as well as possible.

    We get two benefits from starting with SLAB. Firstly, we get a larger
    testing base. Secondly, we get a simple (ie. git revert) formula of how
    to get from good behaviour to bad behaviour.

    I don't anticipate a huge number of functional changes to SLAB here
    though. It's surprisingly hard to do better than it. alien caches are
    one area, maybe configurable higher order allocation support, jitter

    If we do get a big proposed change in the pipeline, then we have to
    eat it somehow, but AFAIKS we've still got a better foundation than
    starting with a completely new allocator and feeling around in the
    dark trying to move it past SLAB in terms of performance.

     \ /
      Last update: 2010-05-25 19:23    [W:0.020 / U:9.896 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site