Re: kmem-pool-uvm

[Lars Heidieker <lars%heidieker.de@localhost>]

hi,

On 06/08/11 04:11, YAMAMOTO Takashi wrote:
> hi,
> 
>> Hi,
>>
>> On 05/26/11 03:51, YAMAMOTO Takashi wrote:
>>> hi,
>>>
>>>>> Findings after having run the system for a while and having about 1.1gig
>>>>> in the pool(9)s:
>>>>> Option a: about 30000 allocated kernel map_entries (not in the map but
>>>>> allocated)
>>>>> Option b: about 100000 allocated boundary tags.
>>>>> Option c: about 400000 allocated boundary tags.
>>>>>
>>>>> With boundary tags beeing about half the size of vm_map_entries the vmem
>>>>> version uses slightly more memory but not so much.
>>>
>>> why did you use different numbers for heap_va_arena's qcache_max
>>> (8 * PAGE_SIZE) and VMK_VACACHE_MAP_QUANTUM (32 * PAGE_SIZE)?
>>>
>>> if i read your patches correctly, the number of map entries/boundary tags
>>> will be smaller if these constants are bigger, right?
>>>
>>
>> I choose the 8 * PAGE_SIZE for qcache_max as the quantum caches are
>> pool_caches, so if we have only two or three allocation of a particular
>> size made by different cpus we have 2 or 3 times the va in the pool
>> caches, with a lot va wasted.
> 
> in that case, the "two or three allocation" will likely be served by
> a single pool page, won't it?  ie. the waste is same as the direct use of 
> pool.
> 

true, the wastage will be only larger if more puts and gets happen as
constructed objects are kept in the caches. However I don't think this
is a problem at all.

Lars