Re: [Qemu-devel] Re: KVM call agenda for Apr 27

[Anthony Liguori <anthony@codemonkey.ws>]

On 04/27/2010 08:42 AM, Kevin Wolf wrote:
> Am 27.04.2010 15:21, schrieb Anthony Liguori:
>    
>> On 04/27/2010 08:18 AM, Kevin Wolf wrote:
>>      
>>> The watermark is not some complex computed value, but actually the
>>> statistic itself. We can get rid of handling a threshold in qemu by just
>>> signalling "something has changed with this stat".
>>>
>>> I'm really not arguing that qemu should do anything complex or even
>>> define policy. It's just about avoiding polling all the time when
>>> nothing has changed and polling too late when things are changing quickly.
>>>
>>>
>>>        
>>>> Polling is really the right solution.  It gives the management tool
>>>> ultimate flexibility in tweaking the heuristics as they see fit.
>>>>
>>>>          
>>> Isn't providing this flexibility completely orthogonal to polling vs.
>>> event-based?
>>>
>>>        
>> Except then we need to offer a generic statistics mechanism which seems
>> like it's going to add a fair bit of complexity.  So far, the only
>> argument for it seems to be a misplaced notion that "polling is evil".
>>      
> I'm not sure if "adding events is evil" is a much better position. :-)
>
> The natural thing is really events here, because we want to get informed
> every time something changes.

You want to be informed every time something has changed and the value 
has met a boolean condition (value > threshold).

>   Polling is a workaround for cases where
> you can't get these events. So I think it's you who should explain why
> polling is so much better than using events.
>    

Polling gives a management tool more flexibility in implementing the 
evaluation condition.

Adding something to the protocol is a long term support statement.  We 
shouldn't add events unless we think they are events that we'll want to 
support in the long term.  If RHEV-M decides that instead of doing value 
 > threshold, they want to include additional information (maybe 
factoring in I/O rate), then a new event needs to be added and we're 
stuck supporting the old event forever.

Polling lets us avoid introducing new protocol operations as heuristics 
change.

> Note that IIUC the case is here different from the ballooning you
> mentioned. The statistics for ballooning change all the time and you
> don't want to get informed about changes but monitor the statistics all
> the time, right?

No, generally speaking, you care about threshold conditions.  For 
instance, you want to know when guest reported free memory is < some 
percentage of total memory.  It's very similar really.

>   This is indeed a scenario where polling seems more
> natural. But in contrast, the watermark usually doesn't change most of
> the time and we want to know when changes happen.
>    

Regards,

Anthony Liguori

> Kevin
>