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

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


Home | Main Index | Thread Index | Old Index