OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [virtio] New virtio balloon...

On Tue, 4 Feb 2014 22:09:32 +0100
Daniel Kiper <daniel.kiper@oracle.com> 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] | [List Home]