On Wed, 1 Jan 2014 20:03:35 -0800 (PST)
Patrick Wood <[email protected]> wrote:
> On Wednesday, January 1, 2014 5:54:20 PM UTC-5, Siarhei Siamashka wrote:
> > I myself still see no good reason for using any governor other than
> > "performance" when running with a wall connected power plug. Poor
> > default cpufreq behaviour is a major performance pitfall for
> > inexperienced users and it totally kills desktop responsiveness.
> >
> > We may introduce a new customized cpufreq governor and set it by
> > default. The users can always change the cpufreq settings to whatever
> > they want.
> >
> > Moreover, as a temporary solution, I would probably even advocate
> > setting the "performance" cpufreq governor for linux-sunxi kernels
> > by default (for the linux defconfigs). Do we have many tablet users,
> > who are running linux instead of android and also need good battery
> > life (have no usb ports or chargers nearby for providing power)?
>
> I believe that a minimum setting of 408MHZ with the "interactive" governor
> works quite well. This governor raises the CPU clock much faster than
> ondemand, and 408MHz seems to be a spot where the SoC will power down a lot
> of blocks when idle.
Is this just a speculation? Or some kind of research has been done?
What we know for sure is that the current cpufreq defaults ("ondemand"
for sun4i and "fantasy" for sun7i) are responsible for really poor
performance. Note that sun4i and sun7i are defaulting to different
governors for some unknown reason.
And there is one more source of inconsistency. The range of allowed CPU
frequencies and their voltages can be configured in fex files for
each device/board individually. For example, compare cubieboard2 and
cubietruck fex files:
https://github.com/linux-sunxi/sunxi-boards/blob/36a6f268b69afde7/sys_config/a20/cubieboard2.fex#L957
https://github.com/linux-sunxi/sunxi-boards/blob/36a6f268b69afde7/sys_config/a20/cubietruck.fex#L944
The minimum CPU clock frequency for the cubieboard2 is set to 400MHz.
And for cubietruck the lowest limit is 60MHz. This means that the
"fantasy" governor on cubieboard2 will run the idle system at 384MHz,
but on cubietruck that would be supposedly 60MHz. Funny, isn't it?
This is a big freaking mess.
> Also, perhaps the minimum setting should be 1GHz at boot time and not
> dropped until the UI is up and running, since this affects the overall boot
> speed by quite a bit, and that's the first impression any user gets of a
> distro -- how long it takes to get my login prompt or splash screen.
Does it mean that currently the "ondemand" / "fantasy" / "interactive"
governors are also responsible poor boot time? That's one more reason
to do something about this.
I tried to look into this stuff and run some tests on cubieboard2 and
cubietruck using the current stage/linux-sunxi-3.4 branch.
As Michal Suchanek mentioned earlier in this thread, we have AXP209
power management chip. And it has some interesting registers (REG 00H
and REG 01H):
http://linux-sunxi.org/AXP209#REG_00H:_Power_input_status
The values of these registers are exposed to the userspace via
/sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20_regs
AXP209 also has IRQs for the notifications about plugging/removing
different power sources: ACIN (power plug), VBUS (miniusb) and LiPo
battery. So looks like the hardware mostly provides all that we need.
Now the results of some tests are below. They were done with screen
blanked because this saves ~20 mA of current. I also have a LiPo
battery, earlier bought from OLIMEX:
https://www.olimex.com/Products/Power/BATTERY-LIPO6600mAh/
The connector of this LiPo battery is mechanically incompatible
with cubietruck, but I still got it temporarily connected just
for the sake of this experiment using jumper wires. Now the results:
=== cubietruck ===
# echo 1 > /sys/devices/platform/disp/graphics/fb0/blank
# cat /sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20_regs
only power adapter : REG[0x0]=0xc1,REG[0x1]=0x10
power adapter + miniusb : REG[0x0]=0xf9,REG[0x1]=0x10
only miniusb : REG[0x0]=0x3d,REG[0x1]=0x70
miniusb + lipo battery : REG[0x0]=0x3d,REG[0x1]=0x70
power adapter + lipo battery : REG[0x0]=0xc5,REG[0x1]=0x70
only lipo battery : REG[0x0]=0x1,REG[0x1]=0x30
Note: "only miniusb" and "miniusb + lipo battery" really have the
same AXP20 register values, that's not a typo.
Power consumption measurements with a multimeter on the 5V barrel
power plug:
idle at 60MHz : ~271 mA
idle at 912MHz : ~287 mA
Note: while cpufreq reports 60MHz clock frequency, the CPU really
runs faster than this and the benchmarks indicate that it
is more likely to be something around ~240MHz.
=== cubieboard2 ===
# echo 1 > /sys/devices/platform/disp/graphics/fb0/blank
# echo 60000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
# echo 60000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq
# cat /sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20_regs
REG[0x0]=0xc1,REG[0x1]=0x10
Note: The values of AXP20 registers are always the same (no matter
whether only a miniusb cable is plugged, or a barrel power plug,
or both of them).
Power consumption measurements with a multimeter on the 5V barrel
power plug:
idle at 60MHz : ~219 mA
idle at 912MHz : ~238 mA
Note: the 60MHz CPU clock speed is fake here too (just like for
the cubietruck).
===
Now what kind of conclusions can we make? The frequency scaling
is really broken in linux-sunxi, especially for sun7i (where it is
even failing to set the correct clock frequency). The power consumption
reduction on the idle system using "ondemand" instead of "performance"
governor is currently less than 10% for Allwinner A20 devices. That's
partially because they don't seem to be really able to clock the
CPU down to 60MHz.
Just as a reminder, for cubieboard1 with Allwinner A10 the difference
between idle 60MHz and idle 1008MHz was more significant (~192 mA vs.
~298 mA).
As a short term solution, I'm now really in favour of setting the
cpufreq governor to "performance" by default. In the case if there
are no objections, I'm going to send a defconfig patch in a few days.
It is in the best interests of the users of the battery power to
step in and contribute to cleaning this mess. Just setting the cpufreq
governor to "ondemand" does not really help to improve the battery
life. That's a kind of fig leaf solution. By the way, the performance
tuned distributions seem to be already changing the cpufreq governor
to "performance":
http://cubieboard.org/2013/12/21/a-debian-image-for-cubieboard2-cubieez/
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.
The users will be able to lookup the name of this new governor in
google and find linux-sunxi wiki with the detailed explanations
about how it works :-) Now what it really should do:
1. It can subscribe to the notifications from AXP209 about
plugging/unplugging the external power sources and run the CPU
at the maximum speed when external power is available.
This should solve all the performance issues for the
development boards and any devices running from the external
power sources. I believe that this is exactly the primary use
case for the vast majority of linux-sunxi users :-)
2. It might include the tweaks from http://linux-sunxi.org/Cpufreq
in the case if they are confirmed to be useful when running on
a battery.
3. In the case if we have only microusb connected and can take only
500 mA from it, then we might be interested in preventing the
battery from eventually getting drained. As we know, even the
CPU alone can cause more than 500 mA consumption if really
stressed. The cpufreq governor may try to limit the maximum
CPU clock speed if the LiPo battery charge is low and only
microusb is connected for charging it.
4. Maybe do something to prevent SoC overheating if CPU, Mali and
Cedar are all used at the same time? AXP209 has some ADC and we
might try to limit the CPU / Mali / Cedar clock frequencies
if the power drain is too high. But the properly working thermal
sensor in A10 / A20 (if it exists) would be of course a better
solution.
I may even give this a try on the next weekend. But frankly speaking,
I don't want to be sidetracked by this cpufreq stuff because it looks
like it may take more time than I can really afford to spend on it :(
--
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.
