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

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

On Tue, Apr 05, 2011 at 11:26:10AM +0200, Lars Heidieker wrote:
> That's what I meant with the overhaul, the statistics must be per
> CPU then, the current statistics implementation is single threaded
> (as malloc itself).
> Technically it would be possible to add some malloc like type
> information to kmem for statistics, this involves changing the
> kmem's interface to include such type information, while pool-like
> logging does not involve such changes.

Err, why ? you'd have to pass a name, one way or another.
I don't care if the name as argument is M_MBUF or "mbuf"
(that is, a constant or a string), but right now kmem doesn't have
arguments like that. So you'll have to change kmem, eiter way.


> I totally agree on the fact that some kind of
> allocation/deallocation tracking is required for kmem as well.
> Personally I like pool like logging more as it shows where the
> allocation took place and not just how much memory of which kind,
> but logging is like a sliding window view on the allocations it
> doesn't show the full history.
> This seems to me the trade off here.

I'm not sure sure why we can't have both. Also, pool also have a name,
which shows how many memory each subsystem is eating.

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