>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
|
Home