Messages in this thread | | | Date | Wed, 20 Oct 2004 16:30:57 +0200 | From | Dominik Brodowski <> | Subject | Re: [PATCH] cpufreq_ondemand |
| |
On Wed, Oct 20, 2004 at 03:35:35AM -0400, Len Brown wrote: > On Wed, 2004-10-20 at 01:03, Andre Eisenbach wrote: > > > ... If the > > speed steps down slowly but shoots up 100% quickly (as it is right > > now), even a small task (like opening a folder, or scrolling down in a > > document) will cause a tiny spike to 100% which takes a while to go > > back down. The result is that the CPU spends most of it's time at 100% > > or calming down. I wrote a small test program on my notebook which > > confirms this. > > The question is what POLICY we're trying to implement.
This is why there may be DIFFERENT policies a.k.a. governors in cpufreq.
> If the goal is > to to be energy efficient while the user notices no performance hit, > then fast-up/slow-down is an EXCELLENT strategy. But if the goal is to > optimize for power savings at the cost of impacting performance, then > another strategy may work better.
> The point is that no strategy will be optimal for all policies. Linux > needs a global power policy manager that the rest of the system can ask > about the current policy. This way sub-systems can (automatically) > implement whatever local strategies are consistent with that global > policy.
Put it in userspace, and let it ask the cpufreq core in the kernel to use a specific governor or another depending on what you want. That's what certain userspace daemons / scripts already do, btw.
Dominik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |