Re: Call For Test: Powerd supported hwpstate_amd

Hi Charlie and others:

I've updated the branch to the latest main and added an AMD RAPL driver 
to expose CPU energy consumption.

The driver doesn't require CPPC to function, which makes it easy to run 
A/B tests to see the actual energy impact of CPPC.

You can find the data in these sysctls:

  *

    |dev.amd_rapl.0.cores_mwatt|: 39,39,45,45,701,701,47,47,48,48,45,45
    (varies based on core count)

  *

    |dev.amd_rapl.0.package_mwatt|: 8985 (varies based on the number of
    sockets)

Notice that the cores_mwatt will be duplicated if you enable SMT on your 
CPU.

Let me know if you run into any issues with the data.

[1]: https://reviews.freebsd.org/D55603

On 2/26/26 05:47, Charlie Li wrote:
> ShengYi Hung wrote:
>> Dear all:
>>
>> Sorry for the confusion caused by the earlier version of the | 
>> hwpstate_amd| driver I shared last month.
>>
>> I’ve prepared a new patch that adds |powerd| support for 
>> |hwpstate_amd|. The patch is available here [1].
>>
>> Please note that this patch depends on a series of parent patches, 
>> all of which must be applied first. For convenience, I’ve created a 
>> GitHub branch [2] that contains the complete patch series, so you can 
>> use |git am| to apply them in order.
>>
>> On my Framework 13 (7040 series), the legacy P-State driver exposes 
>> only three frequency levels, which limits control granularity. In 
>> contrast, the CPPC driver exposes 10 frequency levels (and 
>> potentially more), allowing |powerd| to manage CPU performance with 
>> much finer granularity.
>>
>> That said, this driver still needs wider testing across different 
>> Zen2+ systems. I would greatly appreciate any additional testing and 
>> feedback.
>>
>> Thanks!
>>
>> [1]: https://reviews.freebsd.org/D55477
>>
>> [2]: https://github.com/aokblast/freebsd-src/commits/hwpstate_amd/ 
>> cpufreq_write/
>>
> I would like to test on my Green Sardine/Cezanne/5000 series, but this 
> no longer applies on latest main, especially after D55251 landed. I 
> commented in the review where the conflicts happened, but I'm not sure 
> if the rest of my rebase attempt made any sense considering the other 
> changes of D55251.
>