From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: RE: [RFC][PATCH] 0/9 Populate-on-demand memory Date: Wed, 24 Dec 2008 06:32:42 -0800 (PST) Message-ID: <0ab6a86a-16ac-47fe-b6fd-6ce56f5b59f9@default> References: Mime-Version: 1.0 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: 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 Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org > > The consequence for a no-swap-disk is application failures > > and the consequence even if a swap disk IS configured is temporarily > > very poor performance. >=20 > I don't think this is particular to the PoD patches, or even > ballooning per se. A swap disk would be required any time you boot > with a small amount of memory, whether it could be increased or not. > > But you're right, in that this differs from a typical operating > system's "demang-paging" mechanism, where the goal is to give a > process only the memory it actually needs, so you can use it for other > processes. You're still allocating a fixed amount of memory to a > guest at start-up. The un-populated memory is not available to use by > other VMs, and allocating more memory is a (relatively) slow process. > I guess a brief note pointing out the difference between "populate on > demand" and "allocate on demand" would be useful. Yes, its just that with your fix, Windows VM users are much more likely to use memory overcommit and will need to be "trained" to always configure a swap disk to ensure bad things don't happen. And this swap disk had better be on a network-based medium or live migration won't work. =20 > > So this won't work for any domain that does start-of-day > > scrubbing with a non-zero value? I suppose that's OK. >=20 > Not if the scrubber might win the race against the balloon driver. :-) > If this really becomes an issue, it should be straightforward to add > functionality to handle it. It just requires having a simple way of > specifying what "scrubbed" pages look like, an extra p2m type for "PoD > scrubbed" (rather than PoD zero, the default), and how to change from > scrubbed <-> zero. >=20 > Did you have a particular system in mind? No, I had just given some limited thought to this problem previously, had considered the idea of sharing a zero page for the Windows start-of-day scrubbing problem, but didn't know if the scrubbing always only used zeroes. If it does, great! I was worried that something like a secure version of Windows might use some other random bit pattern, but I'll bet Windows elsewhere assumes that all pages start as zero-filled and is thus dependent on start-of-day ZERO scrubbing, so I'll bet your approach will always work.