From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/4] Rework alarm timer infrastrucure - take2 Date: Sun, 19 Aug 2007 11:24:18 +0300 Message-ID: <46C7FE32.4050309@qumranet.com> References: <20070817231149.544849769@gmail.com> <1187450256.13580.1.camel@squirrel> <64F9B87B6B770947A9F8391472E032160D4645F0@ehost011-8.exch011.intermedia.net> <20070818220252.GA19526@dreamland.darkstar.lan> <1187481505.15472.3.camel@squirrel> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-TtF/mJH4Jtrk1uMJSBkQmQ@public.gmane.org, qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org To: Anthony Liguori Return-path: In-Reply-To: <1187481505.15472.3.camel@squirrel> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Anthony Liguori wrote: > I think this is a really nice and important patch set. Just a couple > things: > > On Sun, 2007-08-19 at 00:02 +0200, Luca Tettamanti wrote: > > >>> In this case the dyn-tick minimum res will be 1msec. I believe it should >>> work ok since this is the case without any dyn-tick. >>> >> Actually minimum resolution depends on host HZ setting, but - yes - >> essentially you have the same behaviour of the "unix" timer, plus the >> overhead of reprogramming the timer. >> > > Is this significant? At a high guest HZ, this is could be quite a lot > of additional syscalls right? > > At HZ=1000, this adds a small multiple of 1000 syscalls, which is a fairly small overhead. At HZ>1000 (only possible with a dyntick guest), the current implementation doesn't cope at all, so we can't compare overhead. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IMg4s-0000Xj-ST for qemu-devel@nongnu.org; Sun, 19 Aug 2007 04:24:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IMg4s-0000XL-BK for qemu-devel@nongnu.org; Sun, 19 Aug 2007 04:24:06 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IMg4s-0000XH-8a for qemu-devel@nongnu.org; Sun, 19 Aug 2007 04:24:06 -0400 Received: from il.qumranet.com ([82.166.9.18]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IMg4r-0006LI-Pf for qemu-devel@nongnu.org; Sun, 19 Aug 2007 04:24:06 -0400 Message-ID: <46C7FE32.4050309@qumranet.com> Date: Sun, 19 Aug 2007 11:24:18 +0300 From: Avi Kivity MIME-Version: 1.0 References: <20070817231149.544849769@gmail.com> <1187450256.13580.1.camel@squirrel> <64F9B87B6B770947A9F8391472E032160D4645F0@ehost011-8.exch011.intermedia.net> <20070818220252.GA19526@dreamland.darkstar.lan> <1187481505.15472.3.camel@squirrel> In-Reply-To: <1187481505.15472.3.camel@squirrel> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2 Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: kvm-devel@lists.sf.net, Luca Tettamanti , qemu-devel@nongnu.org Anthony Liguori wrote: > I think this is a really nice and important patch set. Just a couple > things: > > On Sun, 2007-08-19 at 00:02 +0200, Luca Tettamanti wrote: > > >>> In this case the dyn-tick minimum res will be 1msec. I believe it should >>> work ok since this is the case without any dyn-tick. >>> >> Actually minimum resolution depends on host HZ setting, but - yes - >> essentially you have the same behaviour of the "unix" timer, plus the >> overhead of reprogramming the timer. >> > > Is this significant? At a high guest HZ, this is could be quite a lot > of additional syscalls right? > > At HZ=1000, this adds a small multiple of 1000 syscalls, which is a fairly small overhead. At HZ>1000 (only possible with a dyntick guest), the current implementation doesn't cope at all, so we can't compare overhead. -- error compiling committee.c: too many arguments to function