From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Andres Lagar-Cavilla" Subject: Re: [PATCH 1 of 2] Global virq for low memory situations Date: Tue, 28 Feb 2012 20:17:35 -0800 Message-ID: References: <7e6a9e72-e028-4f3e-a474-76be9babe3c5@default> Reply-To: andres@lagarcavilla.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <7e6a9e72-e028-4f3e-a474-76be9babe3c5@default> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dan Magenheimer Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org, jbeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca List-Id: xen-devel@lists.xenproject.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 > > 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 >