Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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?pag...e-Kern-Regress

  • #2
    Originally posted by Xaero_Vincent
    Could this be due to more hardening against Intel CPU vulnerabilities around LV, Meltdown, Foreshadow, etc.?
    As written in the article, no.
    Michael Larabel
    http://www.michaellarabel.com/

    Comment


    • #3
      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

      Comment


      • #4
        Originally posted by FPScholten View Post
        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.
        Last edited by stormcrow; 22 April 2020, 01:54 PM.

        Comment


        • #5
          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.

          Comment


          • #6
            Originally posted by DanL View Post
            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.

            Comment


            • #7
              Originally posted by zerothruster View Post
              But I dunno about your weather, in this part of England the weather is warming up again.
              Michael's based in Indiana, USA, chap

              Comment


              • #8
                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
                Code:
                sudo systemctl disable ondemand
                Next boot your system will remain in performance mode.

                Comment


                • #9
                  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?
                  Last edited by kcrudup; 23 April 2020, 02:40 PM.

                  Comment


                  • #10
                    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/*

                    Comment

                    Working...
                    X