qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] 4 CPUs with vexpress is slow?


From: Frederic Konrad
Subject: Re: [Qemu-devel] 4 CPUs with vexpress is slow?
Date: Tue, 23 Jun 2015 00:10:26 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

On 22/06/2015 22:57, Peter Maydell wrote:
On 22 June 2015 at 19:18, Frederic Konrad <address@hidden> wrote:
Testing MTTCG patch-set performance I found strange slowness with _upstream_
qemu (46bca5404b08201bb9df1ac32bc88fc7e6db1f74).

Basically booting a vexpress-a15 with "-smp 4" takes approximately forever
if I use a
vexpress-v2p-ca15-tc1.dtb (2x A15) dtb and 39 secs if I hack this dtb to
have 4 CPUs.
Wait, so if you change the dtb it boots in a non-infinite time,
but MTTCG boots both dtbs?
Yes MTTCG boots both dtbs.

This is definitely strange because if I use "-smp 2" with the same guest
image it takes
only 4 secs. And MTTCG patch-set seems to fix the issue as it boot in 6 secs
with
"-smp 4".

Is that a known issue or maybe it's my guest (linux 3.13.5)?
Dunno. I basically never run with SMP configs because they're
always slower than uniprocessor... Does your kernel boot on
KVM? It may be that it's configured to assume 2xSMP somehow,
given the h/w we're modelling here is 2xSMP.

Important question: when you boot this config, does /proc/cpuinfo
say you have two cores booted, or all four? If we've ended up with
the other two cores in the config spinning then that would explain
why MTTCG is doing better here, but it's not a very interesting
config to try to optimise :-)
All four cores are in /proc/cpuinfo.


There is an issue where IPIs may be inefficient:
http://lists.nongnu.org/archive/html/qemu-devel/2015-06/msg03824.html
but I'd expect that to merely slow things down a bit, not send
the boot time off to infinity.

This is definitely a bug :
Seems that removing "--nographic" option removes the problem it just boots as per
normal..

Fred


-- PMM




reply via email to

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