From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42310) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rp7XO-00015g-PR for qemu-devel@nongnu.org; Sun, 22 Jan 2012 19:13:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rp7XN-0004vB-KJ for qemu-devel@nongnu.org; Sun, 22 Jan 2012 19:13:30 -0500 Received: from e32.co.us.ibm.com ([32.97.110.150]:51341) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rp7XN-0004uu-CF for qemu-devel@nongnu.org; Sun, 22 Jan 2012 19:13:29 -0500 Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sun, 22 Jan 2012 17:13:23 -0700 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 2DA421FF0050 for ; Sun, 22 Jan 2012 17:12:52 -0700 (MST) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q0N0Cq2u146196 for ; Sun, 22 Jan 2012 17:12:53 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q0N0CqjK018399 for ; Sun, 22 Jan 2012 17:12:52 -0700 Message-ID: <4F1CA602.2020103@linux.vnet.ibm.com> Date: Sun, 22 Jan 2012 18:12:50 -0600 From: Michael Roth MIME-Version: 1.0 References: <1327108107-16600-1-git-send-email-mdroth@linux.vnet.ibm.com> <1327166033-17922-1-git-send-email-mdroth@linux.vnet.ibm.com> <20120121203923.GE4871@jl-vm1.vm.bytemark.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] main-loop: For tools, initialize timers as part of qemu_init_main_loop() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org On 01/22/2012 06:32 AM, Paolo Bonzini wrote: > On 01/21/2012 09:39 PM, Jamie Lokier wrote: >> Is this a timer that need to fire soon after setting, every time? >> >> I wonder if a different kind of Windows timer, lower-resolution, could >> be used if the timeout is longer. If it has insufficient resolution, >> it could be set to trigger a little early, then set a high-resolution >> timer at that point. >> >> Maybe that could help for Linux CONFIG_NOHZ guests? > > No, it's an implementation detail of Windows multimedia timers. Just > enabling them apparently burns CPU. > > There is another kind of timers for Windows but it didn't work reliably. > Finding out why would be the right fix, but anyway I'd looked into timer queues, which the developer docs suggested had deprecated the use of mm timers, but I came across this which I figured was why mm was preferred (%30 average error for a 50ms periodic/oneshot) by the QEMU code: http://www.virtualdub.org/blog/pivot/entry.php?id=272 Apparently Windows 7 has some fixes for drift that makes them reasonable for a clock source, but still fairly low-res for an event timer. I suppose we could use some historical timer data to adaptively determine a reasonable minimum resolution to set...basically if the last timer fired X ns ago, we'd configure the resolution to be 1/10th of that periodic or whatever, and start them off low-res as James suggested to avoid unnecessary CPU burn, but it's a pretty loose heuristic. > > Reviewed-by: Paolo Bonzini > > Paolo > >