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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 07 2002 - 21:00:34 EST