On Friday, 28 June 2024 18:37:06 CEST Mario Limonciello wrote: > 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.
Isn't that something that AMD would know? > 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. Ok, understood. I'm not too positive I could convince Asus to add that to their 'BIOS', but I can try. > 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. Understood. Hopefully this does make AMD aware that non-laptop/mobile devices could (or should!) be a potential target too. Even if it won't directly benefit me now, that would still be a win :) > >> 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 ... > > > > 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. > > > > 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. I hadn't used PPD before, so I'll experiment with it. Looks like I have lots of research to do ;-) Thanks for your detailed response :-) Hack (and Save) the Planet! Diederik
signature.asc
Description: This is a digitally signed message part.
