qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: [Qemu-devel] Re: [RFD] virtio: Add memory statistics reporting to the balloon driver
Date: Thu, 07 Jan 2010 09:12:10 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]