Thanks for the ideas and feedback. I will play around with #4 and see if I can hack up a prototype.
On Thu, 2010-01-07 at 09:22 -0600, Anthony Liguori wrote: > 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 -- Thanks, Adam
