YAMAMOTO Takashi wrote:
>> On Sun, Jun 11, 2006 at 02:45:45PM +0900, YAMAMOTO Takashi wrote:
>>     
>>> which includes:
>>> 	1. implement solaris-like vmem.
>>>       
>> Could you elaborate a bit what this is and why you are changing things?
>> I have no idea what solaris "vmem" is.
>>
>> Martin
>>     
>
> for "what's vmem", see:
> 	http://www.usenix.org/event/usenix01/bonwick.html
>
> as i wrote in the previous mail, my primary purpose at this point is
> to make amap use kernel_map rather than kmem_map.
> (the latter is more restricted and there's no point for amap to use it.)
>
> for long term, i'd like to replace extent(9) and malloc(9),
> but my implementation is still far from it.
>
> YAMAMOTO Takashi
>   

The Solaris kernel memory allocator is *very* robust, and quite
efficient. I used it to replace a busted allocator in thin-client, and
much joy was held at suddenly new-found memory that gained by an
efficient allocator. (Efficient in both space and time.)

On the other hand, I've not looked seriously at our versions. Is there a
"need" to replace extent and malloc? 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.)

The other thing is that the cost of free/alloc with a cache allocation
goes *way* down, but it requires more intelligence on the part of
drivers. (You have to specify a size with kmem_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?)

I should probably look at your source in more detail. What would be
really nice would be to expose kmem_cache_alloc() - like implementation.

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