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),
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? -- Jamie
