Re: [Qemu-devel] [Qemu-trivial] [PATCH] main-loop: For tools, initialize timers as part of qemu_init_main_loop()

[Paolo Bonzini]

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