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, 04 Feb 2014 11:53:57 +1030
Rusty Russell <rusty@au1.ibm.com> wrote:

> Luiz Capitulino <lcapitulino@redhat.com> writes:
> > On Mon, 03 Feb 2014 13:37:17 +1030
> >> I changed the STATS_REPLY to STATS, and included a "want more mem"
> >> flag.  The implication is that the host compare stats across different
> >> guests.
> >
> > When would the host do that? Can you elaborate a bit how this would
> > be used?
> >
> > I feel that what you're proposing is not far away from automatic
> > ballooning. Basically, my current idea for automatic ballooning more or
> > less is:
> 
> Yes, this is to enable automatic ballooning, as per your lkml posting.
> Here's how it maps onto your case:
> 
> >  1. QEMU registers for vmpressure events in the host 
> >     (see Documentation/cgroups/memory.txt "Memory Pressure" section)
> >
> >  2. The virtio-balloon driver in the guest registers for
> >     in-kernel memory pressure notification (not upstream yet)
> >
> >  3. When the host is under pressure, QEMU is notified and it asks the
> >     guest to inflate its balloon by some amount
> 
> This would mean the host changing the balloon target, ie
> VIRTIO_BALLOON_HCMD_SET_BALLOON.

OK.

> >  4. When the guest is under pressure, QEMU is notified by the
> >     virtio-balloon driver and QEMU asks the guest to deflate by
> >     some value
> 
> This would mean guest sending stats with the "need_mem" flag to true,
> and the host changing the balloon target.
> 
> > Now, doing one inflate/deflate per event is not very good. I'm trying
> > to find a way where we use the amount of events to determine:
> >
> >  A. When memory should be moved from the guest to the host
> >
> >  B. When memory should be moved from the host to the guest
> >
> >  C. When memory shouldn't move (ie. when both guest and host experience
> >     similar pressure)
> 
> That's what the stats are for, to give QEMU an indication of the size of
> the crisis.  If that's not sufficient, the stats are not doing their
> job.

I'm not against having the stats, but I'm not sure we can use it to do what
you propose. Mainly because by the time QEMU receives the stats and decides
what to do, I wonder whether the picture may be different in the guest.

Besides, I agree with mst. If we're going to use the stats to refuse an
inflate for example, I think that the guest is in a better place to do that.

> Even the "need_mem" flag is a reluctant crutch: QEMU should be able to
> see that the target should be increased from the stats alone.
> 
> > Note that there's no "central authority" that has information about
> > all guests to decide how do that. Each qemu instance has to decide it
> > itself, based on the information it has about the host and about its guest.
> 
> True today, but higher layers may eventually exist which can do this, or
> may exist on other platforms.
> 
> Cheers,
> Rusty.
> 



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