virtio — archive

New virtio balloon...

From: Rusty Russell <[email protected]>
To: [email protected]
Date: Thu, 06 Feb 2014 01:01:00 -0000

Luiz Capitulino <[email protected]> writes: > On Wed, 05 Feb 2014 14:07:33 +1030 > Rusty Russell <[email protected]> wrote: > >> Luiz Capitulino <[email protected]> writes: >> > On Tue, 4 Feb 2014 22:09:32 +0100 >> > Daniel Kiper <[email protected]> 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.