Messages in this thread | | | Date | Mon, 4 Mar 2002 10:41:38 -0700 | From | "Jeff V. Merkey" <> | Subject | Re: 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" <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/
| |