[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.047 / U:43.492 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site