linux-kernel - Re: Major regression on hackbench with SLUB (more numbers)

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]

Message-ID: <Pine.LNX.4.64.0712210818360.29372@schroedinger.engr.sgi.com>
Date:	Fri, 21 Dec 2007 08:26:47 -0800 (PST)
From:	Christoph Lameter <clameter@....com>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Christoph Hellwig <hch@...radead.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: Major regression on hackbench with SLUB (more numbers)

On Fri, 21 Dec 2007, Ingo Molnar wrote:

> and this is not the only regression:
> 
>     http://lkml.org/lkml/2007/10/4/290
> 
> _6%_ TPC-C regression. That's _a lot_ in TPC-C terms.
> 
> and just like in this case there were very clear profiles posted. I 
> proffer, reading back the whole thread, that if you fix hackbench you 
> have fixed TPC-C as well.

There are patches pending to address these issues. AFAICT Intel is 
testing if the regression is still there. There is no way for me to verify what 
is going  on there and there is the constant difficulty of getting 
detailed information about what is going on at Intel. Every couple of 
month I get a result from that test. Its a really crappy situation where a 
lot of confusing information is passed around.

> So i believe you should either send some sensible fixes _NOW_, or admit 
> that the "no queues" NIH nonsense of SLUB doesnt work and do an edible, 
> incremental patchset against SLAB to bring in the debuggability features 
> of SLUB without killing SLAB's performance. (And fix the NUMA alien 
> cache problem along the lines suggested before - perhaps initially by 
> making 'noaliencache' the default bootup option.) And we obviously must 
> revert the default in 2.6.24 to SLAB as well.

The fixes to the alien that you proposed do not work since we would still 
have to check for the need to put the object into alien cache. The checks 
for the locality of each object are the main cause of trouble when freeing 
in SLAB.

SLUB is generally performance wise superior to SLAB as demonstrated by my 
measurements that you reviewed too. In addition SLUB has many improvements 
over SLAB. Its not only the runtime debuggability which would be difficult 
to add since there would be numerous runtime checks in critical code paths 
that would cause regressions.

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