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.
