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}, #endifIt 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
