linux-kernel - Re: tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52, [2.6.24-rc4-git5: Reported regressions from 2.6.23]

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: <20071208195211.GA3727@elte.hu>
Date:	Sat, 8 Dec 2007 20:52:11 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Matt Mackall <mpm@...enic.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	LKML <linux-kernel@...r.kernel.org>,
	Christoph Lameter <clameter@....com>
Subject: Re: tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52,
	[2.6.24-rc4-git5: Reported regressions from 2.6.23]

* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> > But I don't think we need to do anything for 2.6.24..
> 
> Good. Although we should perhaps look at that reported performance 
> problem with SLUB. It looks like SLUB will do a memclear() for the 
> area twice (first for the whole page, then for the thing it allocated) 
> for the slow case. Maybe that exacerbates the problem.

i dont think the SLUB problem could be explained purely via a double 
memset(). [which ought to be extremely fast anyway] We are talking about 
a 10 times slowdown on a 64-way box of a workload that is fairly 
common-sense. (tasks sending messages to each other via bog standard 
means)

while i dont want to jump to conclusions without looking at some 
profiles, i think the SLUB performance regression is indicative of the 
following fallacy: "SLAB can be done significantly simpler while keeping 
the same performance".

I couldnt point to any particular aspect of SLAB that i could 
characterise as "needless bloat".

the SLUB concept is proudly outlined in init/Kconfig:

  config SLUB
        bool "SLUB (Unqueued Allocator)"
        help
           SLUB is a slab allocator that minimizes cache line usage
           instead of managing queues of cached objects (SLAB approach).
           Per cpu caching is realized using slabs of objects instead
           of queues of objects. SLUB can use memory efficiently
           and has enhanced diagnostics.

but that's not true anymore - the two concepts are pretty much 
equivalent, after all the "performance tuning" that went on in SLUB. 
(read: 'frantically try to catch up with SLAB in benchmarks')

so even today's upstream kernel, which has 'ancient' SLUB code, SLAB and 
SLUB have essentially the same linecount:

  $ wc -l mm/slab.c mm/slub.c
  4478 mm/slab.c
  4125 mm/slub.c

(and while linecount != complexity, there is a strong relationship.)

With SLAB having 10 years more test coverage and tuning.

the messiest and most fragile aspect of SLAB that i can think of is its 
bootstrap hacks - but that is an entirely unimportant detail in my 
opinion. SLAB has been cleaned up significantly in the past few years by 
Pekka Enberg & co, it's pretty pleasant and straightforward code these 
days.

I think we should we make SLAB the default for v2.6.24 ...

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