diff options
author | Michael Roth | 2012-01-21 18:13:53 +0100 |
---|---|---|
committer | Anthony Liguori | 2012-02-01 21:45:02 +0100 |
commit | d34e8f6e9d3a396c3327aa9807c83f9e1f4a7bd7 (patch) | |
tree | 02c78a7b8b95cf5da36f5a7e6dec710b1444a6ec /linux-headers/asm-powerpc | |
parent | main-loop: Fix SetEvent() on uninitialized handle on win32 (diff) | |
download | qemu-d34e8f6e9d3a396c3327aa9807c83f9e1f4a7bd7.tar.gz qemu-d34e8f6e9d3a396c3327aa9807c83f9e1f4a7bd7.tar.xz qemu-d34e8f6e9d3a396c3327aa9807c83f9e1f4a7bd7.zip |
main-loop: For tools, initialize timers as part of qemu_init_main_loop()
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.
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Diffstat (limited to 'linux-headers/asm-powerpc')
0 files changed, 0 insertions, 0 deletions