[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <84144f020901140730l747b4e06j41fb8a35daeaf6c8@mail.gmail.com>
Date: Wed, 14 Jan 2009 17:30:48 +0200
From: "Pekka Enberg" <penberg@...helsinki.fi>
To: "Nick Piggin" <npiggin@...e.de>
Cc: "Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
"Lin Ming" <ming.m.lin@...el.com>,
"Christoph Lameter" <cl@...ux-foundation.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
"Andrew Morton" <akpm@...ux-foundation.org>,
"Linus Torvalds" <torvalds@...ux-foundation.org>
Subject: Re: [patch] SLQB slab allocator
Hi Nick,
On Wed, Jan 14, 2009 at 5:22 PM, Nick Piggin <npiggin@...e.de> wrote:
> And... IIRC, the Intel guys did make a stink but it wasn't considered
> so important or worthwhile to fix for some reason? Anyway, the fact is
> that it hadn't been fixed in SLUB. Hmm, I guess it is a significant
> failure of SLUB that it hasn't managed to replace SLAB by this point.
Again, not speaking for Christoph, but *I* do consider the regression
to be important and I do want it to be fixed. I have asked for a test
case to reproduce the regression and/or oprofile reports but have yet
to receive them. I did fix one regression I saw with the fio benchmark
but unfortunately it wasn't the same regression the Intel guys are
hitting. I suppose we're in limbo now because the people who are
affected by the regression can simply turn on CONFIG_SLAB.
In any case, I do agree that the inability to replace SLAB with SLUB
is a failure on the latter. I'm just not totally convinced that it's
because the SLUB code is unfixable ;).
Pekka
--
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/
Powered by blists - more mailing lists