On Mon, 13 Sep 2010 16:18:51 -0400 David C Niemi <dniemi@xxxxxxxxxxxx> wrote: > > > 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. > > > I have looked at the latest kernels too, and the changes in the > ondemand governor between that and RHEL 6's 2.6.32 kernel are quite > modest. I mention 2.6.18 just because it's what's been out in the > field a while. Most of the interesting changes were post 2.6.32 (2.6.32 is ancient too for mainline) > > 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. > > > I do see c-states getting used on Intel hardware to save power, and ondemand has nothing to do with c-states, c-states are handled by the menu governor. > in some cases these are quite effective. On AMD hardware lowering > frequency tends to be very important to saving power. AFAIK modern AMD doesn't need this either in c-states. > > ondemand and p-states mainly help you on moderate load. > > > > Just going to highest state unconditionally would be somewhat > > contraproductive to that goal. > > > On moderate load I might agree, but on the servers I care about it is > a workload that's a bit like war -- long periods of boredom > punctuated by sudden bursts of sheer terror. In this case on modern hardware you don't need a p-state governor at all except for "performance" -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
