lkml.org 
[lkml]   [2006]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2006-08-11 19:25    [W:0.093 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site