On Sat, Jan 21, 2012 at 11:13:53AM -0600, Michael Roth wrote:
> In some cases initializing the alarm timers can lead to non-negligable
> overhead from programs that link against qemu-tool.o. At least,
> setting a max-resolution WinMM alarm timer via mm_start_timer() (the
> current default for Windows) can increase the "tick rate" on Windows
> OSs and affect frequency scaling, and in the case of tools that run
> in guest OSs such has qemu-ga, the impact can be fairly dramatic
> (+20%/20% user/sys time on a core 2 processor was observed from an idle
> Windows XP guest).
>
> This patch doesn't address the issue directly (not sure what a good
> solution would be for Windows, or what other situations it might be
> noticeable), but it at least limits the scope of the issue to programs
> that "opt-in" to using the main-loop.c functions by only enabling alarm
> timers when qemu_init_main_loop() is called, which is already required
> to make use of those facilities, so existing users shouldn't be
> affected.
>
> Signed-off-by: Michael Roth <mdr...@linux.vnet.ibm.com>
> ---
> main-loop.c | 2 +-
> main-loop.h | 12 ++++++++++++
> qemu-tool.c | 3 ++-
> vl.c | 5 +++++
> 4 files changed, 20 insertions(+), 2 deletions(-)
static struct qemu_alarm_timer alarm_timers[] = {
#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"?
mm_start_timer() is using 1 ms intervals!
Stefan
