cpufreq and changing driver

Bruno Ducrot ducrot at poupinou.org
Wed Nov 30 20:13:36 GMT 2005

On Wed, Nov 30, 2005 at 10:05:04AM -0800, Nate Lawson wrote:
> Marco Calviani wrote:
> >Hi,
> >
> >2005/11/30, Bruno Ducrot <ducrot at poupinou.org>:
> >
> >>You have to load the cpufreq.ko module at boot.
> >>Adding that line:
> >>cpufreq_load = "YES"
> >>to /boot/loader.conf
> >>should be OK.
> >
> >
> >I have that line in that position, and it seems working. The point is
> >that i would like to change the driver and use (AFAIU) a better driver
> >for my system (est).
> >In particular i have:
> >
> >dev.cpu.0.%desc: ACPI CPU
> >dev.cpu.0.%driver: cpu
> >dev.cpu.0.%location: handle=\_PR_.CPU0
> >dev.cpu.0.%pnpinfo: _HID=none _UID=0
> >dev.cpu.0.%parent: acpi0
> >
> >Maybe i didn't understood well: but what i have to do to use the Intel
> >Enhanced SpeedStep driver?
> You should send the full output of "sysctl dev.cpu".  There is no 
> cpufreq driver (est, acpi_perf, or other) driver running.  Perhaps look 
> at your dmesg to see if one is probing/attaching.
> If you are using acpi and load cpufreq.ko, you've got all the cpufreq 
> drivers in one package.  The right one for your platform will 
> automatically probe/attach.
> >>powerd need some rework in order to get it working properly.  There
> >>is one FreeBSD project on that subject if you are interrested.
> >
> >Well, thanks i'm very interested, although i'm not at all experienced
> >in kernel programming....
> >
> >I'm not inside this issue, but it would not be possible to "emulate"
> >the behaviour of the ondemand governor? (sorry if this question makes
> >no sense)
> I have no idea what you mean by "on-demand governor".  The only 
> automated control of cpu speed is either by the BIOS (which we can't 
> control) or the TM/TM2 (and that one is heat-based, not load-based).

The ondemand governor is basically an implemation of the following

There is a counter, say count.

at each given fixed intervall:
if (idle less than a watermark) {
    frequency full
    reinitialise count to 10
} else if (idle more than another watermark) {
    decrement count
    if count is 0 {
        down one step the frequency
else reinitilize count to 10

Note that in the latter case, the down step is performed only
after 10 such comparison.  In other word, intervall is ten times
larger for the down side than the full frequency one.

This work well when you can perform, say, 20 to 50 transitions per
second.  Otherwise, it is pretty bad.

Bruno Ducrot

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

More information about the freebsd-questions mailing list