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 <[email protected]> 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. -- Manuel Bouyer <[email protected]> NetBSD: 26 ans d'experience feront toujours la difference --
