https://fedoraproject.org/wiki/Features/SysVtoSystemd
cpuspeed is usually used for one-time frequency/governor settings in Fedora; most of the work for that is done in its initscript... I'd rather move that to cpupowerutils and drop cpuspeed dead. It's last release was three years ago and it doesn't do more than other power managers in Fedora. http://www.carlthompson.net/Software/CPUSpeed
*** Bug 714433 has been marked as a duplicate of this bug. ***
The current Fedora kernel's default seems 'userspace', which makes almost no sense these days. The default governor should be 'ondemand' and no additional userspace fiddling should be done by default. This leaves only the cpufreq modules, and governor and cpufreq modules should probably just be compiled into the kernel, as only the kernel itself can really decide which driver to use, and in which order to load the individual modules. Relying on userspace and scripts to know the right kernel module names, and their probing order to bind the best one first, and not a fallback driver, just asks for trouble. We are currently working on making CPU modaliases working, which will allow us to auto-load cpufreq drivers like any other modules. But it might take some time until this is available.
CC'ing some kernel-side people for comments.
(In reply to comment #3) > The current Fedora kernel's default seems 'userspace', which makes almost no > sense these days. The default governor should be 'ondemand' and no additional > userspace fiddling should be done by default. > > This leaves only the cpufreq modules, and governor and cpufreq modules should > probably just be compiled into the kernel, as only the kernel itself can really > decide which driver to use, and in which order to load the individual modules. > Relying on userspace and scripts to know the right kernel module names, and > their probing order to bind the best one first, and not a fallback driver, just > asks for trouble. > > We are currently working on making CPU modaliases working, which will allow us > to auto-load cpufreq drivers like any other modules. But it might take some > time until this is available. It would be really nice if kernel handled it all. A simple "service" allowing the user to set their governor and frequency limits without all that stuff cpuspeed initscript currently does would be awesome.
> The default governor should be 'ondemand' and no additional > userspace fiddling should be done by default. ondemand isn't suitable for all scaling drivers. The switching latency on some older chips is horrible. It's the reason why conservative exists. unless we're ok with making older systems run slower every release, this would be a regression. I agree with the idea of killing off the userspace cpuspeed daemon though. There shouldn't be a case that it covers that ondemand or conservative aren't a better match for any more. > We are currently working on making CPU modaliases working, which will allow us > to auto-load cpufreq drivers like any other modules. But it might take some > time until this is available. I look forward to seeing this. For a long time the fact that every distro does their decision of "what driver to load" differently has bothered me. With more modern hardware moving towards just using acpi-cpufreq everywhere this should be getting simpler over time, instead of having to add more hacks like we have in the initscript. This still leaves the 'set the right governor based on the driver' problem, but in the future that could be something as simple as if (oldcpu) conservative else ondemand A longer term solution might be to just add a conservative behaviour mode to ondemand, and have the drivers for the older cpu's trigger that mode somehow.
(In reply to comment #6) > > The default governor should be 'ondemand' and no additional > > userspace fiddling should be done by default. > > ondemand isn't suitable for all scaling drivers. The switching latency on some > older chips is horrible. It's the reason why conservative exists. > > unless we're ok with making older systems run slower every release, this would > be a regression. Those users could just choose a different governor manually. Ondemand would not be the best for them but it shouldn't do any harm. > > I agree with the idea of killing off the userspace cpuspeed daemon though. > There shouldn't be a case that it covers that ondemand or conservative aren't a > better match for any more. Indeed. > > > > We are currently working on making CPU modaliases working, which will allow us > > to auto-load cpufreq drivers like any other modules. But it might take some > > time until this is available. > > I look forward to seeing this. For a long time the fact that every distro does > their decision of "what driver to load" differently has bothered me. > With more modern hardware moving towards just using acpi-cpufreq everywhere > this should be getting simpler over time, instead of having to add more hacks > like we have in the initscript. > > This still leaves the 'set the right governor based on the driver' problem, but > in the future that could be something as simple as > > if (oldcpu) > conservative > else > ondemand > > A longer term solution might be to just add a conservative behaviour mode to > ondemand, and have the drivers for the older cpu's trigger that mode somehow.
So what the conclusion is to drop cpuspeed ( it would be good to get it dropped then so we can remove it from the alpha blocker tracker )?
I still think we should compile the governors and scaling drivers in. And we should set the default to ondemand. Then we will need almost no setup at boot time. Only the kernel can know the right order of the CPU scaling drivers and how to choose the proper fallback. Userspace can never really know all possible names for modules to load. I guess a quick look at: /etc/init.d/cpuspeed will convince anybody that what we do today is a really bad idea. :) For the old boxes which might work better with 'conservative', I guess that switching logic also belongs in the kernel and not in userspace. Something like that should be done once at governor init time: if (oldcpu & governor == ondemand) governor = conservative Userspace is just too dumb to do that properly, and it should rightfully stay as dumb as it is today regarding internals of the CPUs. Userspace has not really a business in knowing what a specific kernel version can do with the CPUs or what it can't, or how kernel modules to load are named. I'll work on the CPU module auto-load soon, which can solve half of the problem, but I would still prefer to compile-in the stuff, unless we have a good reason not to. We ship the usb modules compiled in, so I guess we should be able to compile in the CPU drivers. :)
ok, changed in git so that.. - every arch now has the same cpufreq options (some were different) - all governors and scaling drivers built-in - ondemand by default We can drop the cpuspeed init file, and see what (if anything) breaks.
Created attachment 511793 [details] Patch that drops legacy sysv support from the spec file Just out of curiousty now that the legacy sysv init support is gone what purpose does it server or what arguments are for keeping the package in F16+ as opposed to drop it dead in favor of cpupowerutils as Petr mentiones in comment 1?
Kay, +1. Dave, great news! Jóhann, there are no reasons to keep it, afaic. A simple unit file in cpupowerutils package to manually select a different governor at boot will suffice. I'll file a bug for it. I'll also remove cpuspeed from Fedora (16+) today.
Ok remember to remove cpuspeed from the base group and also do put the bug you create for that simple systemd unit file to the blocker bug list ( 713562 ) I've removed cpuspeed from the wikipage https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd
No need to file a bug + this is a new introduction not a conversion hence it does not belong on the tracker bug and to save needless back and fourth you are probably looking for something like this.. [Unit] Description=Set CPU Governor After=syslog.target [Service] ExecStart=/path/to/script conservative ( or auto if the script is smart enough to figure it out ) [Install] WantedBy=sysinit.target This run relevantly early in the boot process which may or may not be needed... Oh and remember to close this bug so it goes of the blocker tracker ;)
(In reply to comment #14) > No need to file a bug + this is a new introduction not a conversion hence it > does not belong on the tracker bug and to save needless back and fourth you are > probably looking for something like this.. > > [Unit] > Description=Set CPU Governor > After=syslog.target > > [Service] > ExecStart=/path/to/script conservative > ( or auto if the script is smart enough to figure it out ) > > [Install] > WantedBy=sysinit.target > Since all will get really done by kernel now, something like EnvironmentFile=-/etc/sysconfig/cpupower ExecStart=/usr/bin/cpupower $CPUPOWER_START_OPTS ExecStop=/usr/bin/cpupower $CPUPOWER_STOP_OPTS will do just fine :) > This run relevantly early in the boot process which may or may not be needed... > > Oh and remember to close this bug so it goes of the blocker tracker ;) Don't worry :)
Created attachment 511878 [details] cpupower.service unit file
Created attachment 511879 [details] cpupower systemd configuration file
Package retired, removed from f16 comps. Rel-eng ticket: https://fedorahosted.org/rel-eng/ticket/4806
Should these changes be reverted because it is impossible to set maximal available frequency with cpupower.service as it was before? See bug 746372
no because you do not understand the output of /proc/cpuinfo these days a cpu is not running the whole time with their full speed vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz stepping : 7 cpu MHz : 1600.000 cache size : 8192 KB
This is source of problems with time in virtual machine that becam too much different from time in host system. I need to I set "cpu MHz" to value that was before "cpu MHz : 2145.378". Is there way to do this or these breaking things I should fix by manually rebuilding kernel?
# cpupower frequency-info analyzing CPU 0: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 10.0 us. hardware limits: 1.60 GHz - 1.86 GHz available frequency steps: 1.86 GHz, 1.60 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 1.60 GHz and 1.86 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.60 GHz (asserted by call to hardware). boost state support: Supported: yes Active: yes So it is not able to set frequency to 2145 MHz (which I set in BIOS) because maximum here is 1.86 GHz.
this was ages ago current kernels and open-vm-tools installed has no time-problems since a long time, i am working with virtual machines all day long on desktop also as server machines i have here 30 virtual machines on different locations and they all have exactly the same time
> So it is not able to set frequency to 2145 MHz (which I set in BIOS) > because maximum here is 1.86 GHz. well, why do you not buy a CPU with 2.1 GHz? there is really no need to quirk in kernel code for support hardware outside of any specifications - from 10.000 computers are 2 overclocked and any change fro them is a potentially sideeffect on the other 9.998
I will buy new CPU when I can but now I just want be able to return previous kernel behavior. If you don't what to fix this problem then at least provide me workaround that will restore frequency which I set.
> If you don't what to fix this problem i am no maintainer and can not fix anything but i am strictly against any quirks in any operating system for hardware outside any specification because if it ain't broken don't fix it
OK, I just ask in other way. Kernel maintainers decided to compile cpufreq modules in kernel: --- a/config-generic +++ b/config-generic @@ -4015,6 +4015,18 @@ CONFIG_PM_TRACE=y CONFIG_PM_TEST_SUSPEND=y CONFIG_PM_RUNTIME=y +CONFIG_CPU_FREQ=y +CONFIG_CPU_FREQ_DEBUG=y +CONFIG_CPU_FREQ_GOV_PERFORMANCE=y +CONFIG_CPU_FREQ_GOV_POWERSAVE=y +CONFIG_CPU_FREQ_GOV_USERSPACE=y +CONFIG_CPU_FREQ_GOV_ONDEMAND=y +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y +CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y +CONFIG_CPU_FREQ_TABLE=y +CONFIG_CPU_FREQ_STAT=m +CONFIG_CPU_FREQ_STAT_DETAILS=y + ## BEGIN ISA Junk. CONFIG_I82365=m How can I disable them in running kernel?
Please, made this modules loadable with systemd unit instead compiling them into kernel.
Userspace has no real idea which module to load in which order for which CPU, this needs to be compiled-in. Can't you tweak the stuff in /sys/devices/system/cpu/*
(In reply to comment #29) > Userspace has no real idea which module to load in which order for which CPU, > this needs to be compiled-in. But at least this can be configred what module to load while unconditional loading modules built it kernel can't be changed. > Can't you tweak the stuff in /sys/devices/system/cpu/* What exactly should I tweak? Do you mean /sys/devices/system/cpu/cpufreq/*? When I am on kernel from F15 without loaded cpufreq modules (and when CPU frequency is equal actual 2145 MHz frequency that I set in BIOS) /sys/devices/system/cpu/cpufreq/ is empty so I dodn't know what values should be there when cpufreq modules loaded (if I load acpi-cpufreq CPU frequency changes to 1.86 GHz).
Try the stuff in the individual CPU directories, one for every CPU: /sys/devices/system/cpu/cpu0/cpufreq/* You may also want to check the documentation, if there is something that fits your needs: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/cpu-freq/user-guide.txt;hb=HEAD
I disabled SpeedStep in BIOS. acpi-cpufreq built-in module was loaded when SpeedStep was enabled. I expected that cpufreq will be completely disabled in kernel after disabling SpeedStep but p4-clockmod built-in cpufreq module used instead of acpi-cpufreq and CPU frequency again changed to 1.87 GHz. Here some kernel messages: Detected 2145.326 MHz processor. Calibrating delay loop (skipped), value calculated using timer frequency.. 4290.65 BogoMIPS (lpj=2145326) ................. p4-clockmod: Warning: EST-capable CPU detected. The acpi-cpufreq module offers voltage scaling in addition to frequency scaling. You should use that instead of p4-clockmod, if possible. ondemand governor failed, too long transition latency of HW, fallback to performance governor ondemand governor failed, too long transition latency of HW, fallback to performance governor p4-clockmod: P4/Xeon(TM) CPU On-Demand Clock Modulation available And what is in /proc/cpuinfo now: cpu MHz : 1866.669 bogomips : 4290.55 /sys/devices/system/cpu/cpufreq is empty now. So your assumption that kernel itself can decide which driver to use is incorrect because kernel should not load any frequency scaling module after scaling was disabled in BIOS but it still loads cpufreq module.
I also disabled in BIOS other power saving options "Enabled C1 control" and "CPU Internal Thermal Control" but even after this p4-clockmod built-in module was used by kernel. This is completely wrong kernel behavior.
I am getting the same issues here. cpupower frequency-info is saying the maximum limit is 1.80GHz, yet it is set be 2.25GHz in the BIOS. How can I set the maximum in cpufreq to be the maximum I have the processor set to in the BIOS? Oct 18 17:51:56 tower20 kernel: [ 0.000000] Detected 2257.885 MHz processor. [root@tower20 sysconfig]# cpupower --cpu all frequency-info analyzing CPU 0: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 10.0 us. hardware limits: 1.20 GHz - 1.80 GHz available frequency steps: 1.80 GHz, 1.20 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 1.20 GHz and 1.80 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.20 GHz (asserted by call to hardware). boost state support: Supported: yes Active: yes analyzing CPU 1: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 1 maximum transition latency: 10.0 us. hardware limits: 1.20 GHz - 1.80 GHz available frequency steps: 1.80 GHz, 1.20 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 1.20 GHz and 1.80 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.20 GHz (asserted by call to hardware). boost state support: Supported: yes Active: yes
Is all this overclocking worth it? :) Anyway, a kernel boot option to disable cpufreq stack would be fine for nucleo (and a nice feature in general, I guess) -- does any kernel-specialist know if it would be difficult to add? Daniel, has that actually ever worked for you? I mean scaling with the ondemand governor up to your overclocked frequency?...
(In reply to comment #35) > Anyway, a kernel boot option to disable cpufreq stack would be fine for nucleo > (and a nice feature in general, I guess) -- does any kernel-specialist know if > it would be difficult to add? http://lists.fedoraproject.org/pipermail/devel/2011-October/158409.html
I had been using cpuspeed up until about a month ago when I finally upgraded this machine from F11, so I really can't say that cpufreq has every really worked or not. But it did work on F11 with cpuspeed, though.
(In reply to comment #3) > We are currently working on making CPU modaliases working, which will allow us > to auto-load cpufreq drivers like any other modules. But it might take some > time until this is available. Is there any news about modaliases for cpufreq modules? Is modaliases or cpufreq=disable kernel parameter will be available in Fedora 17 kernel?
modalias patches are posted upstream. We'll see how they shape up wrt whether they make it into f17.
Looks like cpufreq modules built in F15 kernel kernel-2.6.42.2-1.fc15 http://koji.fedoraproject.org/koji/buildinfo?buildID=296350 There is now in F15 config-generic: CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y CONFIG_CPU_FREQ_TABLE=y CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y Why this done for F15? Should this changes be only for F16+? So modalias is not implemented in 3.2 kernel. Is it will be in 3.3 kernel?
It was an error. has now been reverted.
Is modalias implemented in 3.3 kernel?
(In reply to comment #42) > Is modalias implemented in 3.3 kernel? No, it is about to be merged for 3.4.
So, 3.4 kernel with CPU modaliases released. Now CPUFREQ drivers will built as modules again?
So is this in place now? Can one do cpufreq=disbled or is it cpu_freq=n?
What about 3.6 kernels? Is cpufreq drivers can be built as modules again?