On Fri, 21 Dec 2007, Pekka Enberg wrote:

quoted text
> Christoph, did you see Steven's oprofile results for the hackbench
> runs (http://lkml.org/lkml/2007/12/8/198)? Any ideas why we're hitting
> add_partial like crazy?

Hmmm... SLUB is cycling through partial slabs. If it gets fed objects with 
a single free object from the free list again and again then this is the 
behavior that one would see.

The worst case scenario would be.

1. Processor 0 gets slab with one free entry from the partial list. 

2. Processor 0 allocates object and deactivates the slab since it is full.

3. Processor 1 frees the object and finds that it was not on the partial
   list since there were no free objects. Call put_partial()

4. processor 0 gets slab with one free entry from the partial list.

If we would make the partial list a mininum size (which is already done 
through MIN_PARTIAL maybe just increase it) then we may be able to avoid 
this particular case. Also we could make sure that the slab is not put at 
the beginning  of the partial list on free in order to increase the time 
that the slab spends on the partial list. That way it will gather more 
objects before it is picked up.

Hmmmm... This is a bit different from what I got to here.






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