[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] mat9v:
Yes, but then I have keep loosing that 10% of power just on the hope that once I actually need that 2nd core it will run 30%? faster for a second? Yes, it diminishes performance, in benchmarks, with non-dependant threads because they have less cache for their use. In real life tasks it is the reverse because threads exchange data, share date and even operate on the same data.

Yes, in theory 8 full cores should be faster, but transfers between L3 cache halves incur up to 140ns penalty here not to mention Windows propensity to migrate whole threads (because it can) between CCX0 and CCX1.

I don't care about Ubuntu, I use Windows.

About our current Android phones:

Just disable forcing cores online (as setting min_cores to 0 for both clusters and not_preferred to 0000), set "busy_up_thres" to 90, "sched_upmigrate" to 95 and you will find that typically Android will only load 1 small core, run it at 1.4Ghz and not even dream of firing up any more cores. It won't be very energy efficient or smooth but it is our decision how we want our CPU to work. Remember that by default all small cores are online and that is how Qualcomm envisioned best core utilization. If I knew how I would show you that almost all the time 1 small core and 1 big core do all the system and app work at utilization level of below 50% (with my config that you can find published in few places) - unfortunately that would require some outside filming and youtube video to do that and I'm just too lazy to bother :)

You are right about integer/fp capabilities of A53/A72 cores but then what? You can't migrate threads based on app code, there is no way to do that and you have no ability to even test the app for its use without extensive debugging. Android does not make decisions about thread placement based on code but on core utilization, how busy it is while taking into account if waking up another core is required, and even then it is not aware of what kind of core the thread is running on (it only knows it is a small or big core) and it's capabilities, so if a mostly busy core is on a small cluster then it will wake another small core (unless "sched_upmigrate" has lower value then "busy_up_thres", then it will migrate the thread to big core first and reassess load value). We can't decide to run some programs on big cores and some others on small cores (I actually would love Windows style core pinning on Android sometimes, so I could for example force running Chrome on big cores) so we can't best utilize cores based on program content.

And yes, like most of our fellow phone users I won't be using specialized programs that take advantage of math libs :), in all discussion about performance capabilities of A53 vs A72 cores is academic because we don't have any way to enforce program placement one way or the other.

The same can be said about keeping 2 small and 2 big cores active, because how Android places tasks on active cores is load dependent and even if the task spawns on correct (from our point of view) core it may very well not stay there because it may not load the core sufficiently or load it too much so the load balancer will move it elsewhere. Again we have no way to pin programs or tasks to specific cores/clusters.