Bug 832179

Summary: Power management guide is wrong for frequency scaling in Fedora 17
Product: [Fedora] Fedora Documentation Reporter: Jim McElwaine <mcelwainejim>
Component: power-management-guideAssignee: Petr Bokoc <pbokoc>
Status: CLOSED EOL QA Contact: Fedora Docs QA <docs-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: develCC: jhradile, jskarvad, zach
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-11-07 15:30:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jim McElwaine 2012-06-14 18:39:43 UTC
Description of problem:
Power management guide is wrong 
https://docs.fedoraproject.org/en-US/Fedora/17/html/Power_Management_Guide/cpufreq_setup.html#enabling_a_cpufreq_governor

Version-Release number of selected component (if applicable):
Fedora 17

the location of the cpufreq directory is misspecified
it is
/lib/modules/3.4.0-1.fc17.x86_64/kernel/drivers/cpufreq

There are no modules
acpi-cpufreq or p4-clockmod available
is acpi-cpufreq directly compiled in.


the cpuspeed package is mentioned for the userspace governor but no package exists in fedora 17.

I have been completely unable to figure out the following use case.

My laptop overheats and powers off if the cpu load is high for too long.

There should be a cpu governor or userspace daemon that reduces frequency when the temperature gets too high.

Comment 1 Jack Reed 2012-10-25 05:17:13 UTC
Thanks for reporting these issues, Jim. I'll address them individually, and have asked Jaroslav Skarvada for his advice on a couple of them.

