[lkml]   [2006]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2.6.20-rc1 00/10] Kernel memory leak detector 0.13

    * Catalin Marinas <> wrote:

    > On 17/12/06, Ingo Molnar <> wrote:
    > >one more thing: after bootup i need to access the /debug/memleak file
    > >twice to get any output from it - is that normal? The first 'cat
    > >/debug/memleak' gives no output (but there's the usual scanning
    > >delay, so memleak does do its work).
    > Yes, this is normal. Especially on SMP, I get some transient reports,
    > probably caused by pointers hold in registers (even more visible on
    > ARM due to the bigger number of registers per CPU). Reporting a leak
    > only if it was seen at least once before greatly reduces the false
    > positives (this is configurable as well but I'll drop the
    > configuration option). Without this, you could see that, at every
    > scan, the reported pointers are different.
    > Some people testing kmemleak used to read the /debug/memleak file
    > periodically from a script and this wasn't noticeable. It would be
    > even better if, as you suggested, I schedule a periodic memory
    > scanning.

    yeah. You could also use the allocation timestamp to exclude too young
    entries. (if something really leaked then it will be a leak in 10
    minutes too)

    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: 2006-12-17 14:33    [W:0.021 / U:95.348 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site