Re: [Qemu-discuss] Using 2.5 multicore and the qemu (qemu-system-ppc64) is never sleeping

[Peter Maydell]

On 4 July 2016 at 15:04,   wrote:
> 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.

Some suggestions to try to narrow things down:

(1) Does this happen on the current QEMU git master ?
(2) Does this happen on Linux hosts as well, or only Windows hosts?

(The set of people who care and are in a position to track down this
kind of bug for Linux hosts is much much larger, so being able to
say "this is not a windows bug" is worth doing.)

thanks
-- PMM

Re: [Qemu-discuss] Using 2.5 multicore and the qemu (qemu-system-ppc64) is never sleeping

[Jakob Bohm]

On 04/07/2016 16:04, trasmus...@ddci.com wrote:
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, _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.


Kind regards

Thorkil B. Rasmussen

I am not completely familiar with the qemu source code, however
qemu_cond_wait() looks a lot like the POSIX call
pthread_cond_wait(), which should release the host CPU until
"halt_cond" is signalled by another thread.  If this is it's
purpose, but if it keeps looping anyway, then maybe there is
something wrong with the Windows port of qemu_cond_wait().

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Qemu-discuss] Using 2.5 multicore and the qemu (qemu-system-ppc64) is never sleeping

[trasmussen]

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, _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.

Kind regards

Thorkil B. Rasmussen