lkml.org 
[lkml]   [2006]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2.6.17-rc4 1/6] Base support for kmemleak
    Pekka Enberg wrote:
    > On 5/13/06, Catalin Marinas <catalin.marinas@gmail.com> wrote:
    >> This patch adds the base support for the kernel memory leak detector. It
    >> traces the memory allocation/freeing in a way similar to the Boehm's
    >> conservative garbage collector, the difference being that the orphan
    >> pointers are not freed but only shown in /proc/memleak. Enabling this
    >> feature would introduce an overhead to memory allocations.
    >
    > Hmm. How much is the overhead anyway? I am guessing lots so can we
    > reasonably expect anyone to run such kernel?

    The overhead is probably high since an allocated pointer needs to be
    inserted in a radix tree, together with its aliases. However, no-one
    should enable this feature for a production kernel, but only for
    debugging (as with Valgrind for user-space, there isn't anyone using
    those libraries for production versions).

    > Why isn't DEBUG_SLAB_LEAK
    > enough for us?

    I haven't looked at DEBUG_SLAB_LEAK in detail but it looks to me like it
    only shows the calling address of whoever allocated the object. Kmemleak
    detects whether the object is still refered (tracing garbage collection).

    So, DEBUG_SLAB_LEAK should be enough if you suspect a memory leak. If
    you don't, some leaks might go unnoticed.

    Catalin
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-05-14 17:33    [W:3.220 / U:0.112 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site