Hey, On Thu, Dec 23, 2010 at 12:34:02PM -0500, Dave Jones wrote: > On Thu, Dec 23, 2010 at 12:00:20PM +0100, Dominik Brodowski wrote: > > Interesting approach, but seems to be quite different from what "ondemand" > > does at the moment. And, as David Niemi pointed out, it seems to be more > > Intel-specific. Therefore, what do you think about adding this different > > algorithm as a different governor, and keep the "ondemand" algorithm more or > > less as it is? > > I'm hesitant to merge more governors. (We already have too many imo). AFAICS, we do have two in-kernel dynamic frequency scaling governors, one of which doesn't seem to get much usage (conservative)... > The userspace logic for automatically deciding which is the best one to use is > already pretty hairy, so any additional ones at this point would have to be > accompanied with some really compelling reasons why the existing ones can't > be fixed in an acceptable manner. Well, if the underlying alogrithm is fundamentally different -- such as when looking at sampling windows instead of the past one window -- this seems to be a "compelling" reason to me. Especially if one governor works well on certain platforms, and the other one works better on other platforms. Best, Dominik -- 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
