Re: [PATCH 2.6.20-rc1 00/10] Kernel memory leak detector 0.13

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 18/12/06, Ingo Molnar <[email protected]> wrote:

* Catalin Marinas <[email protected]> wrote:

> >at freeing we only have to look up the tree belonging to object->cpu.
>
> At freeing, kmemleak only gets a pointer value which has to be looked
> up in the hash table for the corresponding memleak_object. Only after
> that, we can know memleak_object->cpu. That's why I think we only need
> to have a global hash table. The hash table look-up can be RCU.
> [...]

hmm ... nasty. Would it be feasible to embedd the memleak info into the
allocated object itself? That would remove quite some runtime overhead,
besides eliminating the global hash.

I thought about this but would be more difficult for page allocations
and even impossible if we later want to track ioremap'ed regions (or
any other resource that has a unique id). The vmalloc'ed regions are
page aligned, though not sure there is any code that makes use of this
assumption. It also makes it too dependent on the allocator itself
(maybe not a big problem). Being less intrusive makes this easier to
maintain, especially if you want to use a different allocator.

Another option would be to store kmemleak info in the slab management
structures, vm_area (for vmalloc) or page structures but this breaks
the kmemleak functions for marking the false positives (which is done
outside the allocator).

Is there any scalability/performance impact of just
acquiring/releasing a lock or this is only affected by the contention
situations? If it's the latter, there can be a lock per hash-table
entry and drastically reduce the contention. The drawback is the
doubling of the hash table size, maybe with some impact on caches and
TLBs.

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux