From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] Make ballooning work with maxmem > mem (i386 version) Date: Fri, 10 Nov 2006 16:16:05 +0000 Message-ID: References: <20061110161004.GE32562@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20061110161004.GE32562@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Glauber de Oliveira Costa , Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 10/11/06 16:10, "Glauber de Oliveira Costa" wrote: >> Maxmem will in future be fixed to track tot_pages. That was its original >> purpose: to cap what memory the guest is allowed *now*, not to tell it the >> max that it will ever be allowed. > > In this scenario, what's the purpose of current_reservation, as the only > difference from it now, is that it returns tot_pages instead of > max_pages ? The idea is that when you ask a guest to balloon down you will change its balloon target, then you will give it 'reasonable time' to drop its memory allocation (reflected by tot_pages). If it fails to comply you take action (e.g., warn user, suspend or kill the guest, etc). If it complies you drop max_pages. So you see that max_pages tracks behind tot_pages when you balloon down, and tracks ahead when you balloon up. It has a distinct purpose separate from that of tot_pages. That's the theory anyway. It's never been properly implemented in the python tools. But that may well change in future, so I'm not going to bake assumptions into guest kernels. -- Keir