[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.