lkml.org 
[lkml]   [1999]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.055 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site