Messages in this thread | | | Date | Fri, 10 Jul 2009 11:29:21 +0200 | From | Nick Piggin <> | Subject | Re: [RFC][PATCH] Check write to slab memory which freed already using mudflap |
| |
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 :(
| |