David C Niemi <dniemi@xxxxxxxxxxxx> writes: Perhaps better post to linux-kernel next time, I think cpufreq is mostly dead these days. > I have tested patches for both 2.6.18 and 2.6.32, but before sharing > them I'd like to first describe the problem I'm trying to solve and > the strategy I've been trying and get some feedback on it. These are all ancient in terms of mainline kernel. The latest kernel should have some improvements, perhaps try them first. On Nehalem class systems with recent kernels it often helps to use the "intel_idle" driver too, because that gives the governour more accurate latencies to work with. Many BIOS are known to report incorrect latencies. > The workload has periods of really high CPU utilization with lulls in > between, and the servers need to respond quickly to the onset of load > to avoid dropping packets. This resulted in 3 goals for my work with > the governor: > > 1) Negligible overhead when at high CPU utilization > 2) Save power when truly idle > 3) Ramp up quickly to the high-performance state when load appears FWIW when you're truly idle you typically don't need ondemand, the idle states on modern CPUs go to the lowest frequency by themselves or simply turn off the frequency completely. ondemand and p-states mainly help you on moderate load. Just going to highest state unconditionally would be somewhat contraproductive to that goal. -Andi -- ak@xxxxxxxxxxxxxxx -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
