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

    * Catalin Marinas <catalin.marinas@gmail.com> wrote:

    > On 17/12/06, Ingo Molnar <mingo@elte.hu> 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)

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