Announcement

Collapse
No announcement yet.

AMD P-State Fixes & Other Power Management Changes For Linux 6.6

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

  • AMD P-State Fixes & Other Power Management Changes For Linux 6.6

    Phoronix: AMD P-State Fixes & Other Power Management Changes For Linux 6.6

    The ACPI and power management updates were merged last week for the Linux 6.6 kernel...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    6.6 is going to be an interesting release for sure.

    Comment


    • #3
      The TEO idle thing puzzles me. From my understanding, it's an idle governor, and I'm not sure if it's default.

      I'd love to know how it compares vs its alternatives on recent AMD, Intel hardware, and if it is or will be the default for everything.

      Comment


      • #4
        Originally posted by Mitch View Post
        The TEO idle thing puzzles me. From my understanding, it's an idle governor, and I'm not sure if it's default.

        I'd love to know how it compares vs its alternatives on recent AMD, Intel hardware, and if it is or will be the default for everything.
        I'm pretty sure the default on x86 is the menu governor. It's the only one compiled into the kernel on Fedora. Ubuntu kernels also include ladder and teo. From various mailing list discussions, it sounds like TEO is widely used on Android. Here's the kernel documentation, and a couple lwn articles about TEO and potential refinements to it. I don't know what the current state of the weighted TEO work is or how far it got, but as of a recent patch (kernel 6.3), TEO started taking CPU utilization into account as well, to prefer shallower sleep states on lightly-loaded systems. The discussions around that patch set include quite a bit of debate and benchmarks.
        ‚Äč
        For some reason it seems like the kernel community has a lot more enthusiasm for sophisticated cpuidle governors than cpufreq governors, to the point that users are widely advised to replace the kernel's default schedutil governor with performance, and AMD and Intel have both managed to beat it with embedded controller solutions that have no way of knowing about threads or the dependencies between them.

        Comment

        Working...
        X