[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: trasmussen
Subject: Re: [Qemu-discuss] Using 2.5 multicore and the qemu (qemu-system-ppc64) is never sleeping - more information
Date: Tue, 5 Jul 2016 15:08:18 +0200

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!


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.)

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]