Re: [Xen-devel] [RFC][PATCH] 0/9 Populate-on-demand memory

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

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.

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel