OASIS Open Mailing List Archives  ·  All Lists  ·  virtio  ·  2014-02

virtio — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

New virtio balloon...


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. 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. > 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]  |  [Month Index]  |  [List Home]