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

[David Hildenbrand]

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".

Cheers!

> 
>>
>> Thanks,
>> Guenter
>>
> 


-- 

Thanks,

David / dhildenb