YAMAMOTO Takashi wrote:
>>>> 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.
>>     
>
> solaris vmem_xalloc has constraint arguments, including alignment,
> doesn't it?  (no idea about its efficiency or implementation, tho.)
>   

Underlying vmem probably does. I've not used it before. My experience is
more with the layer above, at kmem_cache_alloc and friends. :-) If vmem
will do it, then great!

>   
>>> 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).
>>     
>
> even if you never sleep, our kernel_map is not interrupt safe.
>   

Yes, but the KM_NOSLEEP flag could be a hint to use an interrupt safe map.

-- Garrett

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