[Solved] Modprobe blacklisting and AMD P-STATE

[lory995]

Hi everybody, It's one of my first posts around here but i've read lots and lots of problem-solving posts that helped me a lot but i didn't find an answer to this one so here i am. It's a stupid problem, i'm messing up something very easy for sure but bear with me.

 

I've read this comment from @Iker and i've tried to implement it, but after the reboot if i launch

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
acpi-cpufreq

i obtain acpi-cpufreq so i guess my mod has failed..

 

As per tagged post i added 

modprobe.blacklist=acpi_cpufreq amd_pstate.shared_mem=1

in /boot/syslinux/syslinux.cfg ( like this ) and in /boot/config/go ( here ).

I didn't know exactly how or under what add them so i guess that it's gonna be an easy solution  .

 

Thank you!

 

Edited February 5 by lory995

[Iker]

I get this thing working with the following options

 

1. Add the blacklisting and pstate command to the syslinux config (It's possible from the GUI):

modprobe.blacklist=acpi_cpufreq amd_pstate.shared_mem=1

2. Include in your go file the following line to load the kernel module:

modprobe amd_pstate

 

3. Reboot and enjoy your new scheduler.

[lory995]

Iker it really doesn't work for me  I've got a Zen 2 cpu so it should work...

If you paste this in your terminal does it state "amd-pstate"? 

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver

[Iker]

Which unraid version are you using?, I don't have amd cpu governor enabled, Unraid lags a lot and generally speaking performance vs power is not so good.

Edited January 24 by Iker

[lory995]

i'm using the last one, 6.11.5 with kernel 5.19.17 if i remember correctly.
The fact is that i made this server with the intention of futureproofing myself, at the moment i need to run 24/7 only 3 little 2 core vms and a couple dockers ( pihole and tailscale ).

Even if the  server is idle most of the time it uses like 60~65watt, that without any gpu and with just 2 disks usually spinning that i'm planning to redcue to one once the new ssd comes in. If i connect my gpu ( 3070 ) it goes up to 110~120 watts idle....

 

I don't know what to do

 

 

i've tried everything, even disabling half the core, reducing ram clocks to 2133, hard capping it to the minimum Wattage on bios (45W)... Now i at least wanted to activate p-state even for that 15-20% reduction you was talking about in the other post but it seems that it doesn't want to work. Or maybe it's active but i can't see it, i don't know. 

Is there an appropriate section to discuss power managing problem?

 

 

Edited January 24 by lory995

[Iker]

You probably need the feature to be enabled on your bios (Global C Stats, CPPC, and a lot of other options), I don't recall the exact parameters and it varies for different manufacturers, so give it a try with a google search.

Edited January 25 by Iker

[lory995]

On 1/25/2023 at 4:55 AM, Iker said:

You probably need the feature to be enabled on your bios (Global C Stats, CPPC, and a lot of other options), I don't recall the exact parameters and it varies for different manufacturers, so give it a try with a google search.

Actually i did already enable all of that at the time you wrote here, but i wanted really go through and try this driver so i stopped and started looking around to try and understand really what i was doing. I read a lot of guides on linux kernel modules and how did they work.
And of course, as usually happens when you have some resemblance of understanding of what you are doing, i succeded.

 

What i did instead is injecting them at boot.

To do that i modified /boot/config/go adding *before everything* except for #!/bin/bash ( so right under it )

modprobe amd_pstate

 

 [....]/emhttp was after the line written above, for example.
 

Then i created 2 .conf files in /etc/modprobe.d one for blacklisting acpi_cpufreq(1) and one for enabling pstate(2):

(1) i created it with " nano /etc/modprobe.d/acpifreqdisable.conf "

blacklist acpi_cpufreq

(2) i created it with "nano /etc/modprobe.d/enableamdpstate.conf"

options amd_pstate shared_mem=1

 

and left /boot/syslinux/syslinux.cfg as link in my first post.

Now it works. 

P.S: @Iker i've got it up an running the 26 or 27th of january and have yet to note any instability whatsoever fortunately. Maybe since you tried them the drivers got updated?  

Edited February 5 by lory995

[Iker]

23 hours ago, lory995 said:

 i've got it up an running the 26 or 27th of january and have yet to note any instability whatsoever fortunately. Maybe since you tried them the drivers got updated?  

 

Nicely done! It's weird as all you did has the same effects as the kernel parameters, but anyway, it's nice to have a new method.

 

For the last question, I didn't have any instability issues, they were latency problems. I have multiple services running every X seconds, and additionally in the morning the governor change to power save; with the new driver the cores go down to 500 MHz, that's actually nice; but also it causes some of the scheduled tasks to fail with timeouts and generally speaking the cores didn't scale very well. Obviously, you save a buck or two with the new driver, but if you need performance it doesn't work really well.

[lory995]

31 minutes ago, Iker said:

Nicely done! It's weird as all you did has the same effects as the kernel parameters, but anyway, it's nice to have a new method.

I know in fact i based my steps upon your previous solution, after all you had it working. i just studied a different way to use them  

 

33 minutes ago, Iker said:

For the last question, I didn't have any instability issues, they were latency problems. I have multiple services running every X seconds, and additionally in the morning the governor change to power save; with the new driver the cores go down to 500 MHz, that's actually nice; but also it causes some of the scheduled tasks to fail with timeouts and generally speaking the cores didn't scale very well. Obviously, you save a buck or two with the new driver, but if you need performance it doesn't work really well.

Fair enough, different usecases and different necessities