[lkml]   [1999]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: PATCH killing dead code and design errors in pre6
    "David S. Miller" wrote:
    > > the SLAB also keeps caches separated, which (to me) feels better
    > > than what kmalloc could give us anytime. I was always worried
    > > about the multipage allocations done by the SLAB, but this
    > > fragmentation issue seems to be a red herring after all.
    > This isn't true. Do you remember the discussion after it got
    > introduced? There where *plenty* of people crying about exactly
    > this problem.
    > As soon as we forced unconditional reaping at every try_to_free_page()
    > attempt, the majority, if not all, of these problems went away.

    Oh OK I didn't follow it that close.

    > You had TWO YEARS of time to proove it in PRACTICE that it would be
    > usefull and how wonderfull it would perform. However for whichever
    > reasons -- nobody did! Maybe this isn't just accident?
    > It costs one instruction to test a single bit, and this instruction
    > will be there even if you removed ctor/dtor support entirely from SLAB
    > because other feature bits are being checked at the same time in that
    > instruction. So the total cost of this facility is two pointers in an
    > internal structure used by the SLAB subsystem, not more.

    The only second other "feature" bit tested there I see which can't be
    avoided is the distinguishment between slabs for slabs and slabs for
    other things. Many many of the other features are dead as well :-).

    > Andi Kleen, among others, did make good usage of the ctor/dtor
    > facility, but due to other happenings in the areas where he had made
    > his changes at the time, the patches did not go in.
    > I myself have several ideas for using this, but I also am deferring
    > this work to 2.3.x where it belongs.

    So put the whole back into 2.3.x.

    > As for evidence that SLAB in and of itself is faster, look at the
    > change which made SKB's structure part get allocated allocated via a
    > SLAB cache and the data part thru kmalloc(). This increased TCP
    > bandwidth very measurably. At the time, as a test, I turned off
    > SLAB's cache alignment heuristics so that no cache coloring was done
    > at all, the result was that Andi's change made TCP bandwidth worse.
    > (both cases were relatively worse with cache coloring turned off in
    > SLAB, so: 1) Andi's change was relatively worse with SLAB coloring
    > turned off and 2) both cases (with and without Andi's SKB change) were
    > equally relatively worse with coloring off than on... the whole point
    > here is that the coloring scheme of SLAB helped regardless of SKB
    > allocation scheme used, and helps even more so with Andi's change).

    This is mainly prooving that the slab is a faster kmalloc in some places
    It doesn't exclude the possibility to make it even faster and cleaner
    in implementation :-).
    However I have evidently my oppinnions about the usefulness of the
    constructor/destructor concept in respect of the current *fundamental*
    kernel design. The colouring benchmarks I don't beleve until I
    reproduce them myself in a NON ISOLATED environment.

    > If you have the worlds greatest memory allocator for the kernel, then
    > "jak fajnie"! I can't wait to see it. But now is the time for
    > stabilizing what we have, unless you have a drop in replacement which
    > Linus can put in without thinking.

    Eh... David just a hint: I'm not that "durny i naiwny" to claim that I
    like to start from scratch and provide something entiertly new and
    Really no need to get ironic... (however please feel free at ironizing
    my english as much as is deservs :-)
    I already quite like for example the idea of saving passing the structs
    all the way along it's allocation for example!. This way the unavoidable
    second parameter is servig a dual purspose instead of a single one. It
    us at where to get our allocation chunk candidates from as well.

    I would just like do some deeper cleanup in the existing slab.c
    Please take note of the comments about the additional flags usage for
    kmem_create_cache I have put in the patch too. OK?


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

     \ /
      Last update: 2005-03-22 13:49    [W:0.025 / U:6.436 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site