On Thu, Jan 07, 2010 at 09:12:10AM -0600, Anthony Liguori wrote: > On 01/05/2010 11:08 AM, Adam Litke wrote: > >This patch has been discussed (and ACKed) in the past, but has not yet > >been committed due to the congestion surrounding the 0.12 release and > >other conflicting changes. I would like to rekindle the discussion so > >that I can make the necessary changes to get this merged. > > > >This patch is ported to 0.12.1 and has one issue that I am aware of: > > > >It still calls monitor_suspend() and monitor_resume() which I understand > >is no longer allowed. Does anyone have any ideas on how to enable async > >monitor commands? > > > >+static void request_stats(VirtIOBalloon *vb) > >+{ > >+ vb->stats_requested = 1; > >+ reset_stats(vb); > >+ monitor_suspend(cur_mon); > > > > This bit is not going to work reliably anymore. Really, it never worked > reliably but this is exacerbated with -qmp since a QMP session will > never be the cur_mon. > > We have a couple of options: > > 1) Introduce a query-balloon command that returns immediately, and > triggers a request for the guest to update the balloon stats. When the > guest does update the balloon stats, trigger an asynchronous message. > Asynchronous messages are ignored by the human monitor so they would > never be displayed there which is unfortunate. > > 2) Make info balloon show the last valid stats and have it request new > stats. Stats will always be delayed but it avoids async messages. > > 3) Make qemu request balloon stats regularly (maybe every 10 seconds) > and display the latest stats with info balloon. This avoids the problem > in #2 but it means that qemu determines the poll rate instead of a > management tool.
I don't like the idea of the anything which has hardcoded polling because it just wastes CPU cycles for the 99% of the time when no one is going to care about these stats. > 4) Make info-balloon a proper asynchronous command. We need new > infrastructure to allow a qmp handler to take a callback that can be > used to delay the completion of the command. This addresses all of the > above problems but it introduces a new one. Command completion now > depends on the guest. This potentially could trip up a naive management > tool that doesn't realize that the info-balloon command may never complete. 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. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|