Re: [PATCH 1 of 2] Global virq for low memory situations

["Andres Lagar-Cavilla" <andres@lagarcavilla.org>]

>> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> Sent: Tuesday, February 28, 2012 2:56 PM
>> To: xen-devel@lists.xensource.com
>> Cc: ian.campbell@citrix.com; andres@gridcentric.ca; tim@xen.org;
>> JBeulich@suse.com;
>> ian.jackson@citrix.com; adin@gridcentric.ca
>> Subject: [Xen-devel] [PATCH 1 of 2] Global virq for low memory
>> situations
>>
>>  xen/common/page_alloc.c  |  92
>> ++++++++++++++++++++++++++++++++++++++++++++++++
>>  xen/include/public/xen.h |   1 +
>>  2 files changed, 93 insertions(+), 0 deletions(-)
>>
>>
>> When a low memory threshold on the Xen heap is reached, we fire a global
>> dom0
>> virq. If someone's listening, they can free up some more memory. The low
>> threshold is configurable via the command line token
>> 'low_mem_virq_limit", and
>> defaults to 64MiB.
>>
>> We define a new virq VIRQ_ENOMEM. Potential listeners include squeezed,
>> xenballoond, or anything else that can be fired through xencommons.
>>
>> We error-check the low mem virq against initial available heap (after
>> dom0
>> allocation), to avoid firing immediately.
>>
>> Virq issuing is controlled by a hysteresis algorithm: when memory dips
>> below a
>> threshold, the virq is issued and the next virq will fire when memory
>> shrinks
>> another order of magnitude. The virq will not fire again in the current
>> "band"
>> until memory grows over the next higher order of magnitude.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Sorry to be late to the party here, but does this take into
> account any fragmentation, i.e. does it reflect that allocations
> of order==0 will succeed but order>0 might fail?  Should it?

Not really concerned about fragmentation. Simply looking at overall count.
Andres

>
> Or maybe Jan's recent work has eliminated all but the corner
> cases of order>0 allocations?  (/me crosses fingers)
>
> Thanks,
> Dan
>