On Thu, Dec 07, 2006 at 11:07:46AM -0600, John Goerzen wrote:
> On Thu, Dec 07, 2006 at 05:23:51PM +0100, Hendrik Sattler wrote:
[...]
> > "The support for this governor depends on CPU capability to do fast
> > frequency
> > switching (i.e, very low latency frequency transitions)."
> > The most important word is "very".
>
> I have yet to see a machine with trouble with this, though that doesn't
> say they couldn't exist.
$ grep -r 'policy->cpuinfo.transition_latency' arch/*
arch/arm/mach-integrator/cpu.c: policy->cpuinfo.transition_latency = 1000000;
/* 1 ms, assumed */
arch/arm/mach-sa1100/cpu-sa1100.c: policy->cpuinfo.transition_latency =
CPUFREQ_ETERNAL;
arch/arm/mach-sa1100/cpu-sa1110.c: policy->cpuinfo.transition_latency =
CPUFREQ_ETERNAL;
arch/arm/plat-omap/cpu-omap.c: policy->cpuinfo.transition_latency =
CPUFREQ_ETERNAL;
arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c:
policy->cpuinfo.transition_latency = 0;
arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c:
policy->cpuinfo.transition_latency)
arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c:
policy->cpuinfo.transition_latency =
arch/i386/kernel/cpu/cpufreq/cpufreq-nforce2.c:
policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
arch/i386/kernel/cpu/cpufreq/elanfreq.c:
policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
arch/i386/kernel/cpu/cpufreq/gx-suspmod.c:
policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
arch/i386/kernel/cpu/cpufreq/longhaul.c:
policy->cpuinfo.transition_latency = 200000; /* nsec */
arch/i386/kernel/cpu/cpufreq/longrun.c: policy->cpuinfo.transition_latency =
CPUFREQ_ETERNAL;
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:
policy->cpuinfo.transition_latency = 1000000; /* assumed */
arch/i386/kernel/cpu/cpufreq/powernow-k6.c:
policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
arch/i386/kernel/cpu/cpufreq/powernow-k7.c:
policy->cpuinfo.transition_latency = cpufreq_scale(2000000UL, fsb, latency);
arch/i386/kernel/cpu/cpufreq/sc520_freq.c:
policy->cpuinfo.transition_latency = 1000000; /* 1ms */
arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:
policy->cpuinfo.transition_latency = 10000; /* 10uS transition latency */
arch/i386/kernel/cpu/cpufreq/speedstep-ich.c:
&policy->cpuinfo.transition_latency,
arch/i386/kernel/cpu/cpufreq/speedstep-smi.c:
policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
arch/ia64/kernel/cpufreq/acpi-cpufreq.c:
policy->cpuinfo.transition_latency = 0;
arch/ia64/kernel/cpufreq/acpi-cpufreq.c:
policy->cpuinfo.transition_latency) {
arch/ia64/kernel/cpufreq/acpi-cpufreq.c:
policy->cpuinfo.transition_latency =
arch/powerpc/platforms/cell/cbe_cpufreq.c:
policy->cpuinfo.transition_latency = 25000;
arch/powerpc/platforms/powermac/cpufreq_32.c:
policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
arch/powerpc/platforms/powermac/cpufreq_64.c:
policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
arch/sh/kernel/cpufreq.c: policy->cpuinfo.transition_latency =
CPUFREQ_ETERNAL;
arch/sparc64/kernel/us2e_cpufreq.c: policy->cpuinfo.transition_latency = 0;
arch/sparc64/kernel/us3_cpufreq.c: policy->cpuinfo.transition_latency = 0;
I'd say half of the supported cpus haven't ondemand/conservative
available (CPUFREQ_ETERNAL automatically disqualifies the two
governors). :)
To automagically detect the thing you just have to load the proper cpu
driver (a script appeared here on the list), try to load all governors
and see what happens (AFAIR ondemand barfs if the transition latency is
too high, eventually just check /sys/..../scaling_available_governors).
I agree with others who said it's just unnecessary to force the whole
thing into the kernel.
--
mattia
:wq!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
