[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: extent-patch and overview of what is supposed to follow
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
Main Index |
Thread Index |