[lkml]   [2007]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: SLUB: The unqueued Slab allocator
    From: Christoph Lameter <>
    Date: Fri, 23 Feb 2007 21:47:36 -0800 (PST)

    > On Sat, 24 Feb 2007, KAMEZAWA Hiroyuki wrote:
    > > >From a viewpoint of a crash dump user, this merging will make crash dump
    > > investigation very very very difficult.
    > The general caches already merge lots of users depending on their sizes.
    > So we already have the situation and we have tools to deal with it.

    But this doesn't happen for things like biovecs, and that will
    make debugging painful.

    If a crash happens because of a corrupted biovec-256 I want to know
    it was a biovec not some anonymous clone of kmalloc256.

    Please provide at a minimum a way to turn the merging off.

    I also agree with Andi in that merging could mess up how object type
    local lifetimes help reduce fragmentation in object pools.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-02-24 06:57    [W:0.018 / U:3.696 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site