Luiz Capitulino <> writes:
> On Wed, 05 Feb 2014 14:07:33 +1030
> Rusty Russell <> wrote:
>
>> Luiz Capitulino <> writes:
>> > On Tue, 4 Feb 2014 22:09:32 +0100
>> > Daniel Kiper <> wrote:
>> >
>> >> > 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.
>> >
>> > Honest question: do we need one? Or better, why would we want to reject
>> > a guest's request?
>> >
>> > With automatic ballooning for example, if the host is not able to supply
>> > a guest's need of memory, it would try to reclaim it from other guests.
>> > If this fails, the host goes through regular memory reclaim.
>>
>> And if that fails? What if there really isn't memory to give? It might
>> really be under stress.
>
> In this case, would it be better for the guests to swap instead of
> having the host to swap? If so, then yes I agree that maybe the guest
> should be able to say no.
s/guest/host/? I think we're agreeing.
>> > Guests, on the other hand, need a way to refuse the host's request, at
>> > least temporarily, so that guests with enough free (or freeeable cached)
>> > memory have a chance to return memory to the host.
>>
>> The guest doesn't know if the administrator has added a much more
>> important guest which needs all the memory, or if the memory savings
>> should be shared across multiple guests.
>>
>> So if the host wants it to meet the target slowly, it should lower the
>> target slowly. And monitor the stats to see how its progressing.
>>
>> Note that the committed_as variable (which is used by HyperV and xen's
>> selfballoon apparently) *isn't* exposed through the stats, and it seems
>> it should be. That seems to be the variable of choice?
>
> I honestly don't know whether it's a good idea for the host to take balloon
> decisions based on guest's stats. When I say host here I mean QEMU. IMO,
> the guest can do this faster and more accurately than QEMU.
I don't know either. A call out to qemu is pretty fast, at least
compared with swapping a page.
> On another note, I'm getting a bit confused with this discussion. IMHO not
> all requirements are clear and I'm seeing you throwing code in... Maybe we
> should start by doing the spec instead? This might help us concentrate on
> providing the mechanisms only.
I thought we were closer to consensus than we are. But providing a
strawman implementation highlighted our differences, so it's not a
complete waste :)
Cheers,
Rusty.
