re: kernel memory allocators

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

hi,

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

i had some code around to record callers.  it was mainly for
post-mortem debugging, tho.

YAMAMOTO Takashi

> 
> 
> .mrg.