[Top] [All Lists]

Re: I need sk_buff frag_list info.

To: Donald Becker <becker@xxxxxxxxx>
Subject: Re: I need sk_buff frag_list info.
From: Andi Kleen <ak@xxxxxxx>
Date: Thu, 21 Mar 2002 17:42:19 +0100
Cc: netdev@xxxxxxxxxxx
In-reply-to: <Pine.LNX.4.33.0203181202500.967-100000@presario>
References: <> <Pine.LNX.4.33.0203181202500.967-100000@presario>
Sender: owner-netdev@xxxxxxxxxxx
User-agent: Mutt/
On Mon, Mar 18, 2002 at 12:39:37PM -0500, Donald Becker wrote:
> Memory allocators are important for performance, and must be frequently
> re-tuned as systems evolved with new cache structures and memory use.
> Keeping the job of the memory allocator simple is critical, as
> allocators can have a surprisingly bad effect on performance.  Not only
> can they to have much worse performance than their memory access
> count indicates because of cache effects, the resulting cache flushing
> slows down unrelated code in ways that are difficult to measure.

I fully agree. I played with this a few years ago with slab
(you can still see the commented out skb_add_mtu() function in skbuff.c),
but it didn't help much with 4K pages. Now with 8K page sizes becomming
more common that changes of course.

The standard power of two spacing of the slab kmalloc is IMHO very stupid.
I think one of the later slab papers from Sun even noted that power of
two is the worst packing for many cases.
There must be surely a better list of values that would better for
many workloads (not for 1.5K ethernet on 4K, but for other things) 
9k jumbo frames have the same problem unfortunately, you cannot pack
two into a 16K double page, which is always allocated. 
> A bit of history on packet size:

Thanks for the interesting history lesson.


<Prev in Thread] Current Thread [Next in Thread>