On Wed, 14 May 2008, Andi Kleen wrote:

quoted text
> iirc profiling analysis showed that the problem was the page lock
> serialization (in particular the slab_lock() in __slab_free). That
> was on 2.6.24.2

Do you have an URL?

quoted text
> I think the problem is that this atomic operation thrashes cache lines
> around. Really counting cycles on instructions is not that interesting,
> but minimizing the cache thrashing is. And for that it looks like slub
> is worse.

It can thrash cachelines if objects from the same slab page are freed 
simultaneously on multiple processors. That occurred in the hackbench 
regression that we addressed with the dynamic configuration of slab sizes.

However, typically long lived objects freed from multiple processors 
belong to different slab caches.

quoted text
> > So I think that the free need to  stay as is. The disadvantages in terms 
> > of the complexity of handling the objects and expiring them and the issue 
> > of having to take per node locks in SLAB makes it hard to justify adding a 
> > queue for free in SLUB. Maybe someone has an inspiration on how to do this 
> > effective that is better than my attempts which always ultimately ended 
> > implementing code that thad the same issues that we have in SLAB.
> 
> What is the big problem of having a batched free queue? If the expiry
> is done at a good bounded time (e.g. on interrupt exit or similar)
> locally on the CPU it shouldn't be a big issue, should it?

Interrupt exit in general would have to inspect the per cpu structures of 
all slab caches on the system?
--
unsubscribe notice
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/