Re: [Xen-devel] [PATCH v3 1/3] libxl: xl mem-max et consortes must update static-max in xenstore too [and 1 more messages]

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Wed, Apr 10, 2013 at 04:56:09PM +0100, Ian Jackson wrote:
> Daniel Kiper writes ("Re: [Xen-devel] [PATCH v3 1/3] libxl: xl mem-max et 
> consortes must update static-max in xenstore too"):
> > On Tue, Apr 09, 2013 at 03:18:10PM +0100, Ian Jackson wrote:
> > > Daniel Kiper writes ("Re: [Xen-devel] [PATCH v3 1/3] libxl: xl mem-max et 
> > > consortes must update static-max in xenstore too"):
> > > > That is why I think that static-max should be unconditionally
> > > > changed or the guest should write something in xenstore to inform
> > > > that it supports memory hotplug and relevant check should be waived.
> > >
> > > Right.  I don't see what any of that has to do with "xl mem-max"
> > > though.  The purpose of xl mem-max is to update the guest's
> > > enforcement limit.
> >
> > ...and static-max if you would like to use memory hotplug in real.
> > If not, then xl mem-set does not allow you to allocate more memory
> > to a guest than static-max.
>
> You seem to be losing sight of the purpose of the static-max key in
> xenstore.  It is for the benefit of the toolstack - and, indirectly,
> the user - so that we know the maximum amount of memory we can ask the
> guest to us.

OK, I understand that. However, static-max equal to maxmem makes sens
for a guest without memory hotplug. If you have memory hotplug and you
could not change static-max then this is an obstacle to use memory
hotplug in real. You could not raise target above static-max using
xl mem-set and you could not change target from guest because
of "xen maximum" too.

Now we have two options:
  - we could allow user to change static-max for a given guest by calling
    xl mem-max (my current solution); this way we change a bit meaning
    of static-max from "maximum amount of memory allowed for the guest
    (usualy all guest OS structures were prepared for this amount of memory
    but they do not need to be filled at boot time)" to "maximum amount
    of memory allowed for the guest at a given moment",
  - we could leave static-max as is and use "xen maximum" as "maximum
    amount of memory allowed for the guest at a given moment"; However,
    in this case comparison with static-max in libxl_set_memory_target()
    should be changed to comparison with "xen maximum".

[...]

> > > No, because a guest which is being asked to shrink will experience
> > > memory allocation failures if it doesn't shrink monotonically.
> >
> > IIRC if you shrink memory for a given guest and it does not have
> > memory balloon driver installed nothing happens.
>
> Yes.
>
> >   I did not tested it but it would be crazy when host could steal
> > random page from the guest without its acceptance.
>
> It can't steal memory from the guest.  But if the guest does any
> operation which allocates memory, when it is above the limit, that
> operation can fail.
>
> So for example consider a guest with a balloon driver (but without
> memory hotplug) which was booted with 1G and subsequently ballooned
> down to 768M.
>
> If the user says "xl mem-set blah 512M" then the limit and target are
> both set to 512M.  If the guest's balloon driver, instead of shrinking
> the guest as it is supposed to, tries to allieviate some memory
> pressure inside the guest by allocating _more_ memory from Xen, that
> allocation will fail.

I suppose it could be phrased like that:

Guests which attempts to exceed or exceeds the target may experience
memory allocation failures.

It takes in to account your case and my case when a guest attempts
to raise its allocation above target.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel