Subject: Re: amap memory allocation
To: None <email@example.com>
From: YAMAMOTO Takashi <firstname.lastname@example.org>
Date: 06/13/2006 11:59:56
> 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
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?
> 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.
although i don't know solaris internals much, i guess it doesn't distinguish
intrsafe/nointr allocations as we does. right?
> 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.