On 6/28/2024 11:18, Diederik de Haas wrote:
I don't think so. I've never heard of this actually used in a desktop
board. It's for mobile designs AFAIK.
I can understand that the initial/original goal/target was mobile.
But is there a(ny) technical reason why it couldn't also support 'desktop'
systems?
IIRC and IIUC it does need Zen 3, which my CPU/SoC does.
It needs information about the hardware thermal design to change the
correct coefficients.
For example just changing the sPPT or fPPT without the appropriate
thermal headroom will cause the SOC to go into thermal throttling
prematurely and hurt your performance.
That's why OEMs encode this information in their EC or in the BIOS and
advertise it in the PMF ACPI tables what they can do.
Ok. I might be able to convince Asus to add it, but I can also configure my
system to 'modprobe' it on boot up.
Loading it with modprobe doesn't do anything if there is no ACPI device
to bind to. It's just like having it compiled into your kernel and it
not binding to any device.
Like I said; I've never seen it on a desktop. Because of what it's
intended to do in it's current form, I think it's unlikely that it would
be added there.
The way that it works is that the OEM will set bits in their BIOS for
that ACPI device indicating which "AMD_PMF" features they support.
That's things like Static Slider, Auto mode, CNQF, Smart PC, slider
notifications.
I have no idea what those things are, but I can research it ...
I think someone with a laptop that supports PMF would be best to confirm
this. Framework 13 AMD and Framework 16 both support it.
It would be great if someone with such a system can confirm whether it now can/
does work for the original target.
Yeah maybe someone on the Framework forums will be able to confirm it's
working now for them. They've been very vocal about it broken in Debian.
But I think everyone and the planet would benefit from a (more) energy efficient
system, regardless if it (normally) runs on batteries or not.
In my case, this system will likely be my NAS, so idle 99(.9)% of the time and
(in the future) on 24/7, so I'm extra motivated to make it consume as little
energy as possible.
Cheers and thanks for your fast response,
Diederik
Keep in mind PPD does multiple things based on what the hardware
advertises support for.
For your system, you are using amd-pstate in active mode. I can see
this from your powerprofilesctl output. This will make sure the SoC is
properly biased towards efficiency or performance based on your preference.
It will operate under the limitations of the coefficients programmed by
the firmware at max load (so you can't change PPT), but when idle it
shouldn't consume more power than needed.
There is a kernel patch series coming in kernel 6.11 for "Core
performance boost" which will let you turn on/off boost above nominal
frequency. You can turn it off, and then CPU cores won't ever go above
nominal frequency.
I'm proposing that we would leave boost on for PPD balanced and
performance states. For PPD power-saver we would turn it off.
This is merged in the PPD tree and unless anyone complains will be part
of the next PPD release.
The other thing that could be really interesting to do for power savings
purposes is to put certain tasks only the non-preferred cores or tune
EPP towards efficiency on cores running long running tasks that don't
need to finish quickly.
In my opinion this is going to open up a lot of potential for sched-ext.
and for systemd. Userspace can read the core rankings and when starting
up and moving tasks around adjust EPP, boost and which cores tasks run
on. It's a lot of complicated work ahead though with a lot of profiling
needed.
