Messages in this thread | | | Subject | Re: hackbench regression since 2.6.25-rc | From | "Zhang, Yanmin" <> | Date | Fri, 14 Mar 2008 15:29:01 +0800 |
| |
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
| |