On Thu, 07 Jan 2010 10:56:19 -0600 Anthony Liguori <anth...@codemonkey.ws> wrote:
> On 01/07/2010 10:39 AM, Avi Kivity wrote: > > On 01/07/2010 06:27 PM, Adam Litke wrote: > >> > >>> I think 'info-balloon' should be synchronous and without side-effects. > >>> ie return the current stats that QEMU has. We could then add a separate > >>> 'refresh-balloon' command + async event notification when that > >>> completes. > >>> The tool that is requiring the stats could thus refresh as often as it > >>> likes. > >> This would work well for the QMP case, but what about for a traditional > >> monitor? We could include a sequence number or timestamp in the memory > >> stats results so the user could tell that they were updated. This > >> doesn't seem very user friendly though > > > > A user would have an easier time logging into the guest and using its > > native tools. I'm not sure I agree with that, running 'info balloon' in the Monitor is more convenient than logging specially if you're testing something related to balloon. > Yeah, without objections, I like having info-balloon attempt to refresh > stats, timeout after 10s, and return the last reported stats. I think > it also satisfies danpb's criteria of not wasting cpu cycles polling. I like Daniel's idea too. In practice 'refresh-balloon' is going to be Anthony's idea #1 for the QMP case, which seems the right way to do it with QMP. The only problem though is the user Monitor. Ideally handlers should not try to know if they are in QMP or not. I would be ok with that in this case, but if we get more asynchronous handlers doing this we will really need an better interface for that.
