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 08:48:06 -0500 Message-ID: <4BD6EB16.5060102@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> 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-vw0-f46.google.com ([209.85.212.46]:46631 "EHLO mail-vw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753163Ab0D0NsL (ORCPT ); Tue, 27 Apr 2010 09:48:11 -0400 Received: by vws13 with SMTP id 13so838773vws.19 for ; Tue, 27 Apr 2010 06:48:10 -0700 (PDT) In-Reply-To: <4BD6E9C1.4090209@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 >