[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 0 of 4] Handling of (some) low memory conditions

>>> On 16.02.12 at 16:34, "Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx> 
>>> wrote:
>>>>> On 16.02.12 at 15:40, "Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>
>>>>> wrote:
>>>>>>> On 16.02.12 at 04:57, Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
>>>>>>> wrote:
>>>>> - Add a VIRQ that the hypervisor can emit when reaching a low memory
>>>>> threshold.
>>>> In this patch, which didn't make it to my inbox yet, you will want to
>>>> change this
>>>> +    if ( (total_avail_pages << PAGE_SHIFT) <= opt_low_mem_virq )
>>>> to
>>>>     if ( total_avail_pages <= PFN_DOWN(opt_low_mem_virq) )
>>>> to avoid the case (on 32-bit hypervisors) where total_avail_pages,
>>>> being just 'long', would get significant bits shifted out.
>>>> I'm further wondering whether the default value shouldn't be set
>>>> dynamically based on available memory and/or taking into account
>>>> an eventual dom0_mem= option.
>>> I can cap or get rid of the threshold (and the virq) if it doesn't make
>>> sense with respect to total memory. I'm not sure about integrating
>>> dom0_mem, since dom0's footprint is also a quantity manipulated by the
>>> receiver of the virq.
>> No, dom0_mem= is only specifying the starting value, and the case
>> that would be of possibly interest is that of having a negative amount
>> specified.
> Sorry, not following entirely. The negative quantity you refer to would be
> dom0_mem or the low mem virq threshold? Additional checks pertaining only
> to dom0_mem, not in relation to this threshold, would most likely go on a
> separate patch.

Consider someone useing "dom0_mem=-64M" - that'd make your
code raise the vIRQ immediately, even though the admin decided
that leaving 64M inside Xen is okay at boot time at least.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.