[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio] New virtio balloon...
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]