Re: [RFC] Simple Slab: A slab allocator with minimal meta information

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 10 Aug 2006, Manfred Spraul wrote:

> Christoph, could you run a test? GigE routing with tiny packets should be
> sufficient. Two cpu bound nics, one does rx, the other one tx. Move the
> skb_head_cache to sslab.

You are right. The problem is that the simple slab does not do the LIFO 
thing that regular slab does. Instead it services objects from the same 
page until its empty and then it gets a new page (which is very unlikely 
to be cache hot). The cpu caches are necessary in order to effectively
handle objects that still have cachelines in the various processor 
memory caches. So at a minimum we would need a cpucache layer on top of 
simple slab.
 
I still do not get the role of the shared cache though. This from the 
early days of SMP and at that time I thought that all processors had
separate caches? Thus crossfeeding objects could not have too much of a 
benefit. On the other hand NUMA nodes cache series of cachelines when 
going on to the interconnect. The shared cache is useful to track 
the state of objects that are potentially in that cache. Reuse of those
objects would avoid additional cacheline acquisition. The same is true
for multi core. The shared caches provide a kind of state of the shared
caches. Maybe the shared caches need to be configured depending on the
underlying cache architecture?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux