Subject: Re: amap memory allocation
To: YAMAMOTO Takashi <firstname.lastname@example.org>
From: Garrett D'Amore <email@example.com>
Date: 06/12/2006 23:07:34
YAMAMOTO Takashi wrote:
>> On the other hand, I've not looked seriously at our versions. Is there a
>> "need" to replace extent and malloc?
> i think it's an improvement because:
> - extent is linear-search based.
> - it isn't trivial to extend malloc to use backends other than
> - malloc is not very space efficient.
> - for some workloads, malloc's "permanent allocation" policy
> is horrible.
> of course, we can just improve extent and malloc instead.
> (in that case, i don't volunteer at this point, tho. :)
>> I think extent is still needed at
>> least, because I don't think the Solaris vmem system really addresses
>> this need (at least Solaris 9 didn't -- they have separate code built on
>> top of kmem_alloc for that.)
> what's the particular feature of extent, which can't be done with vmem,
> in your mind?
> "fragment" case of extent_free?
The ability to match particular alignment constraints, for one. This can
be implemented on top of kmem_alloc of course, but may be less efficient
in such a case.
Most of my experience is not with vmem_alloc, per se, but rather with
kmem_cache_alloc and the slab allocator.
>> Finally, is there a reason that you couldn't make KM_NOSLEEP style
>> allocations work from interrupt context ala the Solaris kmem_alloc
>> (perhaps by going to a different allocation pool?)
> this implementation is not intrsafe because it's backed by kernel_map,
> which is not intrsafe.
> i chose kernel_map because i thought that it was suitable for the common cases.
> it's trivial to provide another one, say, kmem_alloc_intrsafe(),
> which is backed by kmem_map.
Or, since you're emulating Solaris, have it specified by a flag.
> although i don't know solaris internals much, i guess it doesn't distinguish
> intrsafe/nointr allocations as we does. right?
It does. Look at KM_NOSLEEP in the flags argument. KM_SLEEP allocations
are not interrupt safe, KM_NOSLEEP allocations never sleep, and hence
are interrupt safe (but may fail).
>> I should probably look at your source in more detail. What would be
>> really nice would be to expose kmem_cache_alloc() - like implementation.
> iirc, there are no fundamental differences between kmem_cache_alloc
> and our pool_cache. it's easier to implement per-cpu things for pool_cache.
Probably true. I'm not even aware of pool_cache. There's a lot of NetBSD
internals I still need to learn about.
kmem_alloc (not vmem_alloc, which is lower layer) is implemented on top
of kmem_caches that are size oriented. So, assuming that you pick good
sizes for the slab allocator, you get very little internal
fragmentation, and pretty much non-existent external fragmentation.
> YAMAMOTO Takashi
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191