qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] QEMU ARM SMP: IPI delivery delayed until next main loop


From: Frederic Konrad
Subject: Re: [Qemu-devel] QEMU ARM SMP: IPI delivery delayed until next main loop event // how to improve IPI latency?
Date: Tue, 23 Jun 2015 09:31:46 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

On 19/06/2015 17:53, Peter Maydell wrote:
On 16 June 2015 at 12:53, Peter Maydell <address@hidden> wrote:
In particular I think the
'do cpu_exit if one CPU triggers an interrupt on another'
approach is probably good, but I need to investigate why
it isn't working on your test programs without that extra
'level &&' condition first...
I've figured out what's happening here, and it's an accidental
artefact of our GIC implementation. What happens is:

  * cpu 0 does an IPI, which turns into "raise IRQ line on cpu 1"
  * arm_cpu_set_irq logic causes us to cpu_exit() cpu 0
  * cpu 1 does then run; however pretty early on it does a read
    on the GIC to acknowledge the interrupt
  * this causes the function gic_update() to run, which recalculates
    the current state and sets CPU interrupt lines accordingly;
    among other things this results in an unnecessary but harmless
    call to arm_cpu_set_irq(CPU #0, irq, 0)
  * without the "level && " clause in the conditional, that causes
    us to cpu_exit() cpu 1
  * we then start running cpu 0 again, which is pointless, and
    since there's no further irq traffic we don't yield til 0
    reaches the end of its timeslice

So basically without the level check we do make 0 yield to 1
as it should, but we then spuriously yield back to 0 again
pretty much immediately.

Next up: see if it gives us a perf improvement on Linux guests...

-- PMM

Hi,

Can you send me a complete diff?

I might have reproduced the same bug during MTTCG speed comparison.
http://lists.nongnu.org/archive/html/qemu-devel/2015-06/msg05704.html

The normal boot with "-smp 4" and a smp 4 guest is slow and become a lot faster
when I enable the window (which have timer callbacks and refresh the screen
regularly)

Thanks,
Fred



reply via email to

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