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