[RFC] cpufreqtools

[RFC] cpufreqtools

[Dominik Brodowski]

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

Re: [RFC] cpufreqtools

[Dave Jones]

On Thu, Oct 21, 2004 at 07:22:27PM +0200, Dominik Brodowski wrote:
 
 > 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]

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

Re: [RFC] cpufreqtools

[Bruno Ducrot]

On Thu, Oct 21, 2004 at 07:22:27PM +0200, Dominik Brodowski wrote:
> 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.


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.

Re: [RFC] cpufreqtools

[Dominik Brodowski]

On Fri, Oct 22, 2004 at 04:39:27PM +0200, Bruno Ducrot wrote:
> 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.

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

Re: [RFC] cpufreqtools

[Bruno Ducrot]

On Fri, Oct 22, 2004 at 04:57:38PM +0200, Dominik Brodowski wrote:
> On Fri, Oct 22, 2004 at 04:39:27PM +0200, Bruno Ducrot wrote:
> > 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.
> 
> 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.

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.

Re: [RFC] cpufreqtools

[Dominik Brodowski]

On Fri, Oct 22, 2004 at 07:21:09PM +0200, Bruno Ducrot wrote:
> On Fri, Oct 22, 2004 at 04:57:38PM +0200, Dominik Brodowski wrote:
> > On Fri, Oct 22, 2004 at 04:39:27PM +0200, Bruno Ducrot wrote:
> > > 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.
> > 
> > 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.
> 
> 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. 

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.

> So all you care is to secure
> this daemon, not random setuid programs that others may wrote.

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

Thanks,
	Dominik

Re: [RFC] cpufreqtools

[Bruno Ducrot]

On Fri, Oct 22, 2004 at 07:47:45PM +0200, Dominik Brodowski wrote:
> On Fri, Oct 22, 2004 at 07:21:09PM +0200, Bruno Ducrot wrote:
> > On Fri, Oct 22, 2004 at 04:57:38PM +0200, Dominik Brodowski wrote:
> > > On Fri, Oct 22, 2004 at 04:39:27PM +0200, Bruno Ducrot wrote:
> > > > 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.
> > > 
> > > 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.
> > 
> > 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. 
> 
> This looks like an interesting idea _on top_ of the libcpufreq stuff I
> suggest.

Yep.

> 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.

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

> > So all you care is to secure
> > this daemon, not random setuid programs that others may wrote.
> 
> not others, /me ;-) Which may make it worse, though...

Everybody knows you *can't make bugs*

-- 
Bruno Ducrot

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

Re: [RFC] cpufreqtools

[Jeremy Fitzhardinge]

On Fri, 2004-10-22 at 19:21 +0200, Bruno Ducrot wrote:
> 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.

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

Re: [RFC] cpufreqtools

[Paul Ionescu]

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.

On Sun, 24 Oct 2004 18:30:25 +0200, Jeremy Fitzhardinge wrote:

> On Fri, 2004-10-22 at 19:21 +0200, Bruno Ducrot wrote:
>> 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.
> 
> 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

Re: [RFC] cpufreqtools

[Dominik Brodowski]

On Mon, Oct 25, 2004 at 01:07:05PM +0300, Paul Ionescu wrote:
> 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

Re: [RFC] cpufreqtools

[Mattia Dongili]

On Thu, Oct 21, 2004 at 07:22:27PM +0200, Dominik Brodowski wrote:
> 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:
[...]
> 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.

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 :)

[...]
> d) autotoolization and libtoolization. I tried to do so today, but failed

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.

>                                             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?

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?

> 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.

I doubt my english is better than yours :)

good job Dominik :)
-- 
mattia
:wq!

Re: [RFC] cpufreqtools

[Dominik Brodowski]

On Mon, Oct 25, 2004 at 11:01:39AM +0200, Mattia Dongili wrote:
> I definitely think it's useful. Probably versioned symbols could be a
> good idea for the library.

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

> 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 :)

Excellent :)

> > d) autotoolization and libtoolization. I tried to do so today, but failed
> 
> 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.

That's great. Thanks for doing this.

> >    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?
> 
> 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:
> 

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.

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

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

Re: [RFC] cpufreqtools

[Mattia Dongili]

On Mon, Oct 25, 2004 at 01:11:50PM +0200, Dominik Brodowski wrote:
> On Mon, Oct 25, 2004 at 11:01:39AM +0200, Mattia Dongili wrote:
[...]
> 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.

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).

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

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

> 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...

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!

Re: [RFC] cpufreqtools

[Dominik Brodowski]

On Mon, Oct 25, 2004 at 02:17:43PM +0200, Mattia Dongili wrote:
> 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?

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

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

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