tech-kern archive

[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 10:45, Manuel Bouyer wrote:
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<>  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.

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. 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.

Home | Main Index | Thread Index | Old Index