(In reply to comment #0)
> the location of the cpufreq directory is misspecified
> it is
> /lib/modules/3.4.0-1.fc17.x86_64/kernel/drivers/cpufreq

No problem, I've fixed this up.

> 
> There are no modules
> acpi-cpufreq or p4-clockmod available
> is acpi-cpufreq directly compiled in.

Jaroslav, how are these drivers acquired? I don't have them listed in my /lib/modules/KERNEL/kernel/drivers/cpufreq directory either. (They are mentioned in the Important admonition in [1].)


> the cpuspeed package is mentioned for the userspace governor but no package
> exists in fedora 17.

Jaroslav, the F16 Alpha release notes [2] say that cpuspeed has been rendered obsolete. The Power Management Guide mentions that the userspace governor is "normally used in conjunction with the cpuspeed daemon". Is whatever has replaced cpuspeed still used in conjunction with the userspace governor? Or can I just remove this point entirely?

> 
> I have been completely unable to figure out the following use case.
> 
> My laptop overheats and powers off if the cpu load is high for too long.
> 
> There should be a cpu governor or userspace daemon that reduces frequency
> when the temperature gets too high.

Jim, it would be best to submit a new bug against the cpupowerutils component as a request for enhancement.


[1] http://docs.fedoraproject.org/en-US/Fedora/17/html/Power_Management_Guide/cpufreq_setup.html
[2] https://fedoraproject.org/wiki/Fedora_16_Alpha_release_notes#What.27s_New_in_Fedora_16_Alpha

Comment 2 Jaroslav Škarvada 2012-10-26 20:27:40 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > the location of the cpufreq directory is misspecified
> > it is
> > /lib/modules/3.4.0-1.fc17.x86_64/kernel/drivers/cpufreq
> 
> No problem, I've fixed this up.
> 
All are built-in and get selected automatically, so the text is obsoleted. So the "3.1 Procedure" should go away. The command:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
is useful and could be moved to 3.2.2 introduction, or maybe to 3.2 procedure. Or just reuse/modify the text from the RHEL guide.

Also all governors are built-in, so preamble for 3.2 procedure is not right.

> > 
> > There are no modules
> > acpi-cpufreq or p4-clockmod available
> > is acpi-cpufreq directly compiled in.
> 
> Jaroslav, how are these drivers acquired? I don't have them listed in my
> /lib/modules/KERNEL/kernel/drivers/cpufreq directory either. (They are
> mentioned in the Important admonition in [1].)
> 
Everything is built-in in the kernel. The "important admon" should go away, the right module should be autoselected by kernel.

> 
> > the cpuspeed package is mentioned for the userspace governor but no package
> > exists in fedora 17.
> 
> Jaroslav, the F16 Alpha release notes [2] say that cpuspeed has been
> rendered obsolete. The Power Management Guide mentions that the userspace
> governor is "normally used in conjunction with the cpuspeed daemon". Is
> whatever has replaced cpuspeed still used in conjunction with the userspace
> governor? Or can I just remove this point entirely?
> 
Right, it gone. AFAIK there is currently no replacement (I pointed this out in the past, but such scenarios are very rare and to be honest this is the way how it shouldn't be done).

> > 
> > I have been completely unable to figure out the following use case.
> > 
> > My laptop overheats and powers off if the cpu load is high for too long.
> > 
> > There should be a cpu governor or userspace daemon that reduces frequency
> > when the temperature gets too high.
> 
> Jim, it would be best to submit a new bug against the cpupowerutils
> component as a request for enhancement.
> 
Currently I am not aware of any similar daemon in Fedora but there are still some possible workarounds:
You can create/download script that will periodically read sensors and alters cpufreq settings or you can alter your cpufreq settings statically (i.e. limit the max freq) by writing to:
/sys/devices/system/cpu/cpufreq/ondemand/powersave_bias
this limits the max frequency the ondemand governor uses on all cores, the bias can be set to 1 - 1000 to reduce the target frequency by one-thousandth of that value, or you can limit the max frequency used by ondemand governor on specific cpu (e.g. for cpu0) by writing the frequency to:
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

Available frequencies can be get by:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

Or you can switch to userspace governor by (e.g. for cpu0):
# echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

and then control the frequency directly by writing the requested frequency to (e.g. for cpu0):
/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed

But anyway the overheating indicates some HW or ACPI table problem. Cleaning/replacing fan/sink/heat pipes or upgrading BIOS is recommended. In case your laptop supports thermal zones (check the trippoints in /sys/class/thermal/thermal_zoneX), you should be able to lower the trippoints by booting with thermal.act=TEMPERATURE kernel command line parameter, where TEMPERATURE is the target temperature in degrees where the thermal zone cooling is started. Or if you think the critical shutdown temperature is too low, you can increase it by booting with thermal.crt=TEMPERATURE (it can be very dangerous). Also AFAIK when the trip point is reached the message is broadcasted on the netlink. Theoretically the acpid daemon could be configured to react to such messages and to lower the cpufreq max frequency. This is async event, so still better than periodical polling by cpuspeed. I could try to prepare some example acpid config if you are interested. But all are workarounds for broken HW.

Comment 3 Jack Reed 2012-11-01 04:26:16 UTC
(In reply to comment #2)
> > 
> All are built-in and get selected automatically, so the text is obsoleted.
> So the "3.1 Procedure" should go away. The command:
> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
> is useful and could be moved to 3.2.2 introduction, or maybe to 3.2
> procedure. Or just reuse/modify the text from the RHEL guide.
> 
> Also all governors are built-in, so preamble for 3.2 procedure is not right.

Thanks Jaroslav, but I'm unsure of what to edit. If I'm removing "If a specific governor is not listed as available for your CPU" because those governors are built in, then the whole step is redundant because it says to use modprobe to enable a governor that is listed as unavailable for your CPU. If all governors are listed as available, then I assume the modprobe command is unnecessary, in which case the second step, which enables the governor, is all that's needed. Should I delete the first step?

Note that because I am updating this section to incorporate the cpupower command as we discussed, then this second step to enable the governor will use "cpupower frequency-info --governors"

The command "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" that you've asked to be retained has also been replaced, by "cpupower frequency-info --policy". 

I just want to be sure that this is acceptable and you don't actually want the existing cat and echo commands to be retained despite the emphasis on cpupower.

> > 
> Everything is built-in in the kernel. The "important admon" should go away,
> the right module should be autoselected by kernel.

No problem - deleted.

> > 
> Right, it gone. AFAIK there is currently no replacement (I pointed this out
> in the past, but such scenarios are very rare and to be honest this is the
> way how it shouldn't be done).

Great, OK. I've removed the sentence "This governor is normally used in conjunction with the cpuspeed daemon" from 3.2.1.

Comment 4 Jaroslav Škarvada 2012-11-05 22:38:29 UTC
(In reply to comment #3)
> Thanks Jaroslav, but I'm unsure of what to edit. If I'm removing "If a
> specific governor is not listed as available for your CPU" because those
> governors are built in, then the whole step is redundant because it says to
> use modprobe to enable a governor that is listed as unavailable for your
> CPU. If all governors are listed as available, then I assume the modprobe
> command is unnecessary, in which case the second step, which enables the
> governor, is all that's needed. Should I delete the first step?
> 
Yes, please delete the first step (about modprobe).

> Note that because I am updating this section to incorporate the cpupower
> command as we discussed, then this second step to enable the governor will
> use "cpupower frequency-info --governors"
> 
Great, I hardly follow all the changes :). But your substitution command is not correct.
"cpupower frequency-info --governors" will show all available governors, but enable the specific governor by:
"cpupower frequency-set --governor GOVERNOR" or simply by "cpupower frequency-set -g GOVERNOR". This will change governer on all cores (CPUs). You can also modify governor on specific core only (if supported by HW) by using the -c switch. 

> The command "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" that
> you've asked to be retained has also been replaced, by "cpupower
> frequency-info --policy". 
> 
OK, no problem, just be consistent.

> I just want to be sure that this is acceptable and you don't actually want
> the existing cat and echo commands to be retained despite the emphasis on
> cpupower.
> 
The admon box from RHEL guide that very briefly noted that there are also the sysfs "echo/cat" alternatives is enough.

Comment 5 Jack Reed 2012-11-08 01:33:26 UTC
(In reply to comment #4)

> Yes, please delete the first step (about modprobe).

Sure, done. I've removed Procedure 3.1 as per Comment 2 and the first step from Procedure 3.2. This has effectively stripped that section down to the two commands.

> > 
> Great, I hardly follow all the changes :). But your substitution command is
> not correct.
> "cpupower frequency-info --governors" will show all available governors, but
> enable the specific governor by:
> "cpupower frequency-set --governor GOVERNOR" or simply by "cpupower
> frequency-set -g GOVERNOR". This will change governer on all cores (CPUs).
> You can also modify governor on specific core only (if supported by HW) by
> using the -c switch. 

And also this: I've added an example command to explain the -c switch.

And oops - that was a typo with frequency-info. I had distinguished them properly in the XML but not here in Comment 3.

> 
> > The command "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" that
> > you've asked to be retained has also been replaced, by "cpupower
> > frequency-info --policy". 
> > 
> OK, no problem, just be consistent.
> 
> > I just want to be sure that this is acceptable and you don't actually want
> > the existing cat and echo commands to be retained despite the emphasis on
> > cpupower.
> > 
> The admon box from RHEL guide that very briefly noted that there are also
> the sysfs "echo/cat" alternatives is enough.

Great, OK. All is well then. Thanks Jaroslav.

The commits can be viewed here:

For the removal of the procedures - http://git.fedorahosted.org/cgit/docs/power-management-guide.git/commit/?id=93244bc92f60a57a2037c53e4282804169666ea2

For the addition of -c - http://git.fedorahosted.org/cgit/docs/power-management-guide.git/commit/?id=c9a4d7118603c8fde5012555117a1c2d0a8670be

Comment 6 Jack Reed 2012-11-08 01:38:42 UTC
(In reply to comment #4)

> Yes, please delete the first step (about modprobe).

Sure, done. I've removed Procedure 3.1 as per Comment 2 and the first step from Procedure 3.2. This has effectively stripped that section down to the two commands and...

> > 
> Great, I hardly follow all the changes :). But your substitution command is
> not correct.
> "cpupower frequency-info --governors" will show all available governors, but
> enable the specific governor by:
> "cpupower frequency-set --governor GOVERNOR" or simply by "cpupower
> frequency-set -g GOVERNOR". This will change governer on all cores (CPUs).
> You can also modify governor on specific core only (if supported by HW) by
> using the -c switch. 

... this: I've also added an example command to explain the -c switch.

And oops - that was a typo with frequency-info. I had distinguished them properly in the XML but not here in Comment 3.

> 
> > The command "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" that
> > you've asked to be retained has also been replaced, by "cpupower
> > frequency-info --policy". 
> > 
> OK, no problem, just be consistent.
> 
> > I just want to be sure that this is acceptable and you don't actually want
> > the existing cat and echo commands to be retained despite the emphasis on
> > cpupower.
> > 
> The admon box from RHEL guide that very briefly noted that there are also
> the sysfs "echo/cat" alternatives is enough.

Great, OK. All is well then. Thanks Jaroslav.

The commits can be viewed here:

For the removal of the procedures - http://git.fedorahosted.org/cgit/docs/power-management-guide.git/commit/?id=93244bc92f60a57a2037c53e4282804169666ea2

For the addition of -c - http://git.fedorahosted.org/cgit/docs/power-management-guide.git/commit/?id=c9a4d7118603c8fde5012555117a1c2d0a8670be

Comment 10 Petr Bokoc 2019-11-07 15:30:23 UTC
I'm closing this bug as part of a Bugzilla cleanup effort. The most likely reason is that the bug has been opened either against a component we no longer publish, or against Release Notes for an EOL release.