Manuel Bouyer <[email protected]> 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
