"Michael S. Tsirkin" <> 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
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
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.
Cheers,
Rusty.
