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.
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'm on the fence between 3 and 4 myself.
Regards,
Anthony Liguori
