|| ||Ingo Molnar <mingo-AT-elte.hu>|
|| ||Linus Torvalds <torvalds-AT-linux-foundation.org>|
|| ||Re: tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52,
[2.6.24-rc4-git5: Reported regressions from 2.6.23]|
|| ||Sat, 8 Dec 2007 20:52:11 +0100|
|| ||Andrew Morton <akpm-AT-linux-foundation.org>,
Matt Mackall <mpm-AT-selenic.com>,
"Rafael J. Wysocki" <rjw-AT-sisk.pl>,
Christoph Lameter <clameter-AT-sgi.com>|
* Linus Torvalds <firstname.lastname@example.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
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:
bool "SLUB (Unqueued Allocator)"
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
(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
I think we should we make SLAB the default for v2.6.24 ...
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
to post comments)