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

[Adam Litke]

On Thu, 2010-01-07 at 15:49 +0000, Daniel P. Berrange wrote:
> 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.

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.

-- 
Thanks,
Adam