WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] implementing memory ballooning in WIndows

To: James Harper <james.harper@xxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] implementing memory ballooning in WIndows
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Wed, 3 Jun 2009 08:35:36 -0700 (PDT)
Cc: Steven Smith <steven.smith@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 03 Jun 2009 08:36:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090603145813.GA20200@xxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
James --

I'm completely ignorant about Windows but have often wondered
if self-ballooning scripts (which today only run in a RedHat-ish
environment) could be implemented on Windows.

If you might be interested, look in the tree (starting
around Xen 3.3) at tools/xenballoon, with more info
on the Xen Summit Summer 2008 site.

Dan

> -----Original Message-----
> From: Steven Smith [mailto:steven.smith@xxxxxxxxxxxxx]
> Sent: Wednesday, June 03, 2009 8:58 AM
> To: James Harper
> Cc: Steven Smith; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] implementing memory ballooning in WIndows
> 
> 
> > > > Do the Citrix Windows PV drivers implement memory 
> ballooning? I've
> > been
> > > > looking at this a bit for GPLPV and the avenues I can see are:
> > > >
> > > > 1. Memory can be added via ACPI hot-add, but I assume that that
> > isn't
> > > > implemented in the GPL qemu code (or is it?) and only works for
> > Windows
> > > > Server Enterprise, not Vista, XP, or Server Standard.
> > > > 2. I can give memory back via just allocating a 
> physical page and
> > giving
> > > > it back to Xen
> > > 
> > > Our drivers do implement ballooning (although it's not 
> actually hooked
> > > up to the control tools, for mostly tedious reasons), and 
> they do it
> > > using approach 2.
> > > 
> > > Approach 1 does have the advantage that you can later increase a
> > > domain's memory allocation beyond its boot-time size, but that's
> > > obviated to some extent by the new populate-on-demand 
> support, and, as
> > > you say, memory hot add is quite heavily restricted by Microsoft's
> > > licensing.
> > > 
> > 
> > #2 is pretty much where I was going. My concern was that 
> Windows says "I
> > have 4GB of memory, so I can use X amount for this and Y 
> amount for that
> > and Z amount for something else", and when the memory is 
> reduced down to
> > (say) 1GB, I was worried that Windows might get a bit 
> unbalanced. Same
> > with Linux when it makes decisions about how much space to 
> reserve for
> > network buffers etc.
> > 
> > But it seems that you have taken the stance that there is no such
> > problem, so I'll do the same.
> We've gotten away with it so far, certainly.
> 
> > The other thing I was concerned about is that the memory is 
> only given
> > back once the PV drivers start, so in the situation where you have:
> > . 16G physical memory
> > . Dom0 with 2G of memory
> > . 6 DomU's with 4G of memory, ballooned down to 2G of memory
> > 
> > It would only work if all the DomU's successfully ran their 
> PV drivers
> > and ballooned the memory down as requested, and you 
> couldn't start them
> > all at once as on boot they'd actually need 4G of memory.
> Well, the second problem is solved by populate-on-demand mode.  The
> first is much harder, and almost certainly requires some kind of
> emergency hypervisor paging.
> 
> Of course, if you do populate-on-demand and then *can't* balloon down
> then the failure mode is extremely bad.  It can hopefully be avoided
> by a sufficiently paranoid toolstack, but it's still rather
> unfortunate.
> 
> > Did you ever have a tinker with the (mostly) undocumented
> > MmAddPhysicalMemory function at all? On face value it seems 
> like it is
> > the sort of function that could be useful... Microsoft 
> would not approve
> > of such a thing obviously which makes it unusable for 
> production use,
> > but I am curious as to if it would actually work.
> I've not looked at it at all, sorry.
> 
> Steven.
>

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