Announcement

Collapse
No announcement yet.

Intel's P-State Driver Does Seem To Be In Bad Shape On Linux 4.6~4.7

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

  • Intel's P-State Driver Does Seem To Be In Bad Shape On Linux 4.6~4.7

    Phoronix: Intel's P-State Driver Does Seem To Be In Bad Shape On Linux 4.6~4.7

    A few days ago when delivering benchmarks of the new CPUFreq "Schedutil" governor in Linux 4.7 the P-State comparison results on this Git kernel looked particularly terrible. I've since done some P-State tests on the same system using the Linux 4.5 and 4.6 kernels that further point towards a regression having taken place...

    http://www.phoronix.com/scan.php?pag...4.6-Regression

  • #2
    +1 for auto-bisect

    Also +1 to auto-bisect for the recent Intel GPU performance boost

    Comment


    • #3
      +1 for both
      ## VGA ##
      AMD: X1950XTX, HD3870, HD5870
      Intel: GMA45, HD3000 (Core i5 2500K)

      Comment


      • #4
        +1 too
        specially because i am on an intel i5-5200u on p-state and kernel 4.6

        Comment


        • #5
          +1 to pstate auto-bisect,

          not sure how difficult it's for the systems to recover with GPU auto-bisect (in case the system doesn't boot, etc.)

          Comment


          • #6
            I remember a couple year ago, when RadeonSI was slower than r600g, and one day when Michael did benchmark and there were a 20% improvement or so, only to later doing a post about the bisect and discover that it was a change on P-State that led to that improvement.

            That news and the one that Marek discover that not every engine or something on RadeonSI was being initialised, and with a couple changes RadeonSI was on par to r600g performance.

            Awesome news

            Comment


            • #7
              +1
              If someone is not aware powersave in case of pstate works like an odemand for other drivers.

              Comment


              • #8
                P-State has never worked correctly for me. The default behavior seems to be "run at maximum possible turbo frequency" (3.5 GHz) and after CPU overheats, "drop down to lowest possible frequency" 100-200 MHz.

                Comment


                • #9
                  +1 too
                  Rob
                  email: [email protected]

                  Comment


                  • #10
                    With Haswell Refresh on Arch due to the config Hz=300 as compared to Ubuntu and SUSE's 250, frequency even at idle has always been full turbo. I have been on CPUFREQ for long unless I am in Ubuntu and have never had any performance issue in Arch due to that.

                    Comment

                    Working...
                    X