From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6lMX-0005qE-7h for qemu-devel@nongnu.org; Tue, 27 Apr 2010 10:02:09 -0400 Received: from [140.186.70.92] (port=58970 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6lM1-0005lL-1j for qemu-devel@nongnu.org; Tue, 27 Apr 2010 10:02:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6lLh-0000pj-Ft for qemu-devel@nongnu.org; Tue, 27 Apr 2010 10:01:24 -0400 Received: from mail-pw0-f45.google.com ([209.85.160.45]:39543) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6lLh-0000ou-Ai for qemu-devel@nongnu.org; Tue, 27 Apr 2010 10:01:17 -0400 Received: by pwi6 with SMTP id 6so8535378pwi.4 for ; Tue, 27 Apr 2010 07:01:16 -0700 (PDT) Message-ID: <4BD6EE24.8050105@codemonkey.ws> Date: Tue, 27 Apr 2010 09:01:08 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: KVM call agenda for Apr 27 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> In-Reply-To: <4BD6ED6A.9020803@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Chris Wright , qemu-devel@nongnu.org, kvm@vger.kernel.org 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 >