From: Frederic Konrad <fred.konrad@greensocs.com>
To: "Peter Maydell" <peter.maydell@linaro.org>,
"Alex Züpke" <alexander.zuepke@hs-rm.de>
Cc: QEMU Developers <qemu-devel@nongnu.org>
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 [thread overview]
Message-ID: <55890B62.2060305@greensocs.com> (raw)
In-Reply-To: <CAFEAcA9WVd3EFjnUVOneYYn-hL2N1wWPvGWcYbce63QYUAMXEg@mail.gmail.com>
On 19/06/2015 17:53, Peter Maydell wrote:
> On 16 June 2015 at 12:53, Peter Maydell <peter.maydell@linaro.org> 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
next prev parent reply other threads:[~2015-06-23 7:31 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-12 16:38 [Qemu-devel] QEMU ARM SMP: IPI delivery delayed until next main loop event // how to improve IPI latency? Alex Züpke
2015-06-12 18:03 ` Peter Maydell
2015-06-15 14:44 ` Alex Züpke
2015-06-15 14:51 ` Peter Maydell
2015-06-15 15:05 ` Alex Züpke
2015-06-15 18:41 ` Peter Maydell
2015-06-15 18:58 ` Peter Maydell
2015-06-15 20:03 ` Alex Zuepke
2015-06-16 10:33 ` Peter Maydell
2015-06-16 10:59 ` Peter Maydell
2015-06-16 11:11 ` Alex Züpke
2015-06-16 11:53 ` Peter Maydell
2015-06-16 12:21 ` Alex Züpke
2015-06-19 15:53 ` Peter Maydell
2015-06-23 7:31 ` Frederic Konrad [this message]
2015-06-23 8:09 ` Peter Maydell
2015-06-23 8:33 ` Frederic Konrad
2015-06-23 18:15 ` Peter Maydell
2015-06-25 17:13 ` Peter Maydell
2015-06-15 15:04 ` Peter Maydell
2015-06-15 15:07 ` Alex Züpke
2015-06-15 15:18 ` Peter Maydell
2015-06-15 15:36 ` Alex Züpke
2015-06-15 15:49 ` Peter Maydell
2015-06-15 16:12 ` Alex Züpke
2015-06-15 21:39 ` Peter Crosthwaite
2015-06-19 16:57 ` Paolo Bonzini
2015-06-19 17:25 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55890B62.2060305@greensocs.com \
--to=fred.konrad@greensocs.com \
--cc=alexander.zuepke@hs-rm.de \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.