Linux 5.5 Seeing Some Wild Swings In Performance - Improvements But Also Regressions

[phoronix]

Phoronix: Linux 5.5 Seeing Some Wild Swings In Performance - Improvements But Also Regressions

While there still is a week to go in the Linux 5.5 merge window with more feature code still landing, due to scheduler changes and other work already having landed, I already started running some Git benchmarks. Linux 5.5 at this stage appears quite volatile with some really nice improvements in some workloads but also regressions in others...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-5.5-Early-Performance

[tildearrow]

Typo:

Meanwhile, Hackbenck, Rodinia, and Parboil all showed improvements off Linux 5.5 Git.

[ms178]

I hope Linus will move on to one of the new Threadripper chips, at least he was thinking about moving on to the 3950X. That would hopefully improve the testing on AMD hardware, the data here implies more regressions on AMD than on Intel if I am not mistaken.

[aufkrawall]

As a side note: default mitigations + intel-ucode butcher my octane 2 score in Firefox by 25% on my 6700k. To hell with this crap...

[johnp117]

Michael Both sides of the X-axis have positive values, shouldn't one of them be negative?

Edit: Or I just misunderstood the graphs... Is the baseline just the respective other version compared to the direction of the result?

[Linuxxx]

As a side note: default mitigations + intel-ucode butcher my octane 2 score in Firefox by 25% on my 6700k. To hell with this crap...

I know how You feel...

However, we as Intel victims are not completely helpless:

Recently, I have found out why passing

intel_pstate=disable

to the kernel leads to such drastic improvements in performance & latency:

From the RedHat Low-Latency tuning guide:

intel_pstate=disable prevents the Intel idle driver from managing power state and CPU frequency.

So all along it was Intel's IDLE driver that was the culprit, not the P-State driver!
This finally explains why Intel systems always felt so sluggish, even though I was always using the Performance governor while also setting the so-called Perf-Bias to zero for maximum performance-bias!

Seriously Intel, are you doing this on purpose?

[aufkrawall]

Linuxxx Perhaps you encounter some specific bug? I can't feel nor measure a difference between intel_pstate=performance, acpi-cpufreq-performance and both blocked at the same time (btw. absolutely same total system consumption while total idle as powersave). Though intel_pstate=powersave behaves badly and causes stuttering everywhere with that 6700k.
Sad, but true: Linux default settings run like crap vs. Windows default settings in these regards.

[perpetually high]

Recently, I have found out why passing

intel_pstate=disable

to the kernel leads to such drastic improvements in performance & latency:

From the RedHat Low-Latency tuning guide:

So all along it was Intel's IDLE driver that was the culprit, not the P-State driver!
This finally explains why Intel systems always felt so sluggish, even though I was always using the Performance governor

Whoa, you led me down a good rabbit hole thanks.

I was previously experimenting with acpi-cpufreq schedutil vs intel_pstate's performance on my Haswell, and had recently found out about setting the intel_pstate kernel boot parameter, but I was using intel_pstate=passive, which lets you use cpufreq (allowing for schedutil, ondemand, etc instead of just pstate's powersave and performance), BUT it was intel_cpufreq, which I had not realized until your post that it wasn't acpi_cpufreq.

Ok, so now I added intel_pstate=disable to my GRUB but when I rebooted, it wasn't using _any_ governor! (verified with the command: sudo cpupower frequency-info).

I quickly duck'd it (aka searched duckduckgo) and found this StackOverflow thread that hinted to check the BIOS and enable SpeedStep as acpi-cpufreq requires that. I went into my MSI bios and changed the CPU Ratio mode from Fixed to Dynamic, which set EIST to Enabled (which I believe is SpeedStep), saved the BIOS, rebooted and alas! acpi_cpufreq was now enabled, and I set it to performance, and you are correct, I think it is quicker.

I figured it shouldn't have mattered if I was using intel_cpufreq performance or acpi_cpufreq performance since the former had all four of my cores (i5-4670K @ 4.3GHz) to 4300 MHz, and thought that's the best I can get, but acpi-cpufreq does feel faster. Would be great if we can get some benchmarks to back up these claims, but for now, I'm rocking with acpi-cpufreq performance over intel_cpufreq performance.

[birdie]

Michael Both sides of the X-axis have positive values, shouldn't one of them be negative?

Edit: Or I just misunderstood the graphs... Is the baseline just the respective other version compare to the direction of the result?

I'm also confused by these graphs. I see 5.5 being faster by 50% in some tests and 5.4 being faster by 50% in others - this looks like a huge regression.

It would be a lot easier to understand if baseline was one of the kernels, not something which I don't understand.

[Michael]

I'm also confused by these graphs. I see 5.5 being faster by 50% in some tests and 5.4 being faster by 50% in others - this looks like a huge regression.

Right some tests are ~50% faster, others ~50% slower. I am working on bisecting the biggest ones right now.