[Xiaomi Mi 4C] a5m:
What about a constant load? We presume the big cluster kicks in, do its job and that's it. That is not always the case.

My tests, where I remove such factors as thermal throttling and the other cluster influence, shows that big cores by themselves even at low frequencies are always hotter than little one at their maximum frequencies:

[IMG="Test of battery drain and temperature depending on cluster and frequencies"]http://image.prntscr.com/image/15ca2f6479b741bc8dd1060acbc6a5c6.png[/IMG]

Then let's have a look at MiUI Android 5.1 CPU settings. Little cluster target load is set to 65%. This mean that any task requiring 936 MHz will push little cores to 1440 MHz. If you limit max frequency to 1248 or even 960, you will not see any performance issues for these tasks, but will have significant temperature drop, though this has nothing to do with little/big balance. I know that you have AICP, so this is not about your system, but just an example that there are many factors at work.

Another example. Many, who use stock CPU settings, praised MiUI Nougat lower heat build-up. They changed CPU settings, specifically target load was set to 80% instead of above mentioned 65% and migration threshold (sched_upmigrate) to 99% instead of 85%. Big cores are utilized much less in this configuration.

You can change sched_upmigrate/sched_downmigrate pair to see if moving load to big cores earlier helps. These are the percentages of task demand for little cluster (1440 = 100%). When the load reaches sched_upmigrate threshold, the task is moved to big cluster. When it drops to sched_downmigrate (again, it is calculated against little cluster), the task is returning to little cluster. I.e. let's say we have this pair set to 70/85:

echo 85 > /proc/sys/kernel/sched_upmigrate
echo 70 > /proc/sys/kernel/sched_downmigrate

Our task needs 1300 MHz on little cluster. This is 90%. So the task will move to big cluster. With time the demand of this task can drop to the level where it can be handled by little cluster working on 960 MHz. This is 67%. It is less than sched_downmigrate, so the task will go back to little cluster.

P.S. But again, don't count to see nice 960 MHz or even 1248 MHz on a frequency monitor. If target load is set to 65% like in MiUI 5.1, we will see 1440 MHz, which can mislead you to think that big cluster is not working as hard as it should.

---------- Post added at 02:37 PM ---------- Previous post was at 01:51 PM ----------

There is a thing called HMP scheduler, which controls the cooperation between clusters. There are many parameters there, but for easy of use we can look at two of them: sched_upmigrate and sched_downmigrate. I explained them a little in my previous post. We set them with commands:

echo xx > /proc/sys/kernel/sched_upmigrate
echo yy > /proc/sys/kernel/sched_downmigrate

Cores switching on MiUI and most of the custom ROMs (if we speak about Mi 4c specifically) are controlled by another thing — core_ctl. It does not have much parameters. We need these one:

echo 0 > /sys/devices/system/cpu/cpu4/core_ctl/min_cpus
chmod 444 /sys/devices/system/cpu/cpu4/core_ctl/min_cpus
echo 2 > /sys/devices/system/cpu/cpu4/core_ctl/max_cpus
echo 60 > /sys/devices/system/cpu/cpu4/core_ctl/busy_up_thres
echo 30 > /sys/devices/system/cpu/cpu4/core_ctl/busy_down_thres
echo 300 > /sys/devices/system/cpu/cpu4/core_ctl/offline_delay_ms

min_cpus — how many cores of the cluster (cpu4 is a big one, cpu0 is little) are always switched on;

max_cpus — maximum quantity of cores (if you set it to 0 for big cluster it will stop working);

offline_delay_ms — that's what you have asked for: delay before switching off the core when it has finished all its work;

busy_up_thres and busy_down_thres are the percentage of load (0-100), but their work is not very intuitive for fine-tuning. High busy_up_thres causes more lag, low busy_down_thres makes cores harder to switch off.