> "What is worse is that the interface is, in my opinion, fundamentally
> broken for *ALL* CPUs. It doesn't present a policy interface to the
> kernel, instead it presents a frequency-setting interface and expect
> the policy to be done in userspace. The kernel is the only part of the
> system which has sufficient information (idle times of all CPUs, for
> example) to do a decent job managing the CPU frequency efficiently.
> On Transmeta CPUs this policy should simply be passed down to CMS, of
> course; on other CPUs the kernel needs to manage it."
You might want to read the paper on the original cpufreq for ARM. It
gives real world cases where the user -needs- to be able to control the
policy. I think you misunderstand what the interface is about. Large
numbers of systems benefit from usermode policy engines.
cpufreq is an interface that allows the user to control the processor
speed. Period. It is not a policy, it is not a management system. Its
business stops at "don't blow up the computer". It enables user space
policies to be handled. It sequences events and notifies device drivers
so they can handle speed changes that affect them. (eg reclocking the
serial ports on the AMD Elan)
If you need a kernel policy engine then that should be a completely
seperate module. The cpufreq interface hs to provide "please change
speed" methods to the kernel. We already have one example of a kernel
policy engine that wants this facility. That is ACPI with native
processor speed control. ACPI is simply one possible policy engine.
Cpufreq is to power management as /dev/hda is to file systems.
Alan
-
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