On 18/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Catalin Marinas <[EMAIL PROTECTED]> wrote: > I could also use a simple allocator based on alloc_pages since > kmemleak doesn't track pages. [...] actually, i'm quite sure we want to track pages later on too, any reason why kmemleak shouldnt cover them?
It could track them but I'm not sure how efficient it would be since you have different ways to get the page addresses like pfn, struct page. The pfn would actually introduce a lot of false negatives. This needs some investigation and it can probably be done but I'll first focus on the slab allocator.
> [...] 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.
[...] (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.
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. There is a global object_list as well covered by memleak_lock (only for insertions/deletions as traversing is RCU). Since modifications to this list happen at the same time with the hash table modifications, the memleak_lock is held anyway so we probably don't need to do per-CPU object lists (they would also need some locking if freeing would happen on a different CPU). List insertion/deletion is very small compared to the hash-table look-up and it wouldn't introduce a scalability problem. -- 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/
