On Fri, Apr 23, 2010 at 07:24:39AM +0200, Pavel Machek wrote: > Hi! > > > The ondemand cpufreq governor uses CPU busy time (e.g. not-idle time) as > > a measure for scaling the CPU frequency up or down. > > If the CPU is busy, the CPU frequency scales up, if it's idle, the CPU > > frequency scales down. Effectively, it uses the CPU busy time as proxy > > variable for the more nebulous "how critical is performance right now" > > question. > > > > This algorithm falls flat on its face in the light of workloads where > > you're alternatingly disk and CPU bound, such as the ever popular > > "git grep", but also things like startup of programs and maildir using > > email clients... much to the chagarin of Andrew Morton. > > > > This patch changes the ondemand algorithm to count iowait time as busy, > > not idle, time. As shown in the breakdown cases above, iowait is performance > > critical often, and by counting iowait, the proxy variable becomes a more > > accurate representation of the "how critical is performance" > > question. > > Well, and now, if you do something like cat /dev/<your usb1.1 hdd> > > /dev/null, you'll keep cpu on max frequency. Not a problem for new > core i7, but probably big deal for athlon 64. So that also means that my notebook's CPU fan will spin like mad as soon as I access a USB key ? It will not help the key go faster... Probably that iowait should only change the time required to go back to low frequency. That way, if there is no CPU nor I/O activity, we can switch back to a low frequency quickly, but if we see I/O activity, we could decide to wait for 1 second (for instance) for CPU idle before switching back to low frequency. > Maybe modern cpus can and should simply react faster? It's above all that we should not try to switch too fast if we know the CPU can't follow. Willy -- 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
