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

[Guenter Roeck]

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.

Guenter