[Top][All Lists]

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

Re: [qemu-s390x] qemu-system-s390x slowdown (regression ?) with qemu v4.

From: David Hildenbrand
Subject: Re: [qemu-s390x] qemu-system-s390x slowdown (regression ?) with qemu v4.0.0
Date: Fri, 14 Jun 2019 10:33:42 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

On 13.06.19 00:48, Guenter Roeck wrote:
> On Wed, Jun 12, 2019 at 10:58:26PM +0200, David Hildenbrand wrote:
>> On 12.06.19 22:37, Cornelia Huck wrote:
>>> On Wed, 12 Jun 2019 13:03:30 -0700
>>> Guenter Roeck <address@hidden> wrote:
>>>> Hi,
>>>> I noticed that qemu-system-s390x is much slower when running qemu v4.0.0
>>>> vs. qemu v3.1.0. Specifically, on a system with Ryzen 2700X, a boot test
>>>> has a runtime of ~25 seconds with qemu v3.1.0, but ~67 seconds with qemu
>>>> v4.0.0.  Mainline qemu as of today (6/12) is even worse, with a runtime
>>>> of ~73 seconds.
>>> This doesn't sound good...
>>>> All of this is booting exactly the same kernel and root file system.
>>>> All qemu versions are compiled locally with gcc 6.5.0, with the same
>>>> configuration options enabled.
>>> Can you share how you build your kernel (e.g. for which architecture
>>> level) and how you start QEMU (do you specify any cpu model)?
>>>> Is this a known problem ?
>>> I'm not aware of any; cc:ing David and Richard in case they are aware
>>> of something in s390x tcg that might slow things down.
>> I did notice the slowdown from 3.1.0 -> 4.0 while working on VX patches.
>> After rebasing my patches at one point, booting Linux took significantly
>> longer.
>> Back then, I did a short profiling of QEMU and it "smelled" like JIT'ed
>> code (especially Python in the guest) got horribly slow. Especially
>> cloud-init takes ages to start (I uninstall it usually right away ;) ).
>> At that time, no other work on the s390x TCG side was really going on,
>> so this would rather have to be some common-code TCG stuff.
>> @Richard are you aware of any changes that might especially harm JIT'ed
>> code in the guest? We might be able to bisect this.
>> The drop from 4.0 -> mainline could simply be VX (vector instruction)
>> patches kicking it, which is expected to be slower in some scenarios
>> (especially when FP instructions e.g. in libm use vector instructions
>> for scalar FP calculations). You could test if this is indeed the case
>> by configuring "-cpu qemu,vx=off".
> Meh. It was all a false alarm, caused by a leftover
>       --enable-debug --disable-strip
> in my build of qemu v4.0, and an extra
>       --extra-cflags=-g
> in my build of mainline qemu. After dropping the debug options, it is as
> fast as before.
> Sorry for the noise.

Maybe I was experiencing debug slowdown due to "--enable-debug-tcg" back
then as well :)

Good to hear that it's working for you as expected.


> Guenter



David / dhildenb

reply via email to

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