From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IMl8J-0007jD-0S for qemu-devel@nongnu.org; Sun, 19 Aug 2007 09:47:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IMl8H-0007if-C1 for qemu-devel@nongnu.org; Sun, 19 Aug 2007 09:47:58 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IMl8H-0007ic-2M for qemu-devel@nongnu.org; Sun, 19 Aug 2007 09:47:57 -0400 Received: from il.qumranet.com ([82.166.9.18]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IMl8G-00079u-Nr for qemu-devel@nongnu.org; Sun, 19 Aug 2007 09:47:57 -0400 Message-ID: <46C84A16.7040305@qumranet.com> Date: Sun, 19 Aug 2007 16:48:06 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [kvm-devel] [Qemu-devel] Re: [PATCH 0/4] Rework alarm timer infrastrucure - take2 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> <46C7FE32.4050309@qumranet.com> <20070819131042.GA22798@mail.shareable.org> In-Reply-To: <20070819131042.GA22798@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: kvm-devel@lists.sourceforge.net, qemu-devel@nongnu.org Jamie Lokier wrote: > Avi Kivity 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. >> > > Small, but maybe measurable. > > That overhead could be removed if the dyn-tick code were to > predictively set the host timer into a repeating mode when guests do > actually require a regular tick. > > I'm thinking when it detects it needed a tick a small number of times > in a row, with the same interval, it could set the host timer to > trigger repeatedly at that interval. Then it wouldn't need to reprogram > if that stayed the same (except maybe to correct for drift?) > > If a tick then _wasn't_ required for that interval (i.e. it was > required for less, more, or not at all), then it would have to > reprogram the host timer. If it really mattered, it wouldn't have to > reprogram the host timer when the next required tick is further in the > future or not at all; it would simply be a redundant SIGALRM. In > weird cases that's worthwhile, but I suspect it generally isn't. > > Yes, good thinking, but this should only be done if it actually impacts something. Reducing overhead from 0.1% to 0.05% is not worthwhile if it introduces extra complexity. -- error compiling committee.c: too many arguments to function