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

[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.

> 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
>