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

[Manfred Spraul <manfred@colorfullife.com>]

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.

--
   Manfred
-
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/