[lkml]   [2002]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH][2.5.32] CPU frequency and voltage scaling (0/4)
On Wed, 2002-08-28 at 20:49, Linus Torvalds wrote:
> The point is that the _policy_ (not the end result) needs to be pushed
> down to the kernel, so that the kernel can do the right thing with it.
> That policy can be updated in "real time" from user space, of course. But
> the fact is that you cannot just set a frequency and leave it at that, it
> doesn't work.

If you look at the papers on the original ARM cpufreq code you'll see a
case where very long granuality user driven policy is pretty much
essential. The kernel sometimes does not have enough information.

Take a trivial example. My CPU is 99% idle. Should you drop the clock
speed right down. On a generic system yes, on a system which has to meet
very tight real time deadlines quite possibly not. In fact some
processors (eg the MediaGX) actually have hardware assists for speeding
the CPU clock up for realtime interrupt processing paths.

That argument ultimately boils down to "should the /proc interface to
cpufreq" be a seperate module to the core cpu_freq code called by kernel
policy engines like ACPI. The answer is obviously "yes" - /proc is just
one of the policy engines.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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