On Thu, Dec 14, 2006 at 01:14:13PM +0300, Dmitry Krivoschekov wrote: > > > Ok, let's reword my sentence. The cpufreq interface does not support > > > voltage as a parameter > > > >Please explain why this is useful at all. > >Under what circumstance is "Set the CPU voltage to 1.2V" a useful thing > >for a user, sysadmin, or application to do ? > > > > > Voltage scaling is a well known technique to reduce power consumption, try > google search "Dynamic voltage scaling" if you are intrested in it. You've missed the point. I'm well aware of dynamic voltage scaling, and some of the cpufreq drivers I've written do this. > I agree, in most cases we don't need to scale CPU voltage and frequency > independently since CPU frequency usually coupled with appropriate voltage > to set. A CPU frequency _always_ has a specific voltage associated with it. > But some CPU's permit to choose frequency value for > a given voltage or vice versa But what sense does it make for a user,sysadmin or application to change voltage? If any of these want to save power, they do so by a) doing less work, and then b) lowering the clock speed as this is inherently tied to voltage. And if you lower voltage, you *MUST* reduce the frequency anyway. Running CPUs at higher speeds at lower voltages than those frequencies are rated for is a fastpath to a crash. This is one fundamental reason I'm opposed to exporting voltages to userspace. Because people _will_ get this wrong, and we will see all manner of strange bugs and crashes reported from people running CPUs at higher speeds than the voltage is rated for. By putting this into the hands of userspace, we're setting ourselves up to fail. How does userspace/users know what voltage is safe for what frequency? Without being intimate with the CPU datasheets, they're almost guaranteed to fail. The _driver_ needs to know the pairings of voltage/frequency and export the only thing that makes sense. > Also, CPU is not the only power consumer in the system, you may need to > scale voltage for other devices to get a best perfomance/power trade off. > And here is an obvious limitation of cpufreq since it takes care only > about CPU. You see it as a limitation, I see it behaving 'as designed'. If those devices have nothing to do with the CPU, why are they even relevant to this discussion? The argument seems to be "cpufreq only cares about CPU frequency, therefore we need something different". But, why? I see no reason why we need to change cpufreq at all, just add additional interfaces to cover those other devices, as they're unrelated anyway. And if there *are* any devices that are related, they can be tied into the existing cpufreq drivers just as for eg, the sa1100 drivers scale DRAM timings with CPU speed. Dave -- http://www.codemonkey.org.uk
