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
