Re: [RFC][PATCH] Check write to slab memory which freed already using mudflap

[Nick Piggin <npiggin@suse.de>]

On Fri, Jul 10, 2009 at 12:14:23PM +0300, Pekka Enberg wrote:
> Hi Nick,
> 
> On Fri, 2009-07-10 at 11:03 +0200, Nick Piggin wrote:
> > > And whether SQLB will replace SLUB remains to be seen.
> > > We're still fixing minor issues here and there in SLUB so I have no
> > > reason to expect SLQB stabilization to happen overnight which means
> > > we're going to have SLUB in the tree for a while anyway.
> > 
> > I think it's pretty good now. It was the right thing not to merge
> > it in this window (seeing as I'd forgotten to make it the default
> > in -next). And that flushed out a bug or two. The core logic I
> > think is pretty solid now though.
> 
> The long-standing PowerPC issue is still open, isnt't it? But anyway, my

Yes.


> main point is that we've already seen from the SLAB to SLUB transition
> that while most of the bugs are fixed early on, there's a "fat tail" of
> problems ranging from performance regressions to slab corruption which
> take a long time to be discovered and fixed up.

True.

 
> And I'm not trying to spread FUD on SLQB here, I'm simply stating the
> facts from the previous "slab rewrite" and I have no reason to expect
> this one to go any smoother. OTOH, SLQB has already had exposure in
> linux-next which hopefully makes merging to mainline less painful
> because 95% of the problems are ironed out. But I don't think there's
> much we can do about the remaining 5% that only trigger on weird
> architectures, workloads, or hardware configurations.

Well hopefully most of the correctness problems are sorted out,
but I think (like SLUB) most of the hard problems will be
performance related and trickle in after merge. So I'm not sure
what point we could *remove* other allocators, but for merging
SLQB I think next window should be OK.

What I would like to see is we eventualy make the hard decision
and cull 2 of them. If SLQB is not clearly better (or, if it is
clearly worse) than the other allocators and it can't be improved,
then it has failed my goals for it and I would prefer to remove it
from the tree.

I guess the hard part is how to judge this, and how long to wait
:(