[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
On 06/08/11 04:11, YAMAMOTO Takashi wrote:
>> On 05/26/11 03:51, YAMAMOTO Takashi wrote:
>>>>> 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
>>>>> 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
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.
Main Index |
Thread Index |