lkml.org 
[lkml]   [2008]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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.



\
 
 \ /
  Last update: 2008-03-14 07:43    [W:0.079 / U:1.908 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site