Messages in this thread | | | Date | Thu, 13 Mar 2008 23:39:04 -0700 (PDT) | From | Christoph Lameter <> | Subject | Re: hackbench regression since 2.6.25-rc |
| |
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.
> 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.
| |