> Date: Wed, 31 May 2023 20:54:34 +0000 > From: Andrew Doran <a...@netbsd.org> > > 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.
