From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] Re: KVM call agenda for Apr 27 Date: Tue, 27 Apr 2010 09:01:08 -0500 Message-ID: <4BD6EE24.8050105@codemonkey.ws> References: <20100426172634.GC15278@x200.localdomain> <4BD5D28C.7080700@codemonkey.ws> <20100426221258.GH15278@x200.localdomain> <4BD61584.9080208@codemonkey.ws> <4BD6A61C.3010100@redhat.com> <4BD6E229.60501@codemonkey.ws> <4BD6E41E.7070106@redhat.com> <4BD6E4D0.1030905@codemonkey.ws> <4BD6E9C1.4090209@redhat.com> <4BD6EB16.5060102@codemonkey.ws> <4BD6ED6A.9020803@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Chris Wright , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Kevin Wolf Return-path: Received: from mail-px0-f174.google.com ([209.85.212.174]:58917 "EHLO mail-px0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755726Ab0D0OBR (ORCPT ); Tue, 27 Apr 2010 10:01:17 -0400 Received: by pxi17 with SMTP id 17so2167109pxi.19 for ; Tue, 27 Apr 2010 07:01:16 -0700 (PDT) In-Reply-To: <4BD6ED6A.9020803@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 >