All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH] PoD: Handle operations properly when domain is dying
Date: Wed, 11 Nov 2009 17:15:28 +0000	[thread overview]
Message-ID: <4AFAF130.7080506@eu.citrix.com> (raw)
In-Reply-To: <067674d9-b387-479d-961d-99fa8459485a@default>

Dan Magenheimer wrote:
> BUT, PoD is essentially doing dynamic ballooning without
> notifying the tools, correct?  Unless I misunderstand, the
> whole point of PoD is to not use zeroed-out-by-Windows
> memory until it gets written (with non-zeroes), and the
> underlying objective is that that not-yet-used memory can
> be used for other purposes -- such as other domains.
>   
You misunderstand. :-)

The *only* point of PoD is to allow a VM to boot "pre-ballooned".  It is 
not related to memory overcommit.  PoD memory is allocated to a domain 
by the domain builder, and is only ever changed afterwards by explicit 
calls made by the toolstack.  Memory is moved from the PoD "cache"* to 
the p2m table and back again automatically, but the total amount of 
memory owned by the domain is constant.

To review, the problem that PoD solves is the following:

HVM guests (both Linux and Windows) read the e820 map early in boot, and 
consider their memory size essentially fixed based on what they read.  
IOW, if Windows reads 1GiB in the e820 map, it will never use more than 
1GiB of RAM.

In a virtualized environment, we'd like to have the flexibility of 
booting a VM with 1GiB of RAM, but then increasing its RAM (say, up to 
4GiB) after boot if it is determined that the VM in question needs more 
memory.

Without PoD, your only option is to build the domain with 4GiB of RAM 
and then wait for the balloon driver to balloon the VM down to 1GiB.  
The problem with this, of course, is that you have to scrape together 
the other 4GiB for the course of the boot.

With PoD, you pass the domain builder two values: 4GiB and 1GiB.  The 
domain builder will fill the p2m table with 4GiB of PoD entries, and 
then allocate 1GiB of ram for the per-domain PoD "cache".  Xen will move 
memory into and out of this "cache" as needed to allow the VM to boot 
until the balloon driver loads. But the total amount of memory used by 
the VM during this time is fixed at 1GiB.  If this pre-allocated amount 
of RAM is used up, no more memory is allocated; the domain crashes.

The zero-page scans are used to recover memory from the p2m table and 
put it back in the per-domain PoD "cache".  This memory is not returned 
to Xen, and cannot be used for other VMs.

So if you're using PoD, you can trust that the memory used by the VM 
will not change "under your feet" so to speak.

 -George

* I put the term "cache" in quotes because it is related to the normal 
English definition of the word ("a hidden storage space"), rather than 
the computer science meaning of the word (e.g., extra copies of data 
used to speed up storage heirarchies).

  parent reply	other threads:[~2009-11-11 17:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-11 15:08 [PATCH] PoD: Handle operations properly when domain is dying George Dunlap
2009-11-11 15:26 ` Dan Magenheimer
2009-11-11 15:42   ` George Dunlap
2009-11-11 16:53     ` Dan Magenheimer
2009-11-11 17:13       ` Keir Fraser
2009-11-11 17:15       ` George Dunlap [this message]
2009-11-11 17:58         ` Dan Magenheimer
2009-11-11 22:49           ` George Dunlap
2009-11-11 23:34             ` Dan Magenheimer
2009-11-12 10:56               ` George Dunlap
2009-11-11 18:12   ` Dave Scott
2009-11-11 18:27     ` Dan Magenheimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AFAF130.7080506@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=dan.magenheimer@oracle.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.