Re: PATCH killing dead code and design errors in pre6

Alan Cox (alan@lxorguk.ukuu.org.uk)
Wed, 13 Jan 1999 18:00:29 +0000 (GMT)


> > The improvements on forwarding performance was the main reason why the slab
> > skb patch was added.
>
> Then why not just maintain a free list inside skbuff.c? Very same like
> all the other parts of the kernel are doing.

No. Thats not what slab is all about. Read the papers.

> > it is possible to avoid the copying of the files array on forking for most cases.
>
> Same again... use a free list.

A free list doesnt do cache optimisations. I think you should read the
papers on SLAB before you do anything more than remove dead constructor
code. Also do you want 300 free lists in the kernel. Then you can write
a vm layer to balance them. Linus just blew away a ton of this kind of mess
in the VM with user pages. Don't reinvent the problems some older BSDs had
with 400 different ways to reclaim mbufs on a bad day.

I'd agree the slab code is messy, I can see the argument for removing the
un-needed constructors and that seems fine, someone can put it back nicely
when they use it. That bit makes sense.

However anyone who blithely throws slab out without doing serious benchmarks
on high end network performance is a fool. Furthermore 2.2 is not the time
to be trying to throw out slab. 2.3 is the time to try and throw it out
by proving you can consistently beat it.

Alan

-
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/