[lkml]   [2008]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: hackbench regression since 2.6.25-rc
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


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