[Qemu-discuss] Using 2.5 multicore and the qemu (qemu-system-ppc64) is n
From:
trasmussen
Subject:
[Qemu-discuss] Using 2.5 multicore and the qemu (qemu-system-ppc64) is never sleeping
Date:
Mon, 4 Jul 2016 16:04:15 +0200
I am using QEMU 2.5.0 with a 4 core set
up and was expecting that the load of the system would be minimal, as none
of the 4 core cpus are really doing anything. Each is awating a core specific
timer interrupt, writes a few characters to the QEMU screen, and then waits
for the next timer interrupt.
What I see is that the QEMU-process
is running at full rate (12,5% = 1 entire core-cpu out of 8 in a Windows7
environment).
The previous QEMU version I ran with
(0.14.50) was hardly showing any load, so it must have managed to put the
QEMU core(s) to sleep, but 2.5 just hammers off cpu time, probably polling
rather than "Windows-waiting".
I have tried to track what is going
on, but had to give up, as this appears to be very complex.
The cpus.c source in the qemu_wait_io_event_common()
function has this code:
while (all_cpu_threads_idle())
{
/* Start
accounting real time to the virtual clock if the CPUs
are
idle. */
qemu_clock_warp(QEMU_CLOCK_VIRTUAL);
qemu_cond_wait(cpu->halt_cond,
&qemu_global_mutex);
}
When all 4 cores are idle the qemu_clock_warp()
function decides that the clock can 'warp', but here I would have thought
that the loop should have been exited, so we could get to the nearest 'waiting-point'
to fall asleep, until an interrupt would wake us up again. Instead we stay
inside this loop, until one of the cpus is not idle anymore.
I have experimentally tried to exit
the while-loop when the qemu_clock_warp() function finds out that it can
'warp', but it made no difference.
The only place I can see where the cpus
might be sleeping is inside main-loop.c inside the os_host_main_loop_wait()
function (or called from that), but the word 'poll' is all over the place,
so I fear it is polling until the wait is done, and not awaiting a Windows
selective wait call for interrupts or other events.
My question is therefore: Does 2.5 offer
a way at all for the cores to Windows-sleep (wait) until an event occurs?
As written above this used to work with
0.14.50, so I would think it was possible.
Right now this appears to be an unnecessary
waste of power, and my i7 laptop gets noticably hot when the core QEMU
is running inside is totally monopolized.