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

[trasmussen]

I have now "time traced" the
(at least) two threads where sleeping is possible.

One is the "emulation-thread"
that discovers that all cpus are idle, and which then enters qemu_cond_wait().
In here I have ascertained that WaitForSingleObject() is waiting about
80% of each period - which is pretty much what I had hoped to see.

The other thread is the "main-loop-thread"
that calls into main_loop_wait(). That thread does not seem to ever
stop to breathe. It calls Win32's select(), but never waits in there, unless
we talk about small stuff like < 300 usecs. It is the thread that calls
polling functions incessantly. I am not quite sure what it is actually
doing, since the only things that may change for the os_host_main_loop_wait()
is the tv0-value which is a local static. It does not appear to be very
Windows-specific what goes on here, so maybe people with more insight into
this function's expected behavior can tell how it may be made to sleep
at least some time. My "time tracing" shows that the os_host_main_loop_wait()
function is called about every 250 usecs, and only rarely are we waiting
more than 250 usecs, and this could be due to longer running polling-functions
as well.

Any guidance here to sleep more in the
"main-loop-thread" when it calls os_host_main_loop_wait()  would
be greatly appreciated!

Thanks!




From:      
 Peter Maydell <address@hidden>
To:      
 address@hidden
Cc:      
 qemu-discuss <address@hidden>
Date:      
 04-07-2016 21:56
Subject:    
   Re: [Qemu-discuss]
Using 2.5 multicore and the qemu (qemu-system-ppc64) is never sleeping
Sent by:    
   "Qemu-discuss"
<address@hidden>

---

On 4 July 2016 at 15:04,  <address@hidden>
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