I recently found out that without kvm enabled, and especially
with -smp 2 or greater, qemu becomes incredibly slow
(to the point that you can see kernel messages in the
quest print one character at a time).
This happens with a Linux host (even with -smp 1)
and with FreeBSD host (in this case -smp 2 or greater;
-smp 1 seems to work fine there).
Bisecting points to this commit as the culprit:
commit b1bbfe72ec1ebf302d97f886cc646466c0abd679
Author: Alex Bligh <a...@alex.org.uk>
Date: Wed Aug 21 16:02:55 2013 +0100
aio / timers: On timer modification, qemu_notify or aio_notify
On qemu_mod_timer_ns, ensure qemu_notify or aio_notify is called to
end the appropriate poll(), irrespective of use_icount value.
On qemu_clock_enable, ensure qemu_notify or aio_notify is called for
all QEMUTimerLists attached to the QEMUClock.
Signed-off-by: Alex Bligh <a...@alex.org.uk>
Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com>
I could not revert this individual commit into master because
of other changes, but i notice that
one key
changes of the commit
was
to
ma
k
e a
call to timerlist_notify() unconditional, whereas
before
it was controlled by the
"
use_icount
"
variable.
So I tried the small patch below and it seems to restore the original
performance, but I have no idea what use_icount does and
whether the change makes sense.
If not, there is an open problem.
Any ideas ?
cheers
luigi
d
iff --git a/qemu-timer.c b/qemu-timer.c
index e15ce47..4180a86 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -380,6 +380,7 @@ static void timerlist_rearm(QEMUTimerList *timer_list)
{
/* Interrupt execution to force deadline recalculation. */
qemu_clock_warp(timer_list->clock->type);
+if (use_icount) // XXX
timerlist_notify(timer_list);
}
