[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [RFC][PATCH] 0/9 Populate-on-demand memory
>From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxx] >Sent: Friday, January 02, 2009 6:04 PM >Hi, > >At 09:40 +0800 on 31 Dec (1230716432), Tian, Kevin wrote: >> >From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxx] >> >At 15:46 +0000 on 24 Dec (1230133560), George Dunlap wrote: >> >> At any rate, I suppose it might not be a bad idea to >*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, >and in the >> >meantime you might cause problems for domains that *aren't* >> >misbehaving. >> > >> >> 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 >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. >Especially >since probably either nobody would turn it on, or everyone >would turn it >on for every domain. > ok, a sound argument. Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |