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-dev] Re: Straw linux/lguest implementation of new "memballoon"


On (Mon) 02 Jun 2014 [13:14:32], Rusty Russell wrote:
> Amit Shah <amit.shah@redhat.com> writes:
> > On (Wed) 28 May 2014 [17:09:16], Rusty Russell wrote:
> >> You're right.  I've deleted that sentence; we need to have a discussion
> >> on whether stats are actually valuable as they are today.
> >
> > What would a guest admin allow a host admin to know?
> > 1. How much memory the guest was started with
> > 2. Did the guest ask for extra pages (negative balloon)
> > 3. What is the size of the current balloon
> 
> Well, the host knows all these things.
> 
> > In addition, a host admin would like to know (well, it'd like to know
> > a lot more, but being realistic):
> > 4. Did the guest refuse to give it memory when asked?  How many times?
> > 5. Did the guest voluntarily give up memory when not asked for (min
> >    going beyond the min balloon)
> 
> It knows this, too.

Yep, I'm just listing out what will be needed on the host for us to
mention in the spec.  So far, nothing has come up that requires us to
put anything specific here.

> The legacy ballon stats interface published stats about the guest VM,
> such as:
> 
> #define VIRTIO_BALLOON_S_SWAP_IN  0   /* Amount of memory swapped in */
> #define VIRTIO_BALLOON_S_SWAP_OUT 1   /* Amount of memory swapped out */
> #define VIRTIO_BALLOON_S_MAJFLT   2   /* Number of major faults */
> #define VIRTIO_BALLOON_S_MINFLT   3   /* Number of minor faults */
> #define VIRTIO_BALLOON_S_MEMFREE  4   /* Total amount of free memory */
> #define VIRTIO_BALLOON_S_MEMTOT   5   /* Total amount of memory */

I feel these are more suited for a debug / perf interface rather than
the balloon -- nothing here is really needed for the functioning of
the balloon itself; nor are these stats going to matter in a host's
decision as to how much memory it asks from a guest.

> With the guest controlling the balloon, it's not clear these are needed.

So looks like we're just fine w/o a stats interface.

> >> > Also, if a device gives control of 2 out of 5 requested pages, which
> >> > pages were the ones the device gave back?
> >> 
> >> The first two.
> >
> > Should this be explicit?  I think so.
> 
> Yes:

Thanks, looks good.


		Amit


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