From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Matt Mackall <mpm@selenic.com>, "Rafael J. Wysocki" <rjw@sisk.pl>,
LKML <linux-kernel@vger.kernel.org>,
Christoph Lameter <clameter@sgi.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]
Date: Sat, 8 Dec 2007 20:52:11 +0100 [thread overview]
Message-ID: <20071208195211.GA3727@elte.hu> (raw)
In-Reply-To: <alpine.LFD.0.9999.0712081034470.12046@woody.linux-foundation.org>
* Linus Torvalds <torvalds@linux-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
next prev parent reply other threads:[~2007-12-08 19:52 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-08 2:40 2.6.24-rc4-git5: Reported regressions from 2.6.23 Rafael J. Wysocki
2007-12-08 6:53 ` Fabio Comolli
2007-12-08 8:28 ` Ingo Molnar
2007-12-08 9:23 ` Andrew Morton
2007-12-08 22:11 ` Rafael J. Wysocki
2007-12-08 9:29 ` Andrew Morton
2007-12-08 22:17 ` Rafael J. Wysocki
2007-12-08 9:30 ` tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52, [2.6.24-rc4-git5: Reported regressions from 2.6.23] Ingo Molnar
2007-12-08 10:11 ` Andrew Morton
2007-12-08 16:37 ` Matt Mackall
2007-12-08 17:47 ` Linus Torvalds
2007-12-08 17:54 ` Linus Torvalds
2007-12-08 18:09 ` Andrew Morton
2007-12-08 18:37 ` Linus Torvalds
2007-12-08 19:52 ` Ingo Molnar [this message]
2007-12-08 20:29 ` Ingo Molnar
2007-12-09 8:20 ` Pekka Enberg
2007-12-09 8:50 ` Ingo Molnar
2007-12-09 9:18 ` Pekka Enberg
2007-12-09 11:51 ` Ingo Molnar
2007-12-09 12:34 ` Ingo Molnar
2007-12-13 22:07 ` Christoph Lameter
2007-12-09 15:59 ` Arjan van de Ven
2007-12-11 6:27 ` Dave Jones
2007-12-11 8:52 ` Ingo Molnar
2007-12-11 19:03 ` Peter Zijlstra
2007-12-14 4:07 ` Christoph Lameter
2007-12-14 7:16 ` Eric Dumazet
2007-12-14 12:49 ` Ingo Molnar
2007-12-17 19:54 ` Christoph Lameter
2007-12-09 7:58 ` Ingo Molnar
2007-12-09 14:17 ` Rafael J. Wysocki
2007-12-08 18:33 ` Matt Mackall
2007-12-08 19:00 ` Matt Mackall
2007-12-09 8:33 ` Pekka Enberg
2007-12-13 22:03 ` Christoph Lameter
2007-12-08 9:36 ` 2.6.24-rc4-git5: Reported regressions from 2.6.23 Andrew Morton
2007-12-08 10:12 ` Andreas Mohr
2007-12-08 10:20 ` Andrew Morton
2007-12-08 10:28 ` Matthew Garrett
2007-12-08 10:55 ` Andreas Mohr
2007-12-09 15:46 ` Tejun Heo
2007-12-09 19:59 ` Andreas Mohr
2007-12-09 6:52 ` Tejun Heo
2007-12-09 14:20 ` Rafael J. Wysocki
2007-12-09 15:11 ` Tejun Heo
2007-12-08 9:42 ` Andrew Morton
2007-12-08 18:57 ` Roland Dreier
2007-12-08 19:40 ` Theodore Tso
2007-12-08 19:55 ` Ingo Molnar
2007-12-08 22:30 ` Rafael J. Wysocki
2007-12-09 2:15 ` Theodore Tso
2007-12-13 10:49 ` Takashi Iwai
2007-12-20 15:42 ` Takashi Iwai
2007-12-08 9:46 ` Andrew Morton
2007-12-08 15:49 ` Alan Stern
2007-12-08 9:52 ` Andrew Morton
2007-12-09 7:00 ` Tejun Heo
2007-12-09 13:42 ` Alan Cox
2007-12-09 15:09 ` Tejun Heo
2007-12-09 15:25 ` Alan Cox
2007-12-09 15:39 ` Tejun Heo
2007-12-09 18:36 ` Linus Torvalds
2007-12-09 21:54 ` Alan Cox
2007-12-09 18:41 ` Linus Torvalds
2007-12-09 22:01 ` Alan Cox
2007-12-09 22:51 ` Ray Lee
2007-12-10 1:57 ` Linus Torvalds
2007-12-10 3:28 ` Alan Cox
2007-12-10 3:38 ` Alan Cox
2007-12-10 15:38 ` Linus Torvalds
2007-12-10 8:21 ` Ingo Molnar
2007-12-10 8:27 ` Tejun Heo
2007-12-10 8:41 ` Ingo Molnar
2007-12-08 10:44 ` Richard Purdie
2007-12-08 22:32 ` Rafael J. Wysocki
2007-12-09 11:54 ` Andrew Morton
2007-12-09 12:05 ` Ingo Molnar
2007-12-09 14:24 ` Rafael J. Wysocki
2007-12-10 20:42 ` Ingo Molnar
2007-12-10 20:57 ` Guillaume Chazarain
2007-12-10 20:59 ` Andrew Morton
2007-12-10 22:45 ` Ingo Molnar
2007-12-10 23:04 ` Ingo Molnar
2007-12-10 23:34 ` Stefano Brivio
2007-12-10 23:53 ` Guillaume Chazarain
2007-12-11 8:48 ` Ingo Molnar
2007-12-10 23:56 ` Arjan van de Ven
2007-12-11 0:01 ` Guillaume Chazarain
2007-12-11 1:06 ` Arjan van de Ven
2007-12-11 8:43 ` Ingo Molnar
2007-12-11 9:01 ` Ingo Molnar
2007-12-11 21:10 ` Stefano Brivio
2007-12-19 0:58 ` Stefano Brivio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071208195211.GA3727@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
--cc=rjw@sisk.pl \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).