Subject: Re: amap memory allocation
To: YAMAMOTO Takashi <email@example.com>
From: Garrett D'Amore <firstname.lastname@example.org>
Date: 06/13/2006 09:18:31
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 D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191