Re: [Qemu-devel] Re: [RFD] virtio: Add memory statistics reporting to the balloon driver

[Daniel P. Berrange]

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 :|