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

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.

-- Garrett
> YAMAMOTO Takashi
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191