[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 05/04/2011 11:40, Manuel Bouyer wrote:
The pool logging is done via macros that trace from where the call comes
without changing the call interface to the pool and for kmem this would
be just a pass through.
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.
Should be possible.
Main Index |
Thread Index |