[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] implementing memory ballooning in WIndows
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |