From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48695) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rqgsr-0005zR-2X for qemu-devel@nongnu.org; Fri, 27 Jan 2012 03:10:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rqgsl-0004Zp-75 for qemu-devel@nongnu.org; Fri, 27 Jan 2012 03:10:09 -0500 Sender: Paolo Bonzini Message-ID: <4F225BD3.4090300@redhat.com> Date: Fri, 27 Jan 2012 09:09:55 +0100 From: Paolo Bonzini 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> <20120127054606.GC17836@stefanha-thinkpad.localdomain> In-Reply-To: <20120127054606.GC17836@stefanha-thinkpad.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-trivial] [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: Stefan Hajnoczi Cc: qemu-trivial@nongnu.org, Michael Roth , qemu-devel@nongnu.org On 01/27/2012 06:46 AM, Stefan Hajnoczi wrote: > #ifndef _WIN32 > #ifdef __linux__ > {"dynticks", dynticks_start_timer, > dynticks_stop_timer, dynticks_rearm_timer}, > #endif > {"unix", unix_start_timer, unix_stop_timer, unix_rearm_timer}, > #else > {"mmtimer", mm_start_timer, mm_stop_timer, mm_rearm_timer}, > {"dynticks", win32_start_timer, win32_stop_timer, win32_rearm_timer}, > #endif > > It seems Windows host already has a "dynticks" implementation. Have you > tried using this instead of "mmtimer"? The dynticks Win32 timer doesn't boot Linux successfully, even though under Wine it works and it is actually more reliable than mmtimer (which is why I haven't thrown it away yet). > mm_start_timer() is using 1 ms intervals! No, it's setting a 1 ms system quantum via timeBeginPeriod. The actual implementation is using dynamic rather than periodic ticks (it has a rearm callback). We threw away periodic timers a few months ago. The problem is that Windows doesn't have something like Linux NOHZ and limits the timer resolution to the system quanta. That's 1 ms for mmtimer and 10 ms (the default) for dynticks right now. However, I suspect that the solution is to move timeBeginPeriod and timeEndPeriod from timer code to generic QEMU code, dynticks would start working on native Windows too. Besides possibly fixing QEMU, it would definitely fix Michael's problem, too. Tools do not need such a fine-grained timer, and shorter quanta cause the increased CPU usage that Michael observed. However, Michael's patch makes sense as a cleanup anyway. Since we have an initialization function, there's no need to have that _and_ a constructor. Paolo