[lkml]   [2002]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Gigabit Performance 2.4.19-preX - Excessive locks, calls, waits
On Mon, Mar 04, 2002 at 09:28:21AM +0100, Andi Kleen wrote:
> "Jeff V. Merkey" <> 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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