Messages in this thread | | | Date | Wed, 13 Jan 1999 12:05:25 -0800 | From | "David S. Miller" <> | Subject | Re: PATCH killing dead code and design errors in pre6 |
| |
Date: Wed, 13 Jan 1999 20:27:17 +0100 From: Marcin Dalecki <dalecki@cs.net.pl>
> 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.
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.
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.
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).
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.
Later, David S. Miller davem@dm.cobaltmicro.com
- 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/
| |