linux-kernel - Re: hackbench regression since 2.6.25-rc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 14 Mar 2008 15:29:01 +0800
From:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
To:	Christoph Lameter <clameter@....com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Kay Sievers <kay.sievers@...y.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>
Subject: Re: 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
resource.

-yanmin


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/