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: Adam Litke
Subject: [Qemu-devel] Re: [RFD] virtio: Add memory statistics reporting to the balloon driver
Date: Thu, 07 Jan 2010 09:39:42 -0600

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





reply via email to

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