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

[David Hildenbrand]

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.

Cheers!

> 
> Guenter
> 


-- 

Thanks,

David / dhildenb