cpufreqtools

Hi all,

The multitude of cpufreq userspace tools is something I like very much: it offers the user the choice to use the tools which suits her needs best.

However, there are three issues which should be addressed, in my humble opinion:

A) A small tool which allows to modify cpufreq settings without having to type e.g. "/sys/devices/system/cpu/cpu0/cpufreq/scaling_set_speed" all the time.

B) A small tool which prints out cpufreq information helpful to developers and interested users.

C) A library, used by A), B) and any other cpufreq userspace tool that wants to do so, which allows for a unified code base on how to determine current cpufreq settings and how to modify or change them.

ad A) AFAIK, the "gnome-cpufreq-applet" contains a small tool named "cpufreq-select" which tries to do something similar. However, it requires some gnome libraries to be built and/or to run, and has some implementation shortcomings, like focusing on specific frequencies and not policies.

Therefore, the hereby suggested tool "cpufreq-set" should have the following options, IMO:

Options:

  -c CPU, --cpu CPU        number of CPU where cpufreq settings shall be modified
  -d FREQ, --min FREQ      new minimum CPU frequency the governor may select
  -u FREQ, --max FREQ      new maximum CPU frequency the governor may select
  -g GOV, --governor GOV   new cpufreq governor
  -f FREQ, --freq FREQ     specific frequency to be set. Requires userspace

governor to be available and loaded
-h, --help Prints out this screen

For example, the super-user can then run

# cpufreq-set -g ondemand
to switch to the ondemand governor on CPU 0, or
# cpufreq-set -c 1 -f 2000000
to switch to 2 GHz on CPU 1

ad B)
Options:

  -c CPU, --cpu CPU    CPU number which information shall be determined about
  -e, --debug          Prints out debug information
  -f, --freq           Get frequency the CPU currently runs at, according
                       to the cpufreq core *
  -w, --hwfreq         Get frequency the CPU currently runs at, by reading
                       it from hardware (only available to root) *
  -l, --hwlimits       Determine the minimum and maximum CPU frequency allowed *
  -d, --driver         Determines the used cpufreq kernel driver *
  -p, --policy         Gets the currently used cpufreq policy *
  -g, --governors      Determines available cpufreq governors *
  -a, --affected-cpus  Determines which CPUs can only switch frequency at the

same time *
-o, --proc Prints out information like provided by the /proc/cpufreq
interface in 2.4. and early 2.6. kernels
-m, --human human-readable output for the -f and -w parameters
-h, --help Prints out this screen

#./cpufreq-info
cpufreq-info 0.1-pre0 (C) Dominik Brodowski 2004
analyzing CPU 0:
driver: p4-clockmod
hardware limits: 300 MHz - 2.40 GHz
available frequency steps: 300 MHz, 600 MHz, 900 MHz, 1.20 GHz, 1.50 GHz, 1.80 GHz, 2.10 GHz, 2.40 GHz available cpufreq governors: userspace
current policy: frequency should be within 300 MHz and 2.40 GHz.
The governor "userspace" may decide which speed to use
within this range.
current CPU frequency is 2.40 GHz (asserted by call to hardware).

#./cpufreq-info -f -m
2.40 GHz
#./cpufreq-info -w
2399940

ad C)
check the "cpufreq.h" header file for the functions the library provides. It uses both the 2.4. /proc interface and the 2.6. /sys interface; as the 2.4. interface doesn't tell as much information as the 2.6. interface, it often returns 0 or NULL. The 2.6. code requires the libsysfs library from sysfsutils; I've developed it with syfsutils-1.2.0, it may also work with earlier revisions, too.

What needs to be done? The first implementation available at

http://www.brodo.de/cpufreq/cpufreqtools-0.1-pre0.tar.bz2
size: 15k
[License: GPL v2]

just "works for me" for A) and B), and has all the code for C) in it. Still missing is the following:

a) discussion about the need of such cpufreqtools, their (first) implementation, further requirements, shortcomings, etc.

b) thorough code review, especially from somebody aware of security issues. After all, some future revision of cpufreq-set may offer to enable the "setuid" bit.

c) adaption of cpufreq.h so that it can work with non-C programs/tools as well.

d) autotoolization and libtoolization. I tried to do so today, but failed big time. I simply have to few knowledge about these great tools to use them; so I'd need help in this area. I'd like to put the library in a subdirectory "libcpufreq/", only enable "sysfs" input if libsys is present, only enable "proc" input if so explicitely desired by the user; cpufreq-set and cpufreq-info should link against libcpufreq, too; and they should be put in a subdirecoty "utils/"... anybody willing to help me to do this?

e) The output should be corrected by someone who has better skills in the English language; and some documentation (man-files, README, INSTALL) be added.

f) internationalization / gettext. Should only be done once a)-d) are somewhat completed, though the hunks may be added earlier.

Thanks,
Dominik

I had intended long ago to add some cpufreq friendlyness to x86info, but lack-of-time got the better of me. It's good to have these tools. Good job.

Dave

I think that Jeremy's work being somehow integrated into your utilities. I think libspeedfreq.c is a good starting point for point C at least.

