Re: [Qemu-devel] [RFC 3/3] virtio-balloon: add auto-ballooning support

[Amit Shah]

On (Mon) 14 Jan 2013 [09:58:30], Luiz Capitulino wrote:
> On Sat, 12 Jan 2013 02:02:32 +0530
> Amit Shah <address@hidden> wrote:
> 
> > Hi Luiz,
> > 
> > On (Tue) 18 Dec 2012 [18:16:55], Luiz Capitulino wrote:
> > > The auto-ballooning feature automatically performs balloon inflate
> > > or deflate based on host and guest memory pressure. This can help to
> > > avoid swapping or worse in both, host and guest.
> > > 
> > > Auto-ballooning has a host and a guest part. The host performs
> > > automatic inflate by requesting the guest to inflate its balloon
> > > when the host is facing memory pressure. The guest performs
> > > automatic deflate when it's facing memory pressure itself. It's
> > > expected that auto-inflate and auto-deflate will balance each
> > > other over time.
> > 
> > What does this last line mean?
> 
> When qemu does auto-inflate, the guest memory will be reduced. Then it's
> expected that something will increase it again. That something is
> auto-deflate.
> 
> However, if we deflate too much, than the host may face memory pressure,
> and then auto-inflate will take place again.
> 
> It's expected that that sequence of auto-inflate and auto-deflate will
> reach a balance in some point in time.

This all depends on the loads on the systems and other external
factors; we never know how things might behave.  Let's just leave this
line out.

> > How about emitting a QMP message to notify
> > management of auto-ballooning?
> 
> I could think about that if they are interested.

I think they would be - no harm in asking.

> > >    o this shouldn't override balloon changes done by the user manually
> > 
> > Can you think of examples here?  If the user (host admin) has
> > ballooned an 8G guest down to 4G, auto-balloon will only further
> > shrink down the guest RAM, so there's no real 'overriding' happening
> > that I can think of.  Of course, a guest can expand itself to, say,
> > 5G, but that should be allowed as the guest might be under pressure.
> 
> Yes, that's exactly my point above. I mean, taking your example, if
> the user has ballooned an 8G down to 4G, should auto-balloon be allowed
> to balloon to 5G or even back to 8G?

I think it should be allowed by default, and tunable by
user/management (i.e. qemu shouldn't create policy, but enforce one if
provided).

                Amit