Re: malloc(9) vs kmem(9) interfaces

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Wed, 31 May 2023 20:54:34 +0000
> From: Andrew Doran <ad%netbsd.org@localhost>
> 
> On Sat, Oct 29, 2022 at 02:42:27PM +0000, Taylor R Campbell wrote:
> 
> > - Was the rationale migrating to kmem(9) written down or discussed
> >   publicly anywhere?
> 
> Some I know of are:
> 
> - escape limitations of (interrupt safe) kmem_map by moving to kernel_map
> - experiment with new layout strategies (vmem)
> - experiment with caching, per-CPU stuff
> - .. without upsetting existing malloc() users

It's all the same under the hood now in kmem(9) and malloc(9), though.
All that's left to distinguish them is the user-facing API -- and the
possibility of attribution.

> > - What would the cost of restoring attribution be, other than the
> >   obvious O(ntag*nsizebuckets) memory cost to record it and the effort
> >   to annotate allocations?
> 
> Related to this, in my experiments it turns out that using dedicated pools
> for objects for no other reason than to to get attribution or be space
> efficient seems to exert a lot of presssure on the CPU cache to the point
> that reverting to the general purpose allocator where possible yields a
> small but measurable and repeatable reduction in system time during builds.

Right, so the question is -- can we get the attribution _without_
that?  Surely attribution itself is just a matter of some per-CPU
counters.