(reminder: http://www.goop.org/~jeremy/speedfreq/)

Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Unfortunately, I can't base the suggested cpufreqtools not on Jeremy's work, as it mixes userspace with kernelspace policies... and doesn't use libsysfs... However, updating speedfreq to use cpufreqtools seems to be possible and will probably lead to a code reduction in speedfreq.

Thanks,
Dominik

I do like Jeremy's idea to wrap all sysfs stuff in one deamon, then all clients (via his library) will communicate with this daemon in order to set different policies. So all you care is to secure this daemon, not random setuid programs that others may wrote.

Cheers,

Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

This looks like an interesting idea _on top_ of the libcpufreq stuff I suggest. Though, I'm not really convinced whether the overhead of a daemon is needed, as it should be clear to the admin that different cpufreq userspace tools running at the same time are a bad idea.

not others, /me ;-) Which may make it worse, though...

Thanks,
Dominik

Yep.

A fork()/execve() in order to just set a frequency do have some overhead which I think is more costly than messaging another process.

Everybody knows you *can't make bugs*

Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Yep, that was the intent. Though I've been thinking of changing it to use dbus rather than its own protocol. If we can define a dbus protocol everyone is happy with, then we can have other implementations, while having consistent UI/policy tools.

J

Hi Jeremy,

I think too that dbus is the way to go.
If there is not any big issue with dbus, we should use it for uniformity. Why invent a new protocol for this if not really necessary ? Consistent UI/policy tools is a nice thing to have.

I'd like to keep a "low-overhead" support by the C calls to libcpufreq, especially for the embedded area [I'm thinking especially of Johan Pouwelse's work]. A daemon, which may both accept a socket or dbus input, depending on configuration, can then be added on top of it. And as such I'd prefer to get a first revision of the cpufreqtools out soon, and add the daemon and dbus support later on. Patches will be _very_ welcome then.

Thanks,
Dominik

[...]

I definitely think it's useful. Probably versioned symbols could be a good idea for the library. Right now I'm (mostly) rewriting cpufreqd and I'd like to use such a library. It could be just a starting point to test the library usability :)

[...]

I'm working on it. Anyway I'm not a master autostuff user :) so some thing I'm going to say may be plainly wrong. I'll send you the result of my efforts asap.

Probably we'd need to completely split the package and _first_ install the library and only then the tools. Right now building both in the same package is beyond my autostuff knowledge, while having them in two separate packages is pretty simple to handle.
Also, I don't know if enabling aut (as in latin) sysfs aut procfs reading is a good idea because you may have many kernels with different configurations and recompiling the library each time you switch kernel is not that *friendly*.
Maybe having a function that detects _which_ cpufreq interface is used and pass its return value everywhere is better? opinions? Something like:

--- cpufreq.h
#define CPUFREQ_PROC_IFACE 0
#define CPUFREQ_SYSFS_IFACE 1
...
---

--- my_userspace_daemon.c
cpufreq_t which_iface = cpufreq_get_cpu_iface(); if ( cpufreq_set_policy(mycpu, mypolicy, which_iface) ) {
...
}
---

Or maybe provide macros to hide the above code?

I doubt my english is better than yours :)

good job Dominik :)

mattia
:wq!

For some stuff yes, for other things like "get current frequency of that CPU" it seems like overkill. Patches are welcome.

Excellent :)

That's great. Thanks for doing this.

Maybe I didn't express my intention too clearly: the code doesn't do "aut" (as in Latin) or either/or (as in English). It preferres sysfs, but doesn't find sysfs to be doable, it falls back to proc if possible.

check "interface.h" at the top:
#define INTERFACE_SYSFS
#define INTERFACE_PROC

You can define one of them or both; only both not defined will not work, of course...

As 2.6. kernels are preferred to use for cpufreq, but it depends on libsyfs -- and will only link correctly if libsyfs is present -- I'd like to make #define INTERFACE_SYSFS dependant on libsysfs; and #define INTERFACE_PROC on some "--enable-proc-interface" passed to ./configure...

Many thanks,
Dominik

[...]

Uh! sorry, it's me who didn't look at the code deeply enough, now I see that every function actually has a fallback to the proc interface (well, I noticed it but didn't inspect interfaces.h deeply enough).

[...]

Ok, I'll try consider this limitation in the configure script (see below)

so:
if libsysfs present and not --disable-sysfs-interface

    #define INTERFACE_SYSFS
  if --enable-proc-interface
    #define INTERFACE_PROC

if neither INTERFACE_SYSFS nor INTERFACE_PROC are defined
fail

does it sound good?

Also, do you agree in splitting your package in libcpufreq-VERSION and cpufreqtools (that depends on the former)?

mattia
:wq!

It sounds excellent. Somewhere later
if (--enable-sysfs-interface) && INTERFACE_SYSFS not defined
fail
if (--disable-proc-interface)
ignore -- disabled by default, unless --enable-proc-interface is passed

Yes, at least for the meantime. They may be re-merged into one before {lib,}cpufreq{,tools}-0.1 is released, though...

Many thanks,
Dominik