On Tue, Apr 05, 2011 at 07:32:54AM +0200, Lars Heidieker wrote:
On 04/03/11 14:52, Manuel Bouyer wrote:
On Sun, Apr 03, 2011 at 02:36:37PM +0200, Lars Heidieker wrote:
On 04/03/11 01:36, Matthew Mondor wrote:
On Sat, 2 Apr 2011 11:49:14 +0200
Martin Husemann<martin%duskware.de@localhost> wrote:
On Sat, Apr 02, 2011 at 11:30:16AM +0200, Manuel Bouyer wrote:
AFAIK dtrace doesn't work on non-modular kernels ...
Nor on most of our archs, and AFAICT there is not even a document
describing the (maybe nontrivial amount of) work needed to make it
work there.
I don't think that we should leave the tracking for a hypothetical
future; it'd be better if the interface, or implementation, allowed to
do such tracking....
Just an Idea, how about giving the kmem allocator a pool like logging...
or malloc(9)-like :)
:-) The trouble is large parts of the kernel are migrated to kmem
already and having too interfaces and two allocators is something that
needs cleanup. The malloc-type statistics would need a major overhaul
if they are the way to go, what I doubt, as the essentially make
malloc single threaded even if it is backed by kmem caches with
cpu-local caches.
Why do the malloc statistics (which are compiled in only with
KMEMSTATS AFAIK) would have to make the allocator single threaded ?
statistics can also be per-cpu.
The point of reusing the malloc-type stats is that the information
is already there. I'd rather see kmem gain the same kind of stats
in its interface, rather than dropping the information we already have.