An on a different note, not to make things more difficult: the cpufrequtils package from ubuntu (at least this version: cpufrequtils_008-1_armhf.deb) installs an init.d startup file called cpufrequtils that sets the default governor to... you guessed it -- ondemand. This is easily overridden by putting
GOVERNOR=performance in the file /etc/default/cpufrequtils, but requires people to know that this is needed. On Sunday, January 5, 2014 9:50:24 PM UTC-5, Siarhei Siamashka wrote: > > On Mon, 6 Jan 2014 06:39:38 +0600 > Roman Mamedov <[email protected] <javascript:>> wrote: > > > On Mon, 6 Jan 2014 00:00:00 +0200 > > Siarhei Siamashka <[email protected] <javascript:>> wrote: > > > > > A better solution is to really ramp up the CPU to the maximum clock > > > speed if we have some external power source connected (ACIN or VBUS). > > > Adhering to the "principle of least surprise", it makes sense to fork > > > the "ondemand" governor with some new name and make it the default. > > > > A new governor (and a platform-specific one, no less) is unlikely to > ever be > > mainlined. > > It's a bit too early to talk about mainlining. We need to solve the > problem at hand before planning too far ahead. I proposed this > particular solution with the upgrade path for sunxi-3.4 in mind. > > Also I don't pretend to know much about power management. But the > current default cpufreq performance is simply unacceptable and > something has to be done about it. Enough is enough. > > > Try mainlining those "fantasy" or "interactive", you'll more likely > > be <del>laughed out of the building</del> politely pointed to all the > tunables > > of "ondemand", some of which I just listed in my other E-Mail. > > Well, it is the primary responsibility of the kernel to provide an > efficient way to use the hardware. If the kernel fails to handle > this efficiently for any reasons, then it is doing a poor job and > needs to be improved. > > And the kernel is indeed always evolving. New things are being > introduced whenever they are justified. And for example, do you > remember things like hyper-threading or turbo boost? Why haven't > those dudes been <del>laughed out of the building</del> politely > asked to design the hardware so that it plays nice with the existing > kernel without any need to introduce anything new? > > But why am I even explaining these obvious things? > > > If you *really* want to react to power events, there is no reason a > userspace > > program can't change max/min_frequency of the ondemand governor, or even > > switch between ondemand and performance as the power situation allows; > it could > > be either a daemon or a oneshot script called from udev(?), if changes > are only > > required on plugging/unplugging of power source. In fact I think there > should > > be something like that already (designed for laptops). > > AFAIK on the x86 laptops at least part of this functionality is handled > by the BIOS and ACPI. Which makes them a little bit different from ARM > hardware. > > In any case, I don't like the idea of forcing the userland to take > special care of sunxi specific power management when this can be better > done in the kernel. How the hell are you going to package it for many > different linux distributions? > > -- > Best regards, > Siarhei Siamashka > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
