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 14:05:20 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.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 Fri, 14 Mar 2008, Zhang, Yanmin wrote:

> > 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?

If you a git pull on the slab-mm branch off my VM tree on kernel.org then
you got all you need. There will be an update in the next days though 
since some of the data you gave me already suggests a couple of ways that
things may be made better.

> > 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.

Well the current slab-mm tree already does order 4 and min_objects=60 
which is probably overkill. Next git push on slab-mm will reduce that
to the values you found to be sufficient.

> 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.

We would have to do some experiments to see how cpu counts affect multiple 
benchmarks. If we can establish a consistent benefit from varying these
parameters based on processor count then we should do so. There is already
one example in mm/vmstat.c how this could be done.

--
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/