From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: RE: Xen balloon driver discuss Date: Tue, 30 Nov 2010 08:39:46 -0800 (PST) Message-ID: <4fd283fa-d6fd-42a3-9d04-104fbc644659@default> References: <4CF38C2F.3020605@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <4CF4D70D.8030500@eu.citrix.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: George Dunlap , hotmaim Cc: xen-devel@lists.xensource.com, Chu Rui List-Id: xen-devel@lists.xenproject.org > One of the explicit purposes of PoD is to set aside a fixed amount of > memory for a guest, so that no other domains / processes can claim it. > It's guaranteed that memory, and as long as it has a working balloon > driver, shouldn't have any issues using it properly. Sharing it with > other VMs would undermine this, and make it pretty much the same as the > Xen free page list. > : > It sounds like what you're advocating is *allocate*-on-demand (as > opposed to PoD, which allocates all the memory at the beginning but > *populates* the p2m table on demand): tell all the guests they have > more > memory than is available total, assuming that only some of them are > going to try to use all of it; and allocating the memory as it's used. > This works well for processes, but operating systems are typically > built > with the assumption that memory not used is memory completely wasted. > They therefore keep disk cache pages and unused memory pages around > "just in case", and I predict that any guest which has an active > workload will eventually use all the memory it's been told it has, even > if it's only actively using a small portion of it. At that point, Xen > will be forced to try to guess which page is the least important to > have > around and swap it out. Maybe another key point about PoD is worth mentioning here (and probably very obvious to George and possibly mentioned somewhere else in this thread and I just missed it): The guest will *crash* if it attempts to write to a PoD page and Xen has no real physical page to back it. Or alternately, the guest must be stopped (perhaps for a long time) until Xen does have a real physical page to back it. Real Windows guest users won't like that, so the memory should be pre-allocated and remain reserved for that guest. Or the toolset/dom0 must implement host-swapping, which has all sorts of nasty unpredictable performance issues. Dan