[Regression[ - 5.14.14-xm2.0.fc35.x86_64 not longer ships usable amd-pstate

[aenertia]

Thanks for AMD-pstate inclusion in - 5.14.14-xm1.0.fc35.x86_64

Worked well (test series if you are interested: https://openbenchmarking.org/result/2110226-TJ-AMDPSTATE39,2110213-TJ-PBO25AUTO59,2110191-TJ-PBO25THER16,2110213-TJ-PBO30018056,2110219-TJ-PBO50THER12,2110226-TJ-AMDPSTATE62&hgv=pbo50-therm76-x8&ppt=D&swl=1&hgv=pbo50-therm76-x8&ppt=D&swl=1&hgv=amdpstate-pbo50-therm760-x8&ppt=D&swl=1&hgv=amdpstate-pbo50-therm76-autoscal-ondemand&ppt=D

but whatever kernel config options were changed in 5.14.14-xm2.0.fc35.x86_64 - have resulted in acpi-cpufreq claiming the device. And there is no way to change the driver from acpi-cpufreq to amd-pstate at run time currently that I am aware of. I think this is likely related to config option for acpi-cpufreq set to Y rather than M possibly likewise for the amd-pstate module (Y rather than M).

The module is built and loadable in xm2; just not usable.

Perhaps this is an upstream bug which requires a mechanism in acpi-cpufreq and amd-pstate to allow for changing the driver on the fly. Previously intel-pstate required a specific disable toggle to revert to acpi-cpufreq, but I have found no evidence of the reverse (acpi-cpufreq to something else).

Originally posted by @aenertia in https://github.com/xanmod/linux/issues/203#issuecomment-949936450

[xanmod]

I have received several issue reports with this driver.

There is no boot parameter option to disable it, the developer added the option to compile it as a module, for this reason it was the best option I found to not disable it for everyone.

As we can see, this driver is not ready for production use yet (v2 patchset).

[aenertia]

Thanks - i've had good results with it so far in testing and I certainly see boost states being more responsive and subsequently better performance whilst using PBO curve optimizer based boosts with zen3.

You are quite correct that the original authors propose a v2 patchset for mainline so hopefully some of these niggles which appear to be with acpi-cpufreq expecting it to be the only legitimate driver fall out of that review process.

[aenertia]

As an related aside - there has been a screed of PBO2 Ryzen optimization threads in various places and forums. As you can see from the test sequence https://openbenchmarking.org/result/2110228-TJ-AMDPSTATE42,2110227-TJ-AMDPSTATE84,2110221-TJ-AMDPSTATE95,2110221-TJ-AMDPSTATE95,2110222-TJ-AMDPSTATE16,2110229-TJ-AMDPSTATE54,2110226-TJ-AMDPSTATE39,2110213-TJ-PBO25AUTO59,2110191-TJ-PBO25THER16,2110213-TJ-PBO30018056,2110219-TJ-PBO50THER12,2110226-TJ-AMDPSTATE62&hgv=pbo50-therm76-x8&ppt=D&swl=1&hgv=pbo50-therm76-x8&ppt=D&swl=1&hgv=amdpstate-pbo50-therm760-x8&ppt=D&swl=1&hgv=amdpstate-pbo50-therm76-autoscal-ondemand&ppt=D&swl=1&hgv=amdpstate-pbo50-autosc-therm81&ppt=D&swl=1&hgv=amdpstate-pbo25-therm76-autos&ppt=D&swl=1&hgv=amdpstate-pbo25-therm76-autos-ondemand&ppt=D&swl=1&hgv=amdpstate-pbo200-autos-therm76&ppt=D&swl=1&hgv=amdpstate-pbo200-autos-therm76&ppt=D&swl=1&hgv=amdpstate-pbo75-therm76-autos&ppt=D

The best way to optimize boost states and boosts is to leave things at default (or use a tuned per core undervolt matching the CPPC tags that ship with each chip) and simply lower the thermal target down based on your individual cooling situation. For me that is lowering the Thermal limit to 76 Deg (Defaults are set at 90 Deg for Ryzen 5000). This limits PPT/EDC/TDC naturally and there is no instability caused by tweaking those values individually as many guides suggest.

[cassandracomar]

the module works fine if you instruct it to load at boot time. you should be able to load the module at boot by creating /etc/modules-load.d/amd-pstate.conf with "amd_pstate" as the contents. as long as this loads before the cpufreq driver, you should be ok. alternatively you can just set the X86_AMD_PSTATE option to "y" and rebuild the kernel yourself.

[aenertia]

I tried; because in xm2 the acpi_cpufreq is built in even adding kernel grub option to blacklist it fail to allow amd_pstate to 'grab' it; and as there isn't an init_handle for the acpi_cpufreq when it is built in then you can't unhook it.

Things tried;

adding amd_pstate to dracut initrd adding amd_pstate=on to kernel command line adding acpi-cpufreq to modprobe.d/blacklist.conf adding modules.blacklist=acpi_cpufreq to kernel command line

On Thu, Oct 28, 2021 at 9:51 AM Cassandra Comar @.***> wrote:

the module works fine if you instruct it to load at boot time. you should be able to load the module at boot by creating /etc/modules-load.d/amd-pstate.conf with "amd_pstate" as the contents. as long as this loads before the cpufreq driver, you should be ok. alternatively you can just set the X86_AMD_PSTATE option to "y" and rebuild the kernel yourself.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/xanmod/linux/issues/208#issuecomment-953300738, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACF5LZ2UCMSHENCUKQ5GITUJBQ33ANCNFSM5GRKJPTA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[aenertia]

Just to further clarify, acpi_cpufreq generally should not be configured as a built-in module as it will supercede the ability to use other frequency schedulers. This is the default in i.e fedora

On Thu, Oct 28, 2021 at 9:55 AM Joel Wirāmu Pauling @.***> wrote:

I tried; because in xm2 the acpi_cpufreq is built in even adding kernel grub option to blacklist it fail to allow amd_pstate to 'grab' it; and as there isn't an init_handle for the acpi_cpufreq when it is built in then you can't unhook it.

Things tried;

adding amd_pstate to dracut initrd adding amd_pstate=on to kernel command line adding acpi-cpufreq to modprobe.d/blacklist.conf adding modules.blacklist=acpi_cpufreq to kernel command line

On Thu, Oct 28, 2021 at 9:51 AM Cassandra Comar @.***> wrote:

the module works fine if you instruct it to load at boot time. you should be able to load the module at boot by creating /etc/modules-load.d/amd-pstate.conf with "amd_pstate" as the contents. as long as this loads before the cpufreq driver, you should be ok. alternatively you can just set the X86_AMD_PSTATE option to "y" and rebuild the kernel yourself.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/xanmod/linux/issues/208#issuecomment-953300738, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACF5LZ2UCMSHENCUKQ5GITUJBQ33ANCNFSM5GRKJPTA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[cassandracomar]

so I got the amd_pstate module to load just by ensuring that it was loaded prior to acpi_cpufreq in /etc/modules.d/:

 $ sudo cpupower frequency-info
analyzing CPU 0:
  driver: amd-pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 131 us
  hardware limits: 400 MHz - 4.68 GHz
  available cpufreq governors: performance schedutil
  current policy: frequency should be within 400 MHz and 4.68 GHz.
                  The governor "schedutil" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 3.18 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
    AMD PSTATE Highest Performance: 166. Maximum Frequency: 4.68 GHz.
    AMD PSTATE Nominal Performance: 117. Nominal Frequency: 3.30 GHz.
    AMD PSTATE Lowest Non-linear Performance: 39. Lowest Non-linear
Frequency: 1.10 GHz.
    AMD PSTATE Lowest Performance: 15. Lowest Frequency: 400 MHz.

is your distro loading acpi_cpufreq from initrd or something? because specifying the module load order explicitly should ensure this driver gets preference.

also, just to confirm, your cpu is Zen 3, correct? the amd_pstate driver will fall back to acpi_cpufreq if you have Zen 2 or older for the time being. I believe they intend to fix this prior to merge into mainline.

On Thu, Oct 28, 2021 at 11:51 PM Joel Wirāmu Pauling < @.***> wrote:

Just to further clarify, acpi_cpufreq generally should not be configured as a built-in module as it will supercede the ability to use other frequency schedulers. This is the default in i.e fedora

On Thu, Oct 28, 2021 at 9:55 AM Joel Wirāmu Pauling @.***> wrote:

I tried; because in xm2 the acpi_cpufreq is built in even adding kernel grub option to blacklist it fail to allow amd_pstate to 'grab' it; and as there isn't an init_handle for the acpi_cpufreq when it is built in then you can't unhook it.

Things tried;

adding amd_pstate to dracut initrd adding amd_pstate=on to kernel command line adding acpi-cpufreq to modprobe.d/blacklist.conf adding modules.blacklist=acpi_cpufreq to kernel command line

On Thu, Oct 28, 2021 at 9:51 AM Cassandra Comar @.***> wrote:

the module works fine if you instruct it to load at boot time. you should be able to load the module at boot by creating /etc/modules-load.d/amd-pstate.conf with "amd_pstate" as the contents. as long as this loads before the cpufreq driver, you should be ok. alternatively you can just set the X86_AMD_PSTATE option to "y" and rebuild the kernel yourself.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/xanmod/linux/issues/208#issuecomment-953300738, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AACF5LZ2UCMSHENCUKQ5GITUJBQ33ANCNFSM5GRKJPTA

. Triage notifications on the go with GitHub Mobile for iOS < https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android < https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/xanmod/linux/issues/208#issuecomment-954407856, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACOKBA2KKNFN4SF2QZRJ2DUJIK3LANCNFSM5GRKJPTA .