lkml.org 
[lkml]   [2003]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.086 / U:0.988 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site