[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [qemu-s390x] qemu-system-s390x slowdown (regression ?) with qemu v4.
Re: [qemu-s390x] qemu-system-s390x slowdown (regression ?) with qemu v4.0.0
Wed, 12 Jun 2019 15:48:41 -0700
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
> 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
in my build of qemu v4.0, and an extra
in my build of mainline qemu. After dropping the debug options, it is as
fast as before.
Sorry for the noise.