[lkml]   [2005]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH RT 00/02] SLOB optimizations

    * Pekka J Enberg <penberg@cs.Helsinki.FI> wrote:

    > > SLAB-bashing has become somewhat fashionable, but i really challenge
    > > everyone to improve the SLAB code first (to make it more modular, easier
    > > to read, etc.), before suggesting replacements.
    > I dropped working on the replacement because I wanted to do just that.
    > I sent my patch only because Matt and Steve talked about writing a
    > replacement and thought they would be interested to see it.
    > I am all for gradual improvements but after taking a stab at it, I
    > starting to think rewriting would be easier, simply because the slab
    > allocator has been clean-up resistant for so long.

    i'd suggest to try harder, unless you think the _fundamentals_ of the
    SLAB allocator are wrong. (which you are entitled to believe, but we
    also have to admit that the SLAB has been around for many years, and
    works pretty well)

    most of the ugliness in slab.c comes from:

    1) debugging. There's no easy solutions here, but it could be improved.

    2) bootstrapping. Bootstrapping an allocator in a generic way is hard.
    E.g. what if cache_cache gets larger than 1 page?

    3) cache-footprint tricks and lockless fastpath. SLAB does things all
    the right way, even that ugly memmove is the right thing. Maybe it
    could be cleaned up, but the fundamental complexity will likely

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-12-21 08:53    [W:0.036 / U:14.116 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site