On 01/07/2010 09:18 AM, Avi Kivity wrote:
On 01/07/2010 05:12 PM, Anthony Liguori wrote:
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.
Can I tip you over to #4? #3 means we have no idea when the stats
were generated. With #4, we can't be sure, but it usually be close to
when the command returns.
The command should include a timeout so a broken guest won't hang a
management tool thread.
Generally, timeouts are evil but if we did something like, wait 10
seconds and if we don't hear a response from the guest, return the last
data set, I think I would be okay with that. It means we may be
reporting stale data, but at the same time, the data is coming from a
guest so it can't be considered authoritative anyway.
Regards,
Anthony Liguori
