linux-kernel - Re: [patch] SLQB slab allocator (try 2)

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:	Mon, 16 Feb 2009 19:41:57 +0000
From:	Mel Gorman <mel@....ul.ie>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	Nick Piggin <nickpiggin@...oo.com.au>,
	Nick Piggin <npiggin@...e.de>,
	Linux Memory Management List <linux-mm@...ck.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Lin Ming <ming.m.lin@...el.com>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Christoph Lameter <cl@...ux-foundation.org>
Subject: Re: [patch] SLQB slab allocator (try 2)

On Mon, Feb 16, 2009 at 09:17:58PM +0200, Pekka Enberg wrote:
> Hi Mel,
>
> Mel Gorman wrote:
>> I haven't done much digging in here yet. Between the large page bug and
>> other patches in my inbox, I haven't had the chance yet but that doesn't
>> stop anyone else taking a look.
>
> So how big does an improvement/regression have to be not to be  
> considered within noise? I mean, I randomly picked one of the results  
> ("x86-64 speccpu integer tests") and ran it through my "summarize"  
> script and got the following results:
>
> 		min      max      mean     std_dev
>   slub		0.96     1.09     1.01     0.04
>   slub-min	0.95     1.10     1.00     0.04
>   slub-rvrt	0.90     1.08     0.99     0.05
>   slqb		0.96     1.07     1.00     0.04
>

Well, it doesn't make a whole pile of sense to get the average of these ratios
or the deviation between them. Each of the tests behave very differently. I'd
consider anything over 0.5% significant but I also have to admit I wasn't
doing multiple runs this time due to the length of time it takes. In a
previous test, I ran them 3 times each and didn't spot large deviations.

> Apart from slub-rvrt (which seems to be regressing, interesting) all the  
> allocators seem to perform equally well. Hmm?
>

For this stuff, they are reasonably close but I don't believe thye are
allocator intensive either. SPEC CPU was brought up as a workload HPC people
would care about. Bear in mind it's also not testing NUMA or CPU scalability
really well. It's one data-point. netperf is a much more allocator intensive
workload.

> Btw, Yanmin, do you have access to the tests Mel is running (especially  
> the ones where slub-rvrt seems to do worse)? Can you see this kind of  
> regression? The results make we wonder whether we should avoid reverting  
> all of the page allocator pass-through and just add a kmalloc cache for  
> 8K allocations. Or not address the netperf regression at all. Double-hmm.
>

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
--
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/