[lkml]   [2006]   [Dec]   [27]   [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

    * Ingo Molnar <> wrote:

    > > As I mentioned in a different e-mail, a way to remove the global
    > > hash table is to create per-cpu hashes. The only problem is that in
    > > these 8-10% of the cases, freeing would need to look up the other
    > > hashes. This would become a problem with a high number of CPUs but
    > > I'm not sure whether it would overtake the performance issues
    > > introduced by cacheline ping-ponging in the single-hash case.
    > i dont think it's worth doing that. So we should either do the current
    > global lock & hash (bad for scalability), or a pure per-CPU design.
    > The pure per-CPU design would have to embedd the CPU ID the object is
    > attached to into the allocated object. If that is not feasible then
    > only the global hash remains i think.

    embedding the info shouldnt be /that/ hard in case of the SLAB: if the
    memleak info is at a negative offset from the allocated pointer. I.e.
    that if kmalloc() returns 'ptr', the memleak info could be at
    ptr-sizeof(memleak_info). That way you dont have to know the size of the
    object beforehand and there's absolutely no need for a global hash of
    any sort.

    (it gets a bit more complex for page aligned allocations for the buddy
    and for vmalloc - but that could be solved by adding one extra pointer
    into struct page. That is a far more preferable cost than the
    locking/cache overhead of a global hash.)

    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-27 18:37    [W:0.022 / U:11.720 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site