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

[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

Given the chance for a do-over I'd remove the ability to do allocation from
interrupt context with malloc() (why allow variable sized allocs there?),
use pools for interrupt context allocs and retain the old malloc()
interface, or something along those lines.

> - 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.
I plan to do this for some objects.

Andrew