Re: Gigabit Performance 2.4.19-preX - Excessive locks, calls, waits

["Jeff V. Merkey" <jmerkey@vger.timpanogas.org>]

On Mon, Mar 04, 2002 at 09:28:21AM +0100, Andi Kleen wrote:
> "Jeff V. Merkey" <jmerkey@vger.timpanogas.org> writes:
> 
> > /usr/src/linux/net/core/skbuff.c
> > 
> > //int sysctl_hot_list_len = 128;
> > int sysctl_hot_list_len = 1024;  // bump this value up
> > 
> 
> The plan was to actually to get rid of the skb hot list. It was just 
> a stop gap solution to get CPU local smp allocation before Linux had
> cpu local slab caches. The slab cache has been fixed and runs 
> cpu local now too, so there should be no need for it anymore as 
> the slab cache does essentially the same thing as the private hot list
> cache (maintaining linked lists of objects and unlinking them quickly
> on allocation and linking them again on free, all in O(1)) 
> 
> 
> > alloc_skb_frame with fixed 1514 + fragment list allocations, 
> > sysctl_hot_list_len = 1024.  
> 
> Something is bogus with your profile data. Increasing sysctl_hot_list_len
> never changes the frequency with which kmalloc/kfree are called. All
> it does is to produce less calls to kmem_cache_alloc() for the skb head,
> but the skb data portion is always allocated using kmalloc().  Your 
> new profile doesn't show kmalloc so you changed something else.
> 
> 
> -andi

Agree.  What's making the numbers get better is the fact I have 
removed calls to kmalloc/kfree in alloc_akb.  This extra code path
increases latency in these high speed adapters.  Reread the post.  I 
said changing the hot list eliminated a lot of packet overruns, not
calls to kmalloc/kfree.  The data is correct.

Jeff