Re: kernel memory allocators

[Andrew Doran <ad%netbsd.org@localhost>]

On Thu, Jan 20, 2011 at 04:30:49PM +1100, matthew green wrote:
> 
> > > Benefits I've thought about:
> > > - The kmem pools use pool_caches therefor scalability will be much
> > > better as the old malloc has a single lock for all access, the pools
> > > have one each with a per cpu cache layer.
> > > - The old malloc only returns oversized allocations back to the kmem
> > > layer but nothing that is in it's bucket, pools can be drained...
> > > - Removing one redundant interface in the kernel-api (in the long
> > > term, when dropping the malloc wrapper)
> > 
> > thanks for working on this.
> > while i'm all for removing malloc(9), i tend to think it should be done
> > by changing the users to use either kmem_alloc or pool_cache, instead of
> > making kmem_alloc interrupt-safe.  i don't think there's much demand for
> > interrupt-safe variable-sized memory allocations.
> 
> while we're discussions allocators, i miss the extra accounting
> information that malloc(9) provides that kmem(9) does not.  pool(9)
> has the info in a slightly different form, but all kmem(9) users
> are dumped into the same pile.
> 
> this part of malloc -> kmem conversions i feel is a step backwards,
> though i'm not going to claim it is more important than the general
> benefits of kmem(9) vs. malloc(9).
> 
> 
> are there any plans to modify kmem to support this sort of usage,
> where a client names itself somehow?

No plans, but in the past I have hacked lockstat to track who is
allocating memory, how much, how often and so on.  A similar mechanism
with a bit of memory (pardon the pun) and basic support in kmem would 
be easy enough to implement and could give an "over time" report to
show who holds what.  So my idea is a lockstat-style report showing the
exact call sites where things were allocated, how much is still held etc.

dtrace provides us with this capability but I haven't thought it though.