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

[Anthony Liguori <anthony@codemonkey.ws>]

On 04/27/2010 08:58 AM, Kevin Wolf wrote:
> Am 27.04.2010 15:48, schrieb Anthony Liguori:
>    
>> 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.
>>      
> This is what I meant with the flexibility being orthogonal to polling
> vs. event-based. You're comparing apples and oranges.
>
> You can either compare sending an event when value>  threshold with
> polling a boolean that says if this threshold is reached. Or you can
> compare sending an event on changes with polling the absolute value. But
> comparing sending an event on a threshold to polling the absolute value
> mixes two different things.
>    

But is statistic change really useful?  During a guest install, you'd 
get hundreds and hundreds of these events.

>>> 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.
>>      
> Hm, maybe implementing something generic with thresholds actually
> wouldn't be a bad idea then.
>
> But still you have the fact that it's changing all the time which is
> very different from the watermark. The watermark only ever grows and
> often doesn't change at all. So the watermark thing can live without
> thresholds, it's enough to get informed about any changes.
>    

It actually changes quite often early in it's lifetime.

Regards,

Anthony Liguori

> Kevin
>