Re: [PATCH 2.6.17-rc4 1/6] Base support for kmemleak

[Catalin Marinas <catalin.marinas@gmail.com>]

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