Bug 713572 - Provide native systemd unit file
Provide native systemd unit file
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: cpuspeed (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Petr Šabata
Fedora Extras Quality Assurance
:
: 714433 (view as bug list)
Depends On:
Blocks: SysVtoSystemd
  Show dependency treegraph
 
Reported: 2011-06-15 15:32 EDT by Stephen Gallagher
Modified: 2013-01-10 03:20 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-07-08 06:26:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch that drops legacy sysv support from the spec file (1.21 KB, patch)
2011-07-07 16:48 EDT, Jóhann B. Guðmundsson
no flags Details | Diff
cpupower.service unit file (294 bytes, text/plain)
2011-07-08 05:42 EDT, Petr Šabata
no flags Details
cpupower systemd configuration file (98 bytes, text/plain)
2011-07-08 05:43 EDT, Petr Šabata
no flags Details

  None (edit)
Description Stephen Gallagher 2011-06-15 15:32:50 EDT
https://fedoraproject.org/wiki/Features/SysVtoSystemd
Comment 1 Petr Šabata 2011-06-16 05:25:59 EDT
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
Comment 2 Petr Šabata 2011-06-20 02:37:11 EDT
*** Bug 714433 has been marked as a duplicate of this bug. ***
Comment 3 Kay Sievers 2011-06-20 14:50:51 EDT
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.
Comment 4 Bill Nottingham 2011-06-20 14:54:47 EDT
CC'ing some kernel-side people for comments.
Comment 5 Petr Šabata 2011-06-21 02:17:01 EDT
(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.
Comment 6 Dave Jones 2011-06-21 13:11:46 EDT
> 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.
Comment 7 Petr Šabata 2011-06-22 03:14:12 EDT
(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.
Comment 8 Jóhann B. Guðmundsson 2011-07-07 13:05:32 EDT
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 )?
Comment 9 Kay Sievers 2011-07-07 13:37:37 EDT
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. :)
Comment 10 Dave Jones 2011-07-07 15:45:46 EDT
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.
Comment 11 Jóhann B. Guðmundsson 2011-07-07 16:48:42 EDT
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?
Comment 12 Petr Šabata 2011-07-08 03:06:38 EDT
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.
Comment 13 Jóhann B. Guðmundsson 2011-07-08 03:26:25 EDT
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
Comment 14 Jóhann B. Guðmundsson 2011-07-08 04:10:00 EDT
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 ;)
Comment 15 Petr Šabata 2011-07-08 04:18:58 EDT
(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 :)
Comment 16 Petr Šabata 2011-07-08 05:42:57 EDT
Created attachment 511878 [details]
cpupower.service unit file
Comment 17 Petr Šabata 2011-07-08 05:43:27 EDT
Created attachment 511879 [details]
cpupower systemd configuration file
Comment 18 Petr Šabata 2011-07-08 06:26:22 EDT
Package retired, removed from f16 comps.
Rel-eng ticket: https://fedorahosted.org/rel-eng/ticket/4806
Comment 19 nucleo 2011-10-15 06:10:52 EDT
Should these changes be reverted because it is impossible to set maximal available frequency with cpupower.service as it was before?
See bug 746372
Comment 20 Harald Reindl 2011-10-15 07:10:06 EDT
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
Comment 21 nucleo 2011-10-15 07:23:07 EDT
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?
Comment 22 nucleo 2011-10-15 07:26:47 EDT
# 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.
Comment 23 Harald Reindl 2011-10-15 07:27:22 EDT
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
Comment 24 Harald Reindl 2011-10-15 07:30:56 EDT
> 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
Comment 25 nucleo 2011-10-15 07:41:04 EDT
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.
Comment 26 Harald Reindl 2011-10-15 07:59:20 EDT
> 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
Comment 27 nucleo 2011-10-15 08:05:33 EDT
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?
Comment 28 nucleo 2011-10-15 11:29:58 EDT
Please, made this modules loadable with systemd unit instead compiling them into kernel.
Comment 29 Kay Sievers 2011-10-15 14:06:39 EDT
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/*
Comment 30 nucleo 2011-10-15 15:18:47 EDT
(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).
Comment 31 Kay Sievers 2011-10-15 20:32:06 EDT
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
Comment 32 nucleo 2011-10-15 21:53:57 EDT
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.
Comment 33 nucleo 2011-10-16 07:32:02 EDT
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.
Comment 34 Daniel Belton 2011-10-18 19:47:01 EDT
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
Comment 35 Petr Šabata 2011-10-19 02:46:51 EDT
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?...
Comment 36 nucleo 2011-10-19 03:05:35 EDT
(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
Comment 37 Daniel Belton 2011-10-20 02:53:58 EDT
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.
Comment 38 nucleo 2012-01-02 17:52:49 EST
(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?
Comment 39 Dave Jones 2012-01-03 11:34:07 EST
modalias patches are posted upstream. We'll see how they shape up wrt whether they make it into f17.
Comment 40 nucleo 2012-01-31 19:30:49 EST
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?
Comment 41 Dave Jones 2012-02-01 13:14:38 EST
It was an error. has now been reverted.
Comment 42 nucleo 2012-03-19 19:47:10 EDT
Is modalias implemented in 3.3 kernel?
Comment 43 Kay Sievers 2012-03-19 20:53:18 EDT
(In reply to comment #42)
> Is modalias implemented in 3.3 kernel?

No, it is about to be merged for 3.4.
Comment 44 nucleo 2012-05-21 20:08:23 EDT
So, 3.4 kernel with CPU modaliases released.
Now CPUFREQ drivers will built as modules again?
Comment 45 anil 2012-06-16 09:04:33 EDT
So is this in place now? Can one do cpufreq=disbled or is it cpu_freq=n?
Comment 46 nucleo 2012-10-17 19:41:54 EDT
What about 3.6 kernels?
Is cpufreq drivers can be built as modules again?

Note You need to log in before you can comment on or make changes to this bug.