Re: [RFC] Simple Slab: A slab allocator with minimal meta information
From: Christoph Lameter
Date: Thu Aug 10 2006 - 14:50:24 EST
On Thu, 10 Aug 2006, Manfred Spraul wrote:
> > 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.
Yes that is what I said. SLAB_DESTROY_BY_RCU is RCU applied to the "whole
> Independantly from that point, we need some benchmarks to test the allocator.
Right. This is pretty early for tests though. Its barely functional.
> 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
> 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.
If the overhead of general allocation/free from a slab is reduced then
this effect should not occur. IMHO it may turn out that the need for
the shared array is an artifact of the per cpu caches.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/