Re: hackbench regression since 2.6.25-rc

["Zhang, Yanmin" <yanmin_zhang@linux.intel.com>]

On Thu, 2008-03-13 at 23:39 -0700, Christoph Lameter wrote:
> On Fri, 14 Mar 2008, Zhang, Yanmin wrote:
> 
> > On tigerton, if I add "slub_max_order=3 slub_min_objects=16" to kernel 
> > boot cmdline, the result is improved significantly and it takes just 
> > 1/10 time of the original testing.
> 
> Hmmm... That means the updates to SLUB in mm will fix the regression that 
> you are seeing because we there can use large orders of slabs and fallback
> for all slab caches. But I am still interested to get to the details of
> slub behavior on the 16p.
> 
> > So kmalloc-512 is the key.
> 
> Yeah in 2.6.26-rc kmalloc-512 has 8 objects per slab. The mm version 
> increases that with a larger allocation size.
Would you like to give me a pointer to the patch? Is it one patch, or many patches?

> 
> > Then, I tested it on stoakley with the same kernel commandline. 
> > Improvement is about 50%. One important thing is without the boot 
> > parameter, hackbench on stoakey takes only 1/4 time of the one on 
> > tigerton. With the boot parameter, hackbench on tigerton is faster than 
> > the one on stoakely.
> > 
> > Is it possible to initiate slub_min_objects based on possible cpu 
> > number? I mean, cpu_possible_map(). We could calculate slub_min_objects 
> > by a formular.
> 
> Hmmm... Interesting. Lets first get the details for 2.6.25-rc. Then we can 
> start toying around with the slub version in mm to configure slub in such 
> a way that we get best results on both machines.
Boot parameter "slub_max_order=3 slub_min_objects=16" could boost perforamnce
both on stoakley and on tigerton.

So should we keep slub_min_objects scalable based on possible cpu number? When a
machine has more cpu, it means more processes/threads will run on it and it will
take more time when they compete for the same resources. SLAB is such a typical
resource.

-yanmin