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

From: Manfred Spraul
Date: Thu Aug 10 2006 - 14:46:01 EST

Christoph Lameter wrote:

On Thu, 10 Aug 2006, KAMEZAWA Hiroyuki wrote:

BTW, in recent Linux, many objects are freed by call_rcu(hoo, dealyed_free_foo).
Objects are freed far after it was touched.
I think catching this kind of freeing will not boost performance by cache-hit if
reuse freed page (object).

Yes that is a general problem with RCU freeing. One can use the SLAB_DESTROY_BY_RCU option to have RCU applied to the whole slab. In that case on can use the cache hot effect but has the additional problem in RCU of dealing with the issue that the object can be replaced at any time.

No SLAB_DESTROY_BY_RCU is not equivalent to delayed_free_foo().
SLAB_DESTROY_BY_RCU just means that the slab allocator uses delayed_free_pages() instead of free_pages().
kmem_cache_free() does not delay the reuse, an object will be returned by the next kmem_cache_alloc, without any grace periods in between.

Independantly from that point, we need some benchmarks to test the allocator.

The last benchmarks of the slab allocator (that I'm aware of) were done with packet routing - packet routing was the reason why the shared_array layer was added:
The shared_array layer is used to perform inter-cpu bulk object transfers. Without that cache, i.e. if a list_add() / list_del() was required to transfer one object from one cpu to another cpu, a significant amount of time was spent in the allocator.

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at