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

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

YAMAMOTO Takashi