cmpxchg on "suspend vs idle vs running, on mobile devices"

courtesy: cmpxchg aka tim murray 

suspend is the big hammer. in suspend, you turn off all peripherals, turn off the CPUs entirely, 
put the DRAM into self-refresh. power consumption is very low. if you've ever put a tablet on
a table and come back a month later to find that it's still on, that's because it's been suspend 
99.9% of the time, and it's drawing a tiny amount the whole time.

problem with suspend is that  it takes a nontrivial amount of time to enter/exit, so you can't 
do it when somebody has to interact with the phone soon. on Android, suspend never happens while 
the screen is on. if you ever wondered what a wakelock actually does, it prevents suspend. that's it.

idle: when your CPU has no scheduled work, it can enter a couple of different idle modes. these 
vary based on the CPU arch, but the ideal (and true on the majority of CPUs at this point) is 
that there is a deep idle state that power gates the entire core off. so if you have no work, 
you can power gate all cores off, your power consumption is relatively close to suspend. you keep 
peripherals on, DRAM controllers on, etc, so you can come out of idle very quickly. so android 
enters/exits idle constantly. run systrace with the idle tag and you'll see that idle is always happening.

now for the DVFS curve stuff. reason why you want idle is because there are two parts to CPU power consumption.

there's static leakage, which is the cost of keeping the CPU powered at all, and there's dynamic 
leakage, which increases as frequency increases. frequency increases require voltage increases at 
certain points, and that causes a quadratic growth in dynamic leakage, so the DVFS curve looks 
like a quadratic curve plus some baseline (which is static leakage).

deep idle where you power gate the entire core off removes both dynamic leakage and static leakage, 
and static leakage can be really high on some architectures. generally depends on process node.

if you ever wondered why snapdragon 808/810 sucked, it's because the static leakage on the A57 cluster
was completely obscene. turning on the A57s at all, even at 384MHz, was more power than running the 
A53s at 1GHz or more, but the A57s weren't faster than A53s at max clocks until you hit 1GHz or so. 
static leakage got way better with finfet process nodes, which is why chips built on 14FF samsung/16FF 
TSMC were such a leap over 20nm non-finfet TSMC.

the reason why the CPU is such a big consumer of power is largely because the CPU is involved with 
everything--you can't do anything with just the GPU or just the screen, the CPU has to mediate and 
that means power. the CPU also has to clock up to hit UI responsiveness thresholds, and that causes 
big power spikes. changing clocks has its own power impact, so you can't clock up for 5ms and then 
clock back down. when I measured this on 5X/6P, you could actually PWM between two CPU frequencies 
every 10ms and get exactly the expected performance result from an intermediate frequency, but the 
power consumption was significantly higher than just running the higher frequency constantly.

so you're usually better off leaving the higher clocks for idk 100ms or so? however, all CPUs I can 
think of since Krait went away are rocking per-cluster frequency, not per-core. so you have to increase 
clocks for some set of CPUs at the same time, even if only one of those CPUs is doing anything that 
requires high performance. 

anyway there you go that's a CPU power consumption brain dump while I have the flu.

(q: So when does suspend actually gets called on Android? When there are no wakelocks? Also what happens on doze?)

yes, when there are no wakelocks. screen is a wakelock, network can be a wakelock, but network packets 
can bring the system out of suspend. which is how gcm et al work. doze is basically a way to try to 
ensure the system stays in suspend for as long as possible.