Announcement

Collapse
No announcement yet.

PowerTop, AMD CPUFreq CPPC & Other Power Tests From The Ryzen 9 3900X On Linux

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

  • PowerTop, AMD CPUFreq CPPC & Other Power Tests From The Ryzen 9 3900X On Linux

    Phoronix: PowerTop, AMD CPUFreq CPPC & Other Power Tests From The Ryzen 9 3900X On Linux

    Continuing on from last week's testing that found the AMD Ryzen 9 3900X + ASUS CROSHAIR VIII HERO WiFi consuming more power on Linux compared to Windows 10, here are some additional metrics after spending a good deal of time over the weekend on further tests...

    http://www.phoronix.com/scan.php?pag...00X-More-Power

  • #2
    Call me crazy, but in the last chart I am not able to tell which line is which because both lines are the same color.

    Comment


    • #3
      Some also suggested, that it could be bugs in the motherboard firmware's handling of ACPI. Do you have this in dmesg?

      Code:
      ACPI: [Firmware Bug]: BIOS _OSI(Linux) query
      If yes, possibly ACPI isn't working as intended. Which can result in all kind of power related issues. So you can try overriding the name, making firmware think it's Windows. See: https://wiki.archlinux.org/index.php/DSDT

      For example I get the above on Asrock X370 Taichi, but not on X570 one.
      Last edited by shmerl; 09-03-2019, 11:38 AM.

      Comment


      • #4
        Originally posted by shmerl View Post
        Some also suggested, that it could be bugs in the motherboard firmware's handling of ACPI. Do you have this in dmesg?

        Code:
        ACPI: [Firmware Bug]: BIOS _OSI(Linux) query
        If yes, possibly ACPI isn't working as intended. Which can result in all kind of power related issues. So you can try overriding the name, making firmware think it's Windows. See: https://wiki.archlinux.org/index.php/DSDT

        For example I get the above on Asrock X370 Taichi, but not on X570 one.
        Nope, didn't have that firmware bug line.
        Michael Larabel
        http://www.michaellarabel.com/

        Comment


        • #5
          I have:
          Code:
          ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
          PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
          An X570 motherboard here.

          Comment


          • #6
            my asus laptop with zen 1 has problems with power comsumption too and it is not zen 2..
            other thing is that CPPC new driver is for zen 1 and future families, not only for zen 2 and the future, it is a fail that is being repeated these days.
            my question is about new amd cpufreq driver.. will there be a new amd_idle driver too? like intel ones

            Comment


            • #7
              Originally posted by shmerl View Post
              Some also suggested, that it could be bugs in the motherboard firmware's handling of ACPI. Do you have this in dmesg?

              Code:
              ACPI: [Firmware Bug]: BIOS _OSI(Linux) query
              If yes, possibly ACPI isn't working as intended. Which can result in all kind of power related issues. So you can try overriding the name, making firmware think it's Windows. See: https://wiki.archlinux.org/index.php/DSDT

              For example I get the above on Asrock X370 Taichi, but not on X570 one.
              not present for me with x470 taichi

              Comment


              • #8
                Originally posted by shmerl View Post
                Some also suggested, that it could be bugs in the motherboard firmware's handling of ACPI. Do you have this in dmesg?

                Code:
                ACPI: [Firmware Bug]: BIOS _OSI(Linux) query
                If yes, possibly ACPI isn't working as intended. Which can result in all kind of power related issues. So you can try overriding the name, making firmware think it's Windows. See: https://wiki.archlinux.org/index.php/DSDT

                For example I get the above on Asrock X370 Taichi, but not on X570 one.
                That's not necessarily a bug, in fact the kernel is intentionally ignoring the "_OSI(Linux)" call because it's led to Linux-specific BIOS/firmware bugs in the past. A kernel engineer explains in this bug report: https://bugs.launchpad.net/ubuntu/+s...x/+bug/1275985

                Comment


                • #9
                  Michael
                  Could You please also do a test with the "schedutil" governor, since it has become very clear now that this is the future & will be the only option left in Linux!

                  We're trying to move all cpufreq into the scheduler and have only a single governor, namely schedutil -- yes, we're still stuck with legacy, and we're still working on performance parity in some cases, but I really hope to get rid of all other cpufreq governors eventually.
                  https://lkml.org/lkml/2019/7/13/86

                  Comment


                  • #10
                    Typo?

                    Comment

                    Working...
                    X