Re: extent-patch and overview of what is supposed to follow

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

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.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--