From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6l3w-0007X8-TY for qemu-devel@nongnu.org; Tue, 27 Apr 2010 09:42:56 -0400 Received: from [140.186.70.92] (port=56822 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6l3v-0007W5-EF for qemu-devel@nongnu.org; Tue, 27 Apr 2010 09:42:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6l3u-0005x3-11 for qemu-devel@nongnu.org; Tue, 27 Apr 2010 09:42:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13514) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6l3t-0005wz-Pb for qemu-devel@nongnu.org; Tue, 27 Apr 2010 09:42:53 -0400 Message-ID: <4BD6E9C1.4090209@redhat.com> Date: Tue, 27 Apr 2010 15:42:25 +0200 From: Kevin Wolf 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> In-Reply-To: <4BD6E4D0.1030905@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Chris Wright , qemu-devel@nongnu.org, kvm@vger.kernel.org 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. 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. 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? 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. Kevin