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

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:
> > >> 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.

It could be DTrace facility or some __builtin_return_address tracking
to have some means e.g. to identify memory leaks when kmem(9) is used.

I am not convinced about statistics point.  For intensive allocations,
constant-sized pool_cache(9) should/would be used, where it already
gathers statistics.  If there is some particular need for statistics,
one can always collect it at the caller's level.  Therefore, I do not
see the need to invade allocator's API for that.

-- 
Mindaugas