Dell XPS 7390 Intel Ice Lake Performance Hit Hard By A Linux Kernel Regression

[phoronix]

Phoronix: Dell XPS 7390 Intel Ice Lake Performance Hit Hard By A Linux Kernel Regression

At the beginning of the month I wrote about the Dell XPS with Core i7 1065G7 Ice Lake running much slower when upgrading to the development release of Ubuntu 20.04 LTS from 19.10. It turns out the performance hit is due to an upstream kernel regression that's thrashing the performance...

http://www.phoronix.com/scan.php?page=news_item&px=Dell-XPS-Ice-Lake-Kern-Regress

[Michael]

Could this be due to more hardening against Intel CPU vulnerabilities around LV, Meltdown, Foreshadow, etc.?

As written in the article, no.

[FPScholten]

Just something tat happened to me, when updating to 5.6.5-xanmod1 my laptop (Intel Haswell 4700MQ based) became very sluggish. Something had changed in the scheduler, it was still on intel_pstate, but in passive mode. Normally this should mean that the normal CPUfreq schedulers are being used.
But in my case this resulted in the CPU being stuck on its lowest frequency, no matter what scheduler was chosen.
The issue was solved in 5.6.6
Have you checked if the scheduler is correctly using the pstates? is it in active or passive mode? does changing mode make a difference?
you can set it here: /sys/devices/system/cpu/intel_pstate
it accepts: active passive off
Changes are directly applied to the intel_pstate driver

[stormcrow]

Just something tat happened to me, when updating to 5.6.5-xanmod1 my laptop (Intel Haswell 4700MQ based) became very sluggish. Something had changed in the scheduler, it was still on intel_pstate, but in passive mode. Normally this should mean that the normal CPUfreq schedulers are being used.
But in my case this resulted in the CPU being stuck on its lowest frequency, no matter what scheduler was chosen.
The issue was solved in 5.6.6
Have you checked if the scheduler is correctly using the pstates? is it in active or passive mode? does changing mode make a difference?
you can set it here: /sys/devices/system/cpu/intel_pstate
it accepts: active passive off
Changes are directly applied to the intel_pstate driver

I had a similar problem with the 8300H in my Dell laptop back in 18.04.x. No matter which power state algorithm was used for the kernel in the stock setup, which used thermald, the laptop would quickly lock itself to its minimum CPU frequency of 800 MHz. I eventually replaced thermald with a different power/thermal manager and that fixed the problem. I don't know if Michael has pursued the bug may not be in the kernel or it could be in both the power management daemon and the kernel... or one exposes a bug in the other. Might be worth a look to eliminate an incompatibility of some sort between hardware, thermal daemon, and kernel.

Edit: I think it's worth noting that there's some anecdotal evidence that Dell may use customized thermal settings in some of the XPS developer's line. If those aren't upstreamed they may not be in the generic Ubuntu 20.04 distribution from Canonical.

[DanL]

C'mon Michael, take advantage of the cold weather, find a cool spot for the laptop and have at it. Have your tried 5.4-rc kernels? That may narrow down the bisecting.

[zerothruster]

C'mon Michael, take advantage of the cold weather, find a cool spot for the laptop and have at it. Have your tried 5.4-rc kernels? That may narrow down the bisecting.

Well, if Michael was running 5.4.0 then that could be a possible approach. But I sort-of assumed he was running a recent-ish stable 5.4 point release. If that is the case, bug compatability with Linus is the stable kernel's target, so perhaps bisecting in the 5.4 stable tree might be useful.

But I dunno about your weather, in this part of England the weather is warming up again.

[DanL]

But I dunno about your weather, in this part of England the weather is warming up again.

Michael's based in Indiana, USA, chap

[FPScholten]

Oh by the way, about the intel_pstate setting in ubuntu.
The kernel itself is compiled with the Performance setting as default. This is also the state when booting Ubuntu.
However there is a systemd service that is activated 1 minute after booting that sets the governor to powersave on Intel machines with intel_pstate or to ondemand on systems using acpi_cpufreq.
The service name is ondemand. To disable this service just run

sudo systemctl disable ondemand

Next boot your system will remain in performance mode.

[kcrudup]

Michael : I have the 2-in-1 version of this laptop, and build my own kernels using an optimized defconfig file that's been tailored to hardware on the device.

I haven't "felt" any of these speed regressions, and I tend to build every few days or so as I track Linus' master branch. If I were to send you my custom defconfig file, could/would you try running these tests again with it? I have a few changes from the generic kernel that comes with Ubuntu distros, namely building for Core2+ chips (I actually build with `-march=icelake-client` via a Makefile change) and only have the pstate "performance" and "powersave" governors enabled (as well as as using the "TEO' governor and turning off mitigations like Retpoline).

Alternatively, are these tests all part of the PTS, and is that something I can download(/build)/run on my own?

[vasu_1970]

Hi Michael,
I am trying to debug this issue. I have a same laptop but don't see issue.
Could you please send this output to check if power limits got messed up:

#grep . /sys/class/powercap/intel-rapl-mmio/intel-rapl-mmio\:0/*