Messages in this thread | | | Date | Mon, 18 Dec 2006 12:21:20 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH 2.6.20-rc1 00/10] Kernel memory leak detector 0.13 |
| |
* Catalin Marinas <catalin.marinas@gmail.com> wrote:
> >> [...] It could be so simple that it would never need to free any > >> pages, just grow the size as required and reuse the freed memleak > >> objects from a list. > > > >sounds good to me. Please make it a per-CPU pool. > > Isn't there a risk for the pools to become imbalanced? A lot of > allocations would initially happen on the first CPU.
hm, what's the problem with imbalance? These are trees and imbalance isnt a big issue.
> >[...] (Add a memleak_object->cpu pointer so that freeing can be done > >on any other CPU as well.) > > We could add the freed objects to the CPU pool where they were freed > and not use a memleak_object->cpu pointer.
i mean totally per-CPU locking and per-CPU radix trees, etc.
> > We'll have to fix the locking too, to be per-CPU - memleak_lock is > > quite a scalability problem right now. > > The memleak_lock is indeed too coarse (but it was easier to track the > locking dependencies). With a new allocator, however, I could do a > finer grain locking. It probably still needs a (rw)lock for the hash > table. Having per-CPU hash tables is inefficient as we would have to > look up all the tables at every freeing or scanning for the > corresponding memleak_object.
at freeing we only have to look up the tree belonging to object->cpu. Scanning overhead does not matter in comparison to runtime tracking overhead. (but i doubt it would be much different - scanning overhead scales with size of tree)
> There is a global object_list as well covered by memleak_lock (only > for insertions/deletions as traversing is RCU). [...]
yeah, that would have to become per-CPU too.
> [...] List insertion/deletion is very small compared to the hash-table > look-up and it wouldn't introduce a scalability problem.
it's a common misconception to think that 'small' critical sections are fine. That's not the issue. The pure fact of having globally modified resource is the problem, the lock cacheline would ping-pong, etc.
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/
| |