Description of problem: In Mageia 5 beta 1 the settings in /etc/sysconfig/cpupower default to performance rather than ondemand. This means that machines take more power and get hotter when they needn't. Version-Release number of selected component (if applicable): Mageia 5 beta 1. How reproducible: Every time. Steps to Reproduce: 1. Install Mageia 5 beta 1 2. cat /etc/sysconfig/cpupower The simple fix is to make it default to ondemand as Mageia 4 does. Reproducible: Steps to Reproduce:
Changelog entry: * Tue Oct 14 2014 tmb <tmb> 3.17.0-5.mga5 + Revision: 738580 - switch to performance governor by default This also affects upgrades: I had GOVERNOR=ondemand in /etc/sysconfig/cpufreq but the systems were switched to 'performance' because cpupower obsoletes cpufreq.
CC: (none) => cjw
Wasn't the default changed because it was invalid on a lot of machines, causing the cpupower service to fail?
Assignee: bugsquad => tmb
@Jim: Please, see: - https://bugs.mageia.org/show_bug.cgi?id=13368 - https://bugs.mageia.org/show_bug.cgi?id=14570
CC: (none) => yullaw
If an other governor is needed, then you can choose from the list: # cpupower frequency-info then by these steps: - # systemctl stop cpupower.service - rewrite a governor in /etc/sysconfig/cpupower se root - # systemctl start cpupower.service But please, check the links above first, why now is a "performance"
Correct me if I'm wrong, but setting the CPU frequency governor to 'performance' is unacceptable for many machines, users may get higher power bills because of such a change. A wrapper script like the one shown below can be used to make sure the cpupower service does not fail when the configured CPU frequency governor is not available. #!/bin/sh if [ "$1" = "frequency-set" ] && [ "$2" = "-g" ]; then # check if configured governor is available CONFIGURED_GOVERNOR="$3" GOVERNORS="$(cpupower frequency-info|grep 'available cpufreq governors')" if ! echo "$GOVERNORS"|grep "$CONFIGURED_GOVERNOR" >/dev/null 2>&1; then echo "CPU frequency governor $CONFIGURED_GOVERNOR is not available" exit 0 fi fi /usr/bin/cpupower "$@"
Priority: Normal => release_blockerSeverity: minor => major
I noted that my childrens laptops Thinkpad T43 (intel 32 bit) was unusually noisy. I realised CPU frequency was constantly at max. First I uninstalled cpupower and installed cpufreqd, but then they were instead at constant slowest speed... Thanks to info above i noted cpufrequd is deprecated and i have now changed back and edited /etc/sysconfig/cpupower to -----8<---- # See 'cpupower help' and cpupower(1) for more info CPUPOWER_START_OPTS="frequency-set -g ondemand" CPUPOWER_STOP_OPTS="frequency-set -g ondemand" ----->8---- ...where the two "ondemand" previously was "performance" Seem to work correctly now :) This really need to be fixed before release. The problem makes batteries drain, power be consumed, noise made...
CC: (none) => fri
Hi guys, I am sorry to disagree here. A feature is not a release critical bug. Mageia has never been claimed to be a laptop-only distribution. If we switch back again to powersave, then someone will open a bug report claiming that for a computing workstation the optimal CPU settings is not powersaving but maximal cpufreq! Userside settings are, and will be, user choices. This bug should be close as INVALID.
CC: (none) => dirteat
Mageia have a tradition of working at least on my laptop (except some hickups recently on hibernate&suspend on thinkpad R61/T61) CPU throttling also helps keep my fileserver quiet. And bills and noise down on all machines power. On my ten machines in family, workstations, laptops, server ondemand as per above works. The eleventh machine is an old opteron server that refuse to spin down. Mageia have never claimed to be a desktop only distribution.
Then we agree, this is user's settings and this bug should be closed!
I do not agree. 1) Today throttling is standard, not a feature. 2) For all machines around here the default should be ondemand. I *guess* that is most normal but this is just a few machines. Why should we change from how it is in mga4? (ondemand) Did many have problem with it in mga4? I see in comment2 "on a lot of machines" but i find no reason to throw out the baby with the water. Of course best if it could work for everybody so some automation would be nice. I suggest to keep it as mga4 (ondemand) and keep this open as enhancement (for making automation)
Let's get back to facts: 1) Ondemand does not exist neither make sense anymore on intel processors; that's either "powersave" or "performance". 2) Users'choice should not be relevant here, every local admin can choose what it prefers (and on computing clusters, ondemand stuff were not a good choice). Why should we change? Because ondemand now causes issues precisely because it does not exist anymore with the intel Pstates. So I don't see the point of opening a release critical bug for a local administrator setting. Using a config(noreplace) for /etc/sysconfig/cpupower is more than enough to satisfy everyone wishes. You set it once and it remains forever. As a distro, we should provide a configuration which is 100% sure to work on any machine. Today it is called "performance"; if tomorrow this is called "powersave" I am fine too. But, for sure, this is not called "ondemand" anymore! cheers.
OK, i am apparently not up to date, we only have old machines here... So what kind of throttling do work and cause least issues? We can not demand every user should be aware of these issues...
I think Thomas picked up already the best compromise with "performance" because with intel_pstates driver, there are only 2 options left "performance" and "powersave" within cpupower interface. powersave works fine with intel_pstate, but with older cpus (acpi_cpufreq module), this will fix the frequency to the lowest minimal and you'll get by default a super slow system: From https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt " 2.1 Performance --------------- The CPUfreq governor "performance" sets the CPU statically to the highest frequency within the borders of scaling_min_freq and scaling_max_freq. 2.2 Powersave ------------- The CPUfreq governor "powersave" sets the CPU statically to the lowest frequency within the borders of scaling_min_freq and scaling_max_freq. "
So either there will come a lot of people like me (who do not need latest intel machines), asking why all their machines make noise and heat, OR There will be a fewer but maybe louder lot of people asking why mageia is slow on their brand new expensive machines. I do not think either alternative is good so we may toss dice about what kind of users this should work for, and cover up for the other in bold writing on the errata? And i do not think either user group would say throttling should not be standard. In the long run it seem we must solve this by automation somehow, at install or boot or...
Ive been thinking of altering the cpupower service according to what hw it's on, but for now it's only a TODO... the other one would be to add a dummy "ondemand" target on pstate so we would load performance anyhow. And pstate driver supports Intel CPUs from Sandy Bridge and up, and that was released 2009... so not so "brand new"... but of course it does not do much for amd users So this is still WIP
Isn't the default governor 'performance'? Then nothing needs to be done for machines that use the pstate driver. Here's a wrapper script that doesn't try to run cpupower if the requested governor is not available: #!/bin/sh if [ "$1" = "frequency-set" ] && [ "$2" = "-g" ]; then # check if configured governor is available CONFIGURED_GOVERNOR="$3" GOVERNORS="$(cpupower frequency-info|grep 'available cpufreq governors')" if ! echo "$GOVERNORS"|grep "$CONFIGURED_GOVERNOR" >/dev/null 2>&1; then echo "CPU frequency governor $CONFIGURED_GOVERNOR is not available" exit 0 fi fi /usr/bin/cpupower "$@"
Thomas, how do you envision the progress on this issue with regard to the Mageia 5 release? Should we keep it as a release_blocker, or do you prefer to work on it with a post-release update?
CC: (none) => remi
I don't think this is a release blocker. Should be possible to fix after release as well.
CC: (none) => mageia
Decreasing priority as it can fixed later and provided through updates
Priority: release_blocker => HighCC: (none) => ennael1
Adding to mga6 tracker.
Blocks: (none) => 15527
*** Bug 8839 has been marked as a duplicate of this bug. ***
CC: (none) => tl16887
Added to errata as AMD users are affected: https://wiki.mageia.org/en/Mageia_5_Errata#default_cpufreq_governor_is_performance.2C_some_.5BAMD.5D_users_might_need_to_switch_to_ondemand
This is crazy as it also affects pre-2009 Intel CPUs. We will have very bad reviews, much more than with the cpupower service failing because ondemand is not avalaible.
CC: (none) => lists.jjorge
Just a reminder to everyone not reading the whole thread :) This does not mean that cpupower is broken; it just means that concerned people will have to explicitly specify "ondemand" in /etc/sysconfig/cpupower once. And if they have done that already, that will transparently work during the upgrade mga4 -> mga5.
(In reply to Chris Denice from comment #24) > This does not mean that cpupower is broken; it just means that concerned > people will have to explicitly specify "ondemand" in /etc/sysconfig/cpupower > once. And if they have done that already, that will transparently work > during the upgrade mga4 -> mga5. People who explicitly did that know also how to change default the other way. I have a pstate cpu, and I never had to change the default : the ondemand failure leaves it on performance. Now we break current systems : laptops will loose at least 20% time on battery because WE changed the default...
The situation was the same before for people running enterprise servers that had to switch ondemand to performance. So for the time being, we have not choice, laptop users will have to read the ERRATA and, *may be* edit one file according to their wishes yes, that's correct. Please, stop exaggerating the situation, we have enough real bugs to fix than arguing why an user-land's default setting is not a broken feature.
Whiteboard: (none) => IN_ERRATA
Target Milestone: --- => Mageia 6
(In reply to José Jorge from comment #25) > (In reply to Chris Denice from comment #24) > > This does not mean that cpupower is broken; it just means that concerned > > people will have to explicitly specify "ondemand" in /etc/sysconfig/cpupower > > once. And if they have done that already, that will transparently work > > during the upgrade mga4 -> mga5. > > People who explicitly did that know also how to change default the other > way. I have a pstate cpu, and I never had to change the default : the > ondemand failure leaves it on performance. Now we break current systems : > laptops will loose at least 20% time on battery because WE changed the > default... Pstate don't use cpupower scaling governors to scaling cpu as it use it's own settings and let cpu scale that frequency. So in real you can't get any battery lost by changing govenor because they are not used at all with pstate. Here is few articles about pstate. www.phoronix.com/scan.php?page=article&item=intel_pstate_linux315&num=1 http://forums.fedoraforum.org/showthread.php?t=303598
CC: (none) => ozkyster
(In reply to Otto Leipälä from comment #27) > Pstate don't use cpupower scaling governors to scaling cpu as it use it's > own settings and let cpu scale that frequency. > That's it. Just to prevent cpupower service to say "Failed" we did a change that brings nothing technically to pstate CPUs, and we broke 'ondemand' CPUs... Nevermind, test sites like Phoronix will just say that MGA5 eats laptops battery on AMD and pre-pstate Intel cpus...
Does it harm anything that cpufreq service fail when not needed?
No if it's not used that what i have readed about it,problem is pstate don't support ondemand powersave and performance only. Problem is tmb can't change govenor to ondemand to acpi and pstate to powersave they need all changed to use same profile that's why performance is default,if he change acpi-cpufreq to powesave to default pc computers get huge slow down laptops are fine.
Is possible for the common users to add to MCC a new setting of the governor, that the user will choose a governor (powersave, ondemand, performance, etc.) by clicking instead of the command in shell? Thanks!
Good feature but it should added to manatools it's Mageia own settings panel it will replace mcc when it's stable enough.
After reading this bug, and changing "performance" to "ondemand" for my pre-2009 laptop, my problem of constant 99% to 100% cpu usage (and almost constant fan) goes to the old usual of less than 50% most of the time, with little fan activity, and faster keyboard response. (I had to reboot to see the change. Stopping/starting cpupower didn't help.) It runs a lot cooler as well. Right now hovering around 10% while adding this comment. So the "performance" setting has considerable impact on at least pre-2009 laptops. If/when tmb implements hardware detection for the cpupower setting, it will make a lot of laptop user's happy. Note that I had upgraded from mga4 to mga5. It wasn't a fresh install.
CC: (none) => andre999mga
Just a thought : Asking the user whether they want the setting "performance" = faster response, more power usage, or "on demand" = power usage according to tasks running (more economical) might be better than hardware detection, as even desktop users could want "on demand"
Yes. Example: A "desktop" acting as a mostly sleeping file server should use "on demand"
See my comment #25 : the bad idea was to change default setting to remove a failure warning at boot. pstate always does "ondemand" as it always change cpu frequency, even with "performance" or "powersave" setting.
CC: (none) => hhielscher
tmb, this bug report is currently set a release blocker for mga6. What's your opinion about it?
(In reply to andré blais from comment #34) > Just a thought : > Asking the user whether they want the setting > > "performance" = faster response, more power usage, or > "on demand" = power usage according to tasks running (more economical) > > might be better than hardware detection, > as even desktop users could want "on demand" Yes they wan't but pstate won't support it there is no ondemand there is only powersave and performance so it's impossible to change it to ondemand.
(In reply to Otto Leipälä from comment #38) > Yes they wan't but pstate won't support it there is no ondemand there is > only powersave and performance so it's impossible to change it to ondemand. I wonder how this can be discussed for so long : - pstate does not have ondemand because he does his own cpufreq - AMD cpus NEED ondemand because it is THE default setting for them. It was the default till MGA4, and is the first thing I have to change manually when I install Mageia in an AMD laptop. - cpupower failure with pstate trying to apply ondemand to it can be ignored, as it just keeps it in performance mode.
Governor is set to /etc/sysconfig/cpupower you acctually ask to add there ondemand even with pstate ? that would be only way to change it what is default,with that change users need to manually set performance or powersave to that file. That time you use to fight it will be changed by default you would already changed it 1000000 times manually it. There is no way to set amd to use ondemand pstate to use powersave or performance etc.... That would just solving this problem in 10 seconds if it would be possible.
(In reply to Otto Leipälä from comment #40) > Governor is set to /etc/sysconfig/cpupower you acctually ask to add there > ondemand even with pstate ? Yes. > That time you use to fight it will be changed by default you would already > changed it 1000000 times manually it. Sorry, my english is not good enough to understand this. > There is no way to set amd to use ondemand pstate to use powersave or > performance etc.... That would just solving this problem in 10 seconds if it > would be possible. As pstate is already in performance by default at boot, there is no need to set it manualy. So ondemand in /etc/sysconfig/cpupower would not change anything to pstate and be a good default for all other things.
So, cpufreq has improved a little, so I've changed kernel/cpupower behaviour a bit... In kernel-4.7.0-0.rc7.5.mga6 I have switched all cpufreq governors to builtin so all modes are available without need of loading modulees... and kernel now defaults to ondemand on the systems that supports it. If you install cpupower it switches to performance on service start, and back to ondemand on service stop. Lets see how it works out with installer, live medias and so on...
I get on a system with Nvidia driver (but not on another system with ati): "remove-boot-splash: Format of /boot/initrd-4.7.0-desktop-0.rc7.5.mga6.img not recognized" Snipped from terminal running # urpmi --auto-update : cpupower 4.7.0 0.rc7.5.mga6 x86_64 kernel-desktop-4.7.0-0.rc7.5.> 1 1.mga6 x86_64 kernel-desktop-devel-4.7.0-0.> 1 1.mga6 x86_64 kernel-desktop-devel-latest 4.7.0 0.rc7.5.mga6 x86_64 kernel-desktop-latest 4.7.0 0.rc7.5.mga6 x86_64 kernel-userspace-headers 4.7.0 0.rc7.5.mga6 x86_64 -snip- nvidia340 (340.96-37.mga6.nonfree): Installing module. ........................ ....... Creating: target|kernel|dracut args|basicmodules remove-boot-splash: Format of /boot/initrd-4.7.0-desktop-0.rc7.5.mga6.img not recognized Du borde starta om din dator för kernel-desktop-4.7.0-0.rc7.5.mga6
Oh crap, the previuos comment may be irrelevant; Something worse is happening: i uninstalled that kernel again and reinstalled and dracut spew many lines about duplicate dm (the system use LVM) and now can not boot, even on old kernel. *may* just be wrong entries in grub, but I just have no time to investigate now, just to say the previous problem may be result of another problem, in dracut, LVM something, disk (an SSD) or other hardware...
(In reply to Thomas Backlund from comment #42) > If you install cpupower it switches to performance on service start, and > back to ondemand on service stop. Thank you Thomas. Do you mean that now cpupower is not installed by default? As it is recommended by kernels, it always ends in my systems....
(In reply to Morgan Leijström from comment #44) > Oh crap, the previuos comment may be irrelevant; This has nothing to do with this bug, please do not hijack it!
(In reply to José Jorge from comment #41) > (In reply to Otto Leipälä from comment #40) > > Governor is set to /etc/sysconfig/cpupower you acctually ask to add there > > ondemand even with pstate ? > > Yes. > > > That time you use to fight it will be changed by default you would already > > changed it 1000000 times manually it. > Sorry i mean if it's performance people can change it from performance to ondemand now it's not needed anymore. You don't need to say sorry for your english language,i know we finnish people speak so much more better english than spanish.
(In reply to José Jorge from comment #45) > (In reply to Thomas Backlund from comment #42) > > If you install cpupower it switches to performance on service start, and > > back to ondemand on service stop. > > Thank you Thomas. Do you mean that now cpupower is not installed by default? > As it is recommended by kernels, it always ends in my systems.... Cpupower is installed by default beacause urpmi install automatically recommend packages you don't need to do nothing.
(In reply to Otto Leipälä from comment #48) > Cpupower is installed by default beacause urpmi install automatically > recommend packages you don't need to do nothing. Unfortunately I have if cpupower still defaults to performance (the subject of this bug report) : - system boots, new kernels default to ondemand - cpupower starts, and replaces the setting to performance! So end users will still be in performance setting while urpmi wants cpupower. Unrecommending it culd be a way to fix this bug.
@tmb is this really release blocker bug if performance governor can manually changed to ondemand. Performance is not killing any cpus so it's not even real excuse to force something because one user wan't it.? I don't see no point to keep it as release blocker as solution is given and this is not break again nothing. I have even myself changed performance always manually to powersave,but this still seems to be too much to use 1 minute time to change it manually.
+1, see my comment number 7. There are plenty of real bugs we need to fix. @tmb, you should dictatorially choose what you want and close this bug as invalid. cheers.
Assignee: tmb => kernelSource RPM: cpupower => kernelWhiteboard: IN_ERRATA => (none)
Well, things are changed. As far as I am concerned, cpupower does not work at all anymore on intel power state cpu. Now it defaults to powersave, which means that this bug is closed! But catastrophically, it is impossible to use it to switch to performance which is problematic for computing servers. cpupower -c all frequency-set -g performance does nothing. I'll open another bug report as it is unrelated to the discussion here.
Status: NEW => RESOLVEDResolution: (none) => WONTFIX
Blocks: 15527 => (none)