Re: hackbench regression since 2.6.25-rc

[Christoph Lameter]

On Fri, 14 Mar 2008, Zhang, Yanmin wrote:

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

If you a git pull on the slab-mm branch off my VM tree on kernel.org then
you got all you need. There will be an update in the next days though 
since some of the data you gave me already suggests a couple of ways that
things may be made better.

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

Well the current slab-mm tree already does order 4 and min_objects=60 
which is probably overkill. Next git push on slab-mm will reduce that
to the values you found to be sufficient.
 
> 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.

We would have to do some experiments to see how cpu counts affect multiple 
benchmarks. If we can establish a consistent benefit from varying these
parameters based on processor count then we should do so. There is already
one example in mm/vmstat.c how this could be done.

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