Re: [virtio] New virtio balloon...

[Daniel Kiper <daniel.kiper@oracle.com>]

On Tue, Feb 04, 2014 at 12:24:48PM +1030, Rusty Russell wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> > On Mon, Feb 03, 2014 at 02:29:36PM +0100, Daniel Kiper wrote:
> >> On Sun, Feb 02, 2014 at 06:21:14PM +0200, Michael S. Tsirkin wrote:
> >> > On Fri, Jan 31, 2014 at 04:01:39PM +1030, Rusty Russell wrote:
> >> > > That's very hard to define across guests.  Should we be using stats for
> >> > > that instead?  In fact, should we allow gratuitous stats sending,
> >> > > instead of a simple NEED_MEM flag?
> >>
> >> I think that it should be simple as possible. Guest just set new target and host
> >> fulfill request or not. Guest slow down requests from balloon if requests cannot
> >> be fulfilled some time. That is all.
> >
> > Hmm that's exactly the reverse of what Rusty suggests.
>
> Indeed.  The current balloon is entirely host-led.  There's no way for

Maybe I am missing something but I am curious why we would like to avoid
symmetric solution. I mean that guest and host could control the target.
Such solution is used in Xen balloon driver.

> the guest to give feedback except by failing to meet the target.
>
> This proposal only modifies that so that the guest can send "need_mem"
> and associated stats.  These stats are fairly generic, so should be
> OS-agnostic (and a guest can omit them if it can't tell).
>
> > Guest has best knowledge how to calculate
> >  memory needs.
>
> True, but not actually useful.
>
> The guest has the most information, but it still can't reliably predict
> the effect of adding more memory.  Because last time I read the
> literature, that problem was Very Hard.  I would *love* a heuristic so
> that the guest can say "if you give me X MB, page faults will drop by
> 50%", but think in practice everyone just increments a few MB at a time
> until the pain stops, right?
>
> But even if we had such a thing, the guest has NO IDEA how bad its
> problems are, because bad is relative.  So it has to have a way of

You mean in comparison to other guests?

> reporting its pain level to the host, who *can* balance things.
>
> I chose to use stats + "need_mem" flag reporting for that method.  But
> if the host doesn't increase the target, the guest should not disobey.

So if I understand correctly we are going in such direction that only
host could control the target and guest may only gently ask for more
memory. Right? However, as I can see we do not have a mechanism to
directly reject guest requests for more memory. So how guest would
know that its needs would not be fulfilled at all or they will be
fulfilled partially? How long guest should wait for target change?
If it does not have such information directly from a host then it
does not have a chance to quickly limit impact of memory pressure
in other way. So I think that the host should have a chance to reject
guests request directly or inform that a given request will be fulfilled
partially. This way guest will have a chance to make relevant actions
(if it use such information).

Daniel