From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6l9C-0000qy-Ox for qemu-devel@nongnu.org; Tue, 27 Apr 2010 09:48:22 -0400 Received: from [140.186.70.92] (port=34933 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6l98-0000qN-3C for qemu-devel@nongnu.org; Tue, 27 Apr 2010 09:48:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6l91-0006nb-Qu for qemu-devel@nongnu.org; Tue, 27 Apr 2010 09:48:16 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:33120) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6l91-0006nR-MT for qemu-devel@nongnu.org; Tue, 27 Apr 2010 09:48:11 -0400 Received: by vws3 with SMTP id 3so708932vws.4 for ; Tue, 27 Apr 2010 06:48:10 -0700 (PDT) Message-ID: <4BD6EB16.5060102@codemonkey.ws> Date: Tue, 27 Apr 2010 08:48:06 -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> In-Reply-To: <4BD6E9C1.4090209@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: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 >