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

Re: [Xen-devel] [PATCH] Make ballooning work with maxmem > mem (i386 version)


  • To: Glauber de Oliveira Costa <gcosta@xxxxxxxxxx>, Keir Fraser <keir@xxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Fri, 10 Nov 2006 16:16:05 +0000
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 10 Nov 2006 08:16:21 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AccE44WqxEWtYHDWEduDSAAX8io7RQ==
  • Thread-topic: [Xen-devel] [PATCH] Make ballooning work with maxmem > mem (i386 version)



On 10/11/06 16:10, "Glauber de Oliveira Costa" <gcosta@xxxxxxxxxx> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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