Messages in this thread | | | Date | Fri, 11 Aug 2006 10:21:24 -0700 (PDT) | From | Christoph Lameter <> | Subject | Re: [RFC] Simple Slab: A slab allocator with minimal meta information |
| |
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 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/
| |