Re: p4-clockmod...ugh ondemand governor failed [Solved]

[anomaly65]

ondemand governor failed, too long transition latency of HW, fallback to performance governor

is the error message (dual p4 prescott server, problem since kernel 2.6.30)
[url]
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536183
[/url]
[url]
http://git.kernel.org/?p=linux/kernel/g ... a645d470a5
[/url]

Seems as though this is intentional, but I had no luck in trying the ACPI interface (rebuilt kernel without p4-clockmod; no joy).

Anyone found a reasonable workaround?
FWIW, I had no complaints about the behavior in the older kernels at all, and it worked quite well.
Now I'm essentially stuck at whatever manual frequency I set. Not the ideal solution with varying loads and not wanting to waste power.

Thanks,
andy

p.s. from the gentoo buglist:
This bug was cited on the LKML 091025 with the subject:
"Broken ondemand scheduler in Linux 2.6.30+ on Pentium IVs"

[url]
http://bugs.gentoo.org/show_bug.cgi?id=287463
[/url]

[anomaly65]

I reversed the change in 2.6.30+ kernels by "undoing" the following change (specifically the generic sabayon -33 kernel):

Code: Select all

--- a/arch/x86/kernel/cpu/cpufreq/p4-clockmod.c
+++ b/arch/x86/kernel/cpu/cpufreq/p4-clockmod.c
@@ -246,7 +246,10 @@ static int cpufreq_p4_cpu_init(struct cpufreq_policy *policy)
        cpufreq_frequency_table_get_attr(p4clockmod_table, policy->cpu);

        /* cpuinfo and default policy values */
-       policy->cpuinfo.transition_latency = 1000000; /* assumed */
+
+       /* the transition latency is set to be 1 higher than the maximum
+        * transition latency of the ondemand governor */
+       policy->cpuinfo.transition_latency = 10000001;
        policy->cur = stock_freq;

        return cpufreq_frequency_table_cpuinfo(policy, &p4clockmod_table[0]);



returning the value to 1000000 re-enables the p4-clockmod.

Whatever the other folks on LKML and various lists mention, the server is once again snappy, responsive, and response nicely to varying load conditions.

I understand the rational behind the changes, but this revert simply behaves very well on a dual proc server system. No complaints here.

Thanks,
andy
p.s. server load includes 2 5Tbyte software raid5 arrays, 4 remote desktop sessions always running, bittorrent client, and 32 NFS server procs running. very mixed load, but seems happy nonetheless. network traffic in/out avg 10Mbps continuous bidirectional.