From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IMkYV-0001BR-Iq for qemu-devel@nongnu.org; Sun, 19 Aug 2007 09:10:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IMkYU-0001AG-LP for qemu-devel@nongnu.org; Sun, 19 Aug 2007 09:10:58 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IMkYU-00019p-6j for qemu-devel@nongnu.org; Sun, 19 Aug 2007 09:10:58 -0400 Received: from mail.shareable.org ([81.29.64.88]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IMkYU-00015L-0m for qemu-devel@nongnu.org; Sun, 19 Aug 2007 09:10:58 -0400 Date: Sun, 19 Aug 2007 14:10:42 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2 Message-ID: <20070819131042.GA22798@mail.shareable.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46C7FE32.4050309@qumranet.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: kvm-devel@lists.sourceforge.net, Luca Tettamanti 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. -- Jamie