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

[Christoph Lameter]

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 
slab".

> 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
> 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.

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/