Messages in this thread | | | Date | Tue, 21 Oct 2003 22:32:15 +0200 | From | Dominik Brodowski <> | Subject | Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver |
| |
On Tue, Oct 21, 2003 at 11:36:56AM -0400, Daniel Thor Kristjansson wrote: > > The _user_ shouldn't set the cpu frequency hundred of times a second, > but a userland program should set the priorities. If you are just > looking at CPU Temperature and the idle loop for setting your cpu > frequency then it's fine to do it in the kernel. But if you are looking > at dozens of factors and balancing them it is much safer to do so in > userland.
Wrong. Passing "events" or "information" to cpufreq governors by cpufreq_governor() is much easier, cheaper, and more reliable.
> CPUFreq has been rearchitectured to allow this type of thing, > you can have a governor in the kernel that sets CPU Frequency based on > load within limits specified by a userland program.
Wrong again. CPUfreq has been rearchitectured to do this kernel-space. The userspace governor allows setting to specific frequencies by the user ["I _want_ 500 MHz and nothing else!"], and it offers backwards compatibility for the first-era cpufreq interface [LART project etc.].
> ACPI can meantime throttle the CPU if it gets too hot
However, frequency scaling is much more efficient on lowering the CPU heat, too.
> The user may know things the kernel doesn't such as "this laptop is > burning a hole in my pants." She might want to construct a policy that > doesn't minimize power consumption since she's plugged in, but gives the > CPU lots of juice at first when the idle goes down, but then backs off > if it detects a long running 100% utilization such as during a long > compile.
Yes indeed. She wants to set a cpufreq policy which suits of her needs: it consists of a - minimum frequency => not too low [she's plugged in] - maximum frequency => 100% - cpufreq governor => some kind of yet-to-be-written dynamic cpufreq governor with temperature or long-term-statistic knowledge.
_I_ wouldn't want to run this governor, though -- I want kernel compiles to complete as fast as possible. So, we need different in-kernel governors.
> This would maximize responsiveness in interactive settings but > still keep her lap comfortably cool when compiling mozilla. Putting the > complexity of policies specified by something like an XML file in the > kernel scares me, putting it in a userspace program that communicates > with a low level governor is a more comforting thought.
Well, the thing one of the cpufreq userspace programs does is really fine: based on low-frequency events [power plug-in, running specific programs, etc.] different cpufreq policies [see above] are selected. No XML file necessary.
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/
| |