Re: [Qemu-devel] [PATCH 6/6] qmp: add balloon-get-memory-stats & event

[Michael Roth <mdroth@linux.vnet.ibm.com>]

On Wed, Feb 22, 2012 at 05:44:37PM -0200, Luiz Capitulino wrote:
> On Wed, 22 Feb 2012 10:54:45 -0600
> Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> 
> > But I'm not suggesting we make query-balloon asynchronous.
> > 
> > I'm suggesting be re-enable it as a synchronous interface by having it
> > immediately return the latest-available results from a timer-driven
> > query mechanism that tucks away the query results, such as the one Anthony
> > suggested.
> 
> I'm not sure I like the semantics, as query-balloon would have some fields
> that actually depends on a timer based polling being enabled somewhere else,
> while others fields ('actual') would always be there.

I think that's more a side-effect of sticking stats unrelated to
ballooning in query-balloon in the first place... but yah, maybe it
makes the interfaces not worth reviving.

> 
> > > But that's a dead discussion I guess, as I already agreed on implementing
> > > this as a device property.
> > 
> > Along with timer-based refresh of the properties? If so I don't understand why we
> > can't just have query-balloon simply return those properties when it's called? I
> > thought that's what Anthony was driving at with the timer-based
> > approach.
> 
> What I had understood is to make each stats a dynamic device property, then
> mngt apps would use qom-set/get on them.

Ahhhh, yah... you're probably right. And we get that for free by tieing
the data to properties, which I guess is where the significance of QOM
was wrt to the polling approach (since we could actually stick the data
anywhere if we did something like query-balloon).

I don't really have any objection there, my main concern was that we
were gonna be adding something *beyond* qom-get or query-balloon, but if
that's not the case, carry on :)

> 
> Anthony, can you detail your suggestion please?
>