[lkml]   [2009]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH] Check write to slab memory which freed already using mudflap
    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
    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.

    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.

    But I think we've been in agreement on this with Nick in the past. So I
    guess my rant is directed towards Ingo who seems to be bit too eager to
    merge SLQB and rm mm/sl{a,u}b.c :-).


     \ /
      Last update: 2009-07-10 11:17    [W:0.020 / U:1.308 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site