New AMD P-State Driver Headlines The Power Management Updates For Linux 5.17

[shmerl]

According to some AMD people the only benefit of the AMD P-State driver is a fine-grained control over the CPU frequency. It is supposed to help in situations where you have some kind of power vs. performance target that you need to hit. I guess that it will mostly benefit server farms with arrays of EPYC servers; consumer-grade laptops or workstations won't see any meaningful difference.

I expect to see longer battery life on laptops from this if it will work as intended. So surely should be good for regular users too.

[shmerl]

Same here, Turned on CPPC in the bios and set the appropriate flags in grub as mentioned by skeevy420 , but still don't see the cppc flag turned on. Since xanmod has the p-state driver built in, will try my VM workload using schedutil and see if it helps.

As discussed in the previous post, cppc flag doesn't appear in cpuinfo for regular Ryzens for some reason (someone commented in only appears for APUs).

You can check whether CPPC is exposed with something like this:

sudo cp /sys/firmware/acpi/tables/SSDT* .
chown $USER:$USER SSDT*
iasl -d SSDT*
rg CPC *.dsl

That should produce a bunch of entries like this:

Name (_CPC, Package (0x17) // _CPC: Continuous Performance Control

Not sure yet whether that alone is good enough for this new code to use (haven't tested it yet).

[darkbasic]

The idea is to only run the CPU as fast as you need to hit your work deadline.

This means nothing to me, how does it determine if/how to meet your deadline? If you're running a sustained workload your deadline is to finish it ASAP, otherwise you're wasting your money on a faster CPU which you're actually not using.

[shmerl]

This means nothing to me, how does it determine if/how to meet your deadline? If you're running a sustained workload your deadline is to finish it ASAP, otherwise you're wasting your money on a faster CPU which you're actually not using.

Not every workload requires finishing it ASAP. Or to put it differently, not every workload requires CPU to run at max frequency to produce sufficient responsiveness. As commented above, if you need everything ASAP - switch to performance mode (max boost), but that will make battery life an irrelevant concern.

[agd5f]

This means nothing to me, how does it determine if/how to meet your deadline? If you're running a sustained workload your deadline is to finish it ASAP, otherwise you're wasting your money on a faster CPU which you're actually not using.

If you are working a document in a word processor or doing some web browsing, there no need to ramp the the CPU to the max frequency constantly every time that task schedules. The user experience of working with that document will be the same whether or not the CPU is at the max frequency or not. As I said, the tricky part is deciding what the right algorithm is in the governor. These patches just provide the knobs. The governors still dictate the performance.

[Linuxxx]

This means nothing to me, how does it determine if/how to meet your deadline? If you're running a sustained workload your deadline is to finish it ASAP, otherwise you're wasting your money on a faster CPU which you're actually not using.

So true!

Also, using the performance governor all the time won't burn your CPU, since it will still enter its deepest sleep states and thus save more power than by simple downclocking.

Here's a very basic test anyone can try out for themselves:

Playback a video with the performance governor and run this command in the terminal at various intervalls:

sudo cpupower monitor

On all of my Intel CPUs I can observe that all my cores are in their deepest sleep state for the majority of time with a 1080p 60FPS h.264 video, and my notebook's fan only spins up slightly during a 2+ hours long film.

I'd really like to know how the situation is with AMD Ryzens, so if anyone could provide that info, would be appreciated.

Thanks!

[Linuxxx]

If you are working a document in a word processor or doing some web browsing, there no need to ramp the the CPU to the max frequency constantly every time that task schedules. The user experience of working with that document will be the same whether or not the CPU is at the max frequency or not. As I said, the tricky part is deciding what the right algorithm is in the governor. These patches just provide the knobs. The governors still dictate the performance.

In that case, the CPU will still be idle and therefore in its deepest sleep state for the majority of time, thus saving the most amount of power.

[agd5f]

In that case, the CPU will still be idle and therefore in its deepest sleep state for the majority of time, thus saving the most amount of power.

Sure, but even when you do ramp it up, there's no need to go the max frequency in most cases.

[agd5f]

So true!

Also, using the performance governor all the time won't burn your CPU, since it will still enter its deepest sleep states and thus save more power than by simple downclocking.

Here's a very basic test anyone can try out for themselves:

Playback a video with the performance governor and run this command in the terminal at various intervalls:

sudo cpupower monitor

On all of my Intel CPUs I can observe that all my cores are in their deepest sleep state for the majority of time with a 1080p 60FPS h.264 video, and my notebook's fan only spins up slightly during a 2+ hours long film.

I'd really like to know how the situation is with AMD Ryzens, so if anyone could provide that info, would be appreciated.

Thanks!

If you are using the same governor, it should act similarly. As I said, this driver just provides the wider range of frequencies compared to the ACPI pstate driver. The governors still determine what performance levels are selected.

[cyring]

What Intel had successfully provided:

• HWP
• EEO
• R2H

This AMD ACPI CPPC implementation is not at best and depends on BIOS/UEFI manufacturers.
AMD has recently commited CPPC MSR registers to provide a better latency control operation over those classes of frequencies. It's very close to the Intel HWP.

So far, assembly reading of those MSR is failing with my MATISSE/3950X