[Xiaomi Mi Max Questions & Answers] Zola III:
Their is no simpler explanation.

The numbers I presented are extrapolated from numerous analysis published as scientific works all available floating around the net.

A) hot plug is relatively slow (not because of it self but) as awakening from deep retention states on all ARM CPU's up to date takes time (to init & test/flush queues and RAM subsystem integrity)

B) HPM scheduler is designed to place the work on first available ready CPU core that best meets the demand (dependant on given idle/packing parameters assigned to HPM)

C) hotplug will never be able to awake any core in deep retention state on time for a HPM decision timing

D) all transitions from one to another core (no matter which one) is costly.

So in short what could & needs to be done;

A) Ensure that at least one CPU is always active per cluster

B) Ensure that HPM is properly configured & running as intended (migration load, packing & idle conditions)

C) Minimise transition times (by providing optimal setup) and minimise their number.

How to achieve this?

Well;

A) properly configure hotplug disabling it to power down control core's that are needed to stay online all the time (this excludes the device sleep), example (of a 2+2 always on configuration on a octa core dual cluster SoC [S652]);

write /sys/devices/system/cpu/cpu0/core_ctl/not_preferred "1 0 1 0"

write /sys/devices/system/cpu/cpu4/core_ctl/not_preferred "1 0 1 0"

write /sys/devices/system/cpu/cpu4/core_ctl/is_big_cluster 1

B) there are two approaches with HPM super packing (Sony) & absolute idle load (Xiaomi on MiUI 8) both tied to min CPU's active and all CPU's active how ever the both approaches are wrong, high enough init with limited packaging & giving idling cores advantage is really the best way to go along with providing ideal conditions of available core's (which is 2+2)

C) this two already implied hire together make the ideal possible setup for a task placement & minimising the up/down migration times plus if set as shown (when possible) ensures the usage of all L2 cache available along with exclusive access, it also provides faster awakening of other core's when they are needed from deep retention state. The power drive cost is the same as the performance gain (5~6%) so for given job the power consumption is exactly the same while other positive effects remain. Additionally it's good to prevent up migration of the tasks that are lower priority & flagged as background tasks.

Notes:

1. If enabling the described hotplug configuration on the A53 cluster make sure that it's enabled only on the V2 revision of the core's & that the tool chain (compiler) is set to the strict ID-ing of the core revision along with no A53 erratums forced.

2. The given 2+2 configuration covers all possible scenarios of the thread migrations including SMP one's & it's considered as optimal one by me.

3. In order for this to work properly (& anything else for that matter) the general scheduler patching is required which is available in nijel8 Github kernel repository (mainline port fixes and mostly from Petr).

4. Alternative setup is all four A53 cores active with one A72 core's active all the time, it provides some power saving (in idle and low load states mostly) compared to 2+2 (with A72 core's which falls close to none with A73 core's) but it doesn't cover SMP up migration case along with minor performance degradation. The rest part remains the same.

Feel free to quote me.

As I believe in good old healthy logic which this is I don't find it particularly "smart" one either.

Best regards.