From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dan Magenheimer" Subject: RE: [PATCH] linux/balloon: don't allow ballooningdowna domain below a reasonable limit Date: Sat, 3 May 2008 13:27:56 -0600 Message-ID: <20080503132756296.00000041924@djm-pc> References: Reply-To: "dan.magenheimer@oracle.com" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Keir Fraser , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org > > I was planning on providing both Model C and Model D (see below), > > but let me know if you will only accept Model C (or even Model B) > > and I will adjust accordingly. > = > I don't know that what you are trying to do is, in full generality, > tractable. Who knows how valuable the memory pages belonging = > to a domU are, > relative to other domains? Just because they are only = > buffer-cache pages, > for example, may not necessarily mean we want the domU to = > aggressively page > them out every N seconds. > > At least if you can extract some measure of memory pressure = > from each domU > (e.g., paging frequency, size of active/inactive page lists) = > dom0 can then > make some global optimisation periodically based on e.g., relative > priorities of domains. > = > Not that your approach is not applicable for some scenarios. = > As long as it's > a switchable option, perhaps it is the kind of thing to let = > users vote on. I agree the general case is not tractable. But I think the basic concept is useful and an initial implementation may serve as a good foundation for later tuning. The initial selfballooning policy is simply "if I have extra memory, give it up; and if I need memory, ask for it back"; where "extra" and "need" are admittedly poorly estimated (but are good enough for some workloads) and the grant-memory-to- asking-domain policy is first-come-first-served. Any more complex policy certainly requires more information to be passed from the guest to domain0. OK, I will submit a patch to cover both Model C and D. Still tracking down a bug or two... Dan