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 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/
This archive was generated by hypermail 2b29 : Sat Aug 31 2002 - 22:00:24 EST