Messages in this thread | | | Date | Fri, 14 Mar 2008 14:05:20 -0700 (PDT) | From | Christoph Lameter <> | Subject | Re: hackbench regression since 2.6.25-rc |
| |
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.
| |