Big.Little is good for battery, right?

>>56593801
Big isn't. Little is. It depends on the workload.

>>56593829
That makes no sense.

You're basically saying that LITTLE is good for the battery, except then it should be using big instead.

The entire purpose behind big.LITTLE is to use the low power cores for very low demand ongoing processing, and then activate the big cores when burst processing needs to be done.

It's not that one is good and the other is bad, it's that both together make something good.

>>56593846
Not him, but big is good for performance, and little is good for battery. OP didn't ask about performance or overall user experience, only battery.

File: Screenshot_20160914-174910.png (181KB, 1080x1920px) Image search: [Google]

181KB, 1080x1920px

>>56593856
OP here, my priority is better battery life with smooth performance.

Other than decreasing frequency, is there a way for me to set a power target?

CPU is snapdragon 800 btw

File: Screenshot_20160814-165516.png (72KB, 1440x2560px) Image search: [Google]

72KB, 1440x2560px

>>56593801
My phone uses big little and I get way above average battery life and sot

Pic related was ~24h time on battery

>>56594012
Which phone?

>>56593856
But big is also good for battery, because it will complete processing faster than smaller cores.

That's part of the reason why Apple's processors are as good as they are, they're designed around completing processing as quickly as possible to go back to idle. iOS is more restrictive on what applications can do in the background so little isn't really required there, on Android though pretty much any application can do whatever it wants in the background (but developers should limit what they do within reason to prevent both poor performance and over usage of the battery) so a big.LITTLE configuration really benefits Android.

>Clock cores maximum to 5% lower than it's normal maximum rate
>Notice substantial battery life improvement

File: a.png (213KB, 1080x1920px) Image search: [Google]

213KB, 1080x1920px

this is what i do;
- enable aggressive multicore power saving, tries harder to keep things on fewer cores
- use conservative cpu governor
- tune it to use higher up/down thresholds (95 up, 90 down)
with this the cpu is at one core running at lowest frequency while idling consistently

the phone does /feel/ slower, as it takes a moment to kick up to a higher speed as you go to use it (for example, starting a scroll from idle, it's choppy for a couple frames, then it's fine), but heavier operations don't take longer, as it will go up to full speed when necessary

responsiveness and power efficiency don't really go hand in hand, you need to find a balance that suits you

>>56593801
Would this actually help battery life on older devices?

>>56594338
So that's why it lags.

>>56595545
No, the delay in the chip changing to the big cores is measured in microseconds. You literally couldn't hope to notice the delay.

It lags because the UI is bloated shit, loaded down with animations.

>>56594064
S7 edge international version (the one with the exynos processor)

>>56593917
If you have a snapdragon 800 you can't have big.little: the reason big.little works is the little cores have completely different power/frequency curves compared to the big ones, due to differences in architecture, cache size or layout.
Yours are 4 identical cores so it doesn't make much sense to limit a pair to a lower frequency than the other.

>>56596782
Lower frequency cores operate at a lower voltage and consume less power

>>56596969
They do, but all modern processors modulate frequency and voltage to lower power consumption and it doesn't have anything to do with big.little. Having two lower frequency cores on the snapdragon 800 doesn't make sense because the faster cores are going to slow down in frequency anyway when there is a smaller load, reaching the exact same efficiency as the slower cores at the same frequency since they are the exact same.