[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200804182112.40732.nickpiggin@yahoo.com.au>
Date: Fri, 18 Apr 2008 21:12:39 +1000
From: Nick Piggin <nickpiggin@...oo.com.au>
To: "Pekka Enberg" <penberg@...helsinki.fi>
Cc: "Ingo Molnar" <mingo@...e.hu>,
"Andrew Morton" <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
"Linus Torvalds" <torvalds@...ux-foundation.org>,
"Thomas Gleixner" <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
"Vegard Nossum" <vegard.nossum@...il.com>,
"Nick Piggin" <npiggin@...e.de>
Subject: Re: [v2.6.26] what's brewing in x86.git for v2.6.26
On Thursday 17 April 2008 20:42, Pekka Enberg wrote:
> On Thu, Apr 17, 2008 at 1:38 PM, Ingo Molnar <mingo@...e.hu> wrote:
> > > We (still!) have not made the decision whether to proceed with slab or
> > > slub. How hard would it be to port kmemcheck into slab?
> >
> > i think slab is clearly out, unless some catastrophic regression is
> > found. But Nick's SLQB might replace SLUB ;-)
>
> Hey, we all have our favorite replacements for kmalloc():
>
> http://www.kernel.org/pub/linux/kernel/people/penberg/patches/binalloc/2.6.
>25-rc8/kmalloc-binning
>
> But it seems unrealistic to expect any of them to replace SLUB or SLAB
> in the near future.
Obviously that one won't because it is totally unsuitable to replace
SLAB. It may be a good choice to replace SLOB (if it is found to be
technically better). Just the same as SLQB might replace SLAB if it
is found to be technically better. That's (one main criteria for) how
we merge/decide between things.
--
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