Re: Notebooks

Andi Kleen (ak@muc.de)
Wed, 19 Aug 1998 07:17:59 +0200

On Wed, Aug 19, 1998 at 06:40:40AM +0200, Linus Torvalds wrote:
> What really worries me is the slab stuff. I applied the diffs quite some
> time ago when David had integrated the "slabification" of the networking
> layer, but only today when I was chasing down this bug did I notice what
> really bad things it does. Not only does it use bigger page-orders than
> necessary, but the networking slabification in particular resulted in the
> fact that when you allocate a skb you now do _two_ allocations.
>
> It used to be that we did one variable-length allocation that contained
> both the skb head and the actual data. But the slab code cannot handle
> variable-length allocations, so when somebody slabified it, they changed
> it to allocate the data separately. As such, the thing just slowed down,
> even though the whole intent of the slabs was to speed things up.

In my benchmarks it is a win. If you have hard numbers that show otherwise
I would be interested to see them.

> I really don't see the point there. It's slower, more complex, and uses
> more memory. Somebody please tell me why I shouldn't just get rid of it
> and revert to the old kmalloc(), which we know is stable and has none of
> these misfeatures?

I implemented that. In practice it is a big win - in Alexey's high speed router
the packet switch rate increased by upto 10% compared to the old skbuff
allocator. On my machine localhost tcp transfer rates increase too.

I believe this is due to increased cache hit rates and overall simplification
of the code. Also the header allocation is cheap because this path is very
fast in slab.

Also skb_clone() is a lot nicer now compared to the old mess (and compared
to 2.0 skb_clone is much more speed critical in TCP)

-Andi

-
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.altern.org/andrebalsa/doc/lkml-faq.html