From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Nick Couchman" Subject: Re: Re: [Xen-users] Max. PV and HVM Guests Date: Mon, 09 Nov 2009 08:29:48 -0700 Message-ID: <4AF7D2FC020000990002A811@collaborate.seakr.com> References: <4AF7CD9E020000990002A7CF@collaborate.seakr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline 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 , "Mr. Teo En Ming (Zhang Enming)" , pasik@iki.fi Cc: "xen-devel@lists.xensource.com" , "xen-users@lists.xensource.com" , Robert Dunkley List-Id: xen-devel@lists.xenproject.org Thanks for the information! Looks like I'll be adjusting some boot-time = options on my Xen servers. I have seen a couple of issues now and then w= ith either migration or starting a domU, but it happens once every few mo= nths at the most, and usually I blame the migration issues on a fault net= work connection or something like that. I'll have to try out limiting my= dom0s to 1 or 2 GB of RAM and see if those issues go away! Thanks! -Nick >>> On 2009/11/09 at 08:18, Keir Fraser wrote= :=20 > On 09/11/2009 15:06, "Nick Couchman" wrote: >=20 >> Really? I thought current conventional wisdom was to allow Xen to >> self-manage memory in both dom0 and domUs, and not to manually adjust >> this? I run several Xen systems with anywhere from 8 to 24 GB of RAM >> and 20 to 30 domUs on some of these systems and have *never* specified >> the dom0 memory at boot time - the Xen ballooning has always functione= d >> perfectly fine, and never crashed my dom0. Furthermore, while I'm not >> Linux developer and so not familiar with how Linux calculates bufferin= g >> and caching, I do know that my Linux systems dynamically manage buffer= s >> and caches, and when memory is reduced or some application requires a >> larger amount of physical memory, Linux reduces the amount of data in >> buffers and caches. >=20 > If you are not using dom0 as a general-purpose OS then it is a very goo= d > idea to specify dom0's memory allowance via dom0_mem=3D and disable > auto-ballooning in the xend-config.sxp. There are a few reasons for thi= s, > the most compelling being that Linux will have a metadata overhead for > tracking memory usage, and this will be a fraction (say a percent or so= ) of > its initial memory allocation. So, that overhead may be just 2% of 24GB= , > say, but then if dom0 gets ballooned down to 1GB it'll be more like 50%= ! > Clearly you are limited in how far you can balloon down without risking= the > OOM killer in dom0. >=20 > Apart from that, the auto-ballooner has been implicated in various quir= ky > bugs in the past -- failing domain creations and migrations for the mos= t > part -- so it's nice to turn it off if you can, as that's one less thin= g to > fail. And if dom0 is single-purpose you should be able to work out how = much > memory it needs for that purpose and statically allocate it. Using > auto-ballooner is actually perverse in this scenario, in that dom0 gets= the > least memory when it needs it the most (because it presumably has highe= st > load when servicing the most VMs, but in that case auto-ballooner has s= tolen > lots of memory from dom0). >=20 > My 2c! >=20 > -- Keir --------=0D This e-mail may contain confidential and privileged material for the sole= use of the intended recipient. If this email is not intended for you, o= r you are not responsible for the delivery of this message to the intende= d recipient, please note that this message may contain SEAKR Engineering = (SEAKR) Privileged/Proprietary Information. In such a case, you are stri= ctly prohibited from downloading, photocopying, distributing or otherwise= using this message, its contents or attachments in any way. If you have= received this message in error, please notify us immediately by replying= to this e-mail and delete the message from your mailbox. Information co= ntained in this message that does not relate to the business of SEAKR is = neither endorsed by nor attributable to SEAKR.