> On Jun 1, 2023, at 5:27 AM, Greg Troxel wrote:
>
> However, you are talking about maintaining a count of objects by user.
> That is vastly cheaper, and likely 90%+ as useful.
>
> SO there is "object attribution" and "total usage attribution".
The old malloc() attribution mechanism just
Taylor R Campbell writes:
> Right, so the question is -- can we get the attribution _without_
> that? Surely attribution itself is just a matter of some per-CPU
> counters.
Reading along, it strikes me there is a huge point implicit in your
last sentence.
I first thought of attribution as
> Date: Wed, 31 May 2023 20:54:34 +
> From: Andrew Doran
>
> On Sat, Oct 29, 2022 at 02:42:27PM +, 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
> On May 31, 2023, at 1:54 PM, Andrew Doran wrote:
>> - 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
On Sat, Oct 29, 2022 at 02:42:27PM +, 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
Starting 10-15 years ago, the NetBSD kernel has been slowly migrating
from the traditional BSD malloc(9) API to the Solaris-inspired kmem(9)
API.
The main differences between the interfaces are:
malloc(9) kmem(9)
- ---
. attribution by
