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
would
like to start from scratch and provide something entiertly new and
"wonderfull".
Really no need to get ironic... (however please feel free at ironizing
at
my english as much as is deservs :-)
I already quite like for example the idea of saving passing the structs
size
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
hints
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?
--Marcin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/