From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Tian, Kevin" Subject: RE: [RFC][PATCH] 0/9 Populate-on-demand memory Date: Mon, 5 Jan 2009 14:08:49 +0800 Message-ID: <0A882F4D99BBF6449D58E61AAFD7EDD603BB4A4D@pdsmsx502.ccr.corp.intel.com> References: <30c85335-4729-4ae4-bb24-0c9dc2abe3cf@default> <20081230092637.GB7747@york.uk.xensource.com> <0A882F4D99BBF6449D58E61AAFD7EDD603BB4A2B@pdsmsx502.ccr.corp.intel.com> <20090102100330.GA12729@york.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20090102100330.GA12729@york.uk.xensource.com> Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: 'Tim Deegan' Cc: George Dunlap , Dan Magenheimer , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org >From: Tim Deegan [mailto:Tim.Deegan@citrix.com]=20 >Sent: Friday, January 02, 2009 6:04 PM >Hi,=20 > >At 09:40 +0800 on 31 Dec (1230716432), Tian, Kevin wrote: >> >From: Tim Deegan [mailto:Tim.Deegan@citrix.com]=20 >> >At 15:46 +0000 on 24 Dec (1230133560), George Dunlap wrote: >> >> At any rate, I suppose it might not be a bad idea to=20 >*try* to allocate >> >> more memory in an emergency. I'll add that to the list of >> >> improvements. >> > >> >Please don't do this. It's not OK for a domain to start using more >> >memory without the say-so of the tool stack. Since this emergency >> >condition means something has gone wrong (balloon driver failed to >> >start) then you're probably just postponing the inevitable,=20 >and in the >> >meantime you might cause problems for domains that *aren't*=20 >> >misbehaving. >> > >>=20 >> Then a user controlled option would fit here, which indicate whether >> given domain is important and then emergency expansion could be >> allowed in such case if mandatory kill is not acceptable. > >What if you're booting two important domains, one of which misbehaves >and uses extra memory, causing the second boot to fail? They were both >important, and you've just chosen the buggy one. :) > >Anyway, the only way to guarantee that a domain will boot even if it >fails to launch its balloon driver is to make sure there is enough >memory around for it to populate its entire p2m -- in which case you >might as well just allocate it all that memory in the first place and >avoid the extra risk of a bug in the pod code nobbling this important >domain. > >The marginal benefit of allowing it to break the rules in the=20 >case where >things go "slightly wrong" (i.e. it overruns its allocation but somehow >recovers before using all available memory) seems so small to me that >it's not even worth the extra lines of code in Xen and xend. =20 >Especially >since probably either nobody would turn it on, or everyone=20 >would turn it >on for every domain. > ok, a sound argument. Thanks, Kevin=