re: kernel memory allocators

[matthew green <mrg%eterna.com.au@localhost>]

> > 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?


.mrg.