[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] grey77:
I haven't seen KA sources but could guess whats going on under its hood (thx to ur explanations before hehe).

When we enable CPU core number 4 ("cpu4") of Big cluster (cpu4/nor_preferred mask "1 0 0 0", cpu4/min_cpus "1"), KA behaves as intended because interface to control Big cluster is exposed.

Otherwise (in case we disable cpu4 "node" core) it seems to try re-enabling all the big cluster in order to get access to its FS info (cpu4/cpufreq/stats, cpu4/cpufreq/interactive) etc.

2 for big cores config seems to be the maximum for 650 (6 core snapdragon). And while doing so it discards cpu4/min_cpus current value. Its a faulty logic compared to just enabling cpu4:

write /sys/devices/system/cpu/cpu4/online 1

w/o changing its core_ctl configuration.

2ALL: Anyways KA has one excellent feature called Custom Controls for GUI access to many "uncharted" fs settings. I created quite a few and shared them here:

https://xdaforums.com/showpost.php?p=71461544&postcount=1227

---------- Post added at 05:31 AM ---------- Previous post was at 04:55 AM ----------

Before I had read ur posts about CPU hotplug latency time, I had some basic notion of hotplugging not being for free, that it would require some initialization code and should have stalls (latency periods). So one might need to minimize sporadic hotplugging and cores` migration. I tried to fight it with

/sys/devices/system/cpu/cpu0/core_ctl/offline_delay_ms
/sys/devices/system/cpu/cpu4/core_ctl/offline_delay_ms

setting it to 200 or even 500ms. It would reduce unsteadiness (enabled/disabled cores` switching madness) under fluctuating load.

Actually for 1 little core out of 4 + 0 big cores setup we suffer from this hotplugging latency mainly while experiencing GUI interaction changes e.g. when we start a new application/begin scrolling/etc. It feels jerky at scrolling for a brief moment then it settles down with additional cores activated and fully loaded and it feels butter-smooth from now on.

And one more thing, for disabled first big cluster`s core (cpu4) core_ctl logic has to re-create a corresponding FS structure for accessing the core`s cluster control for applications - it takes quite a few ms. And it deletes FS structure after the core`s shutdown. This keeps happening again and again... Non-optimal behavior.

There has to be some give and take to mitigate this effect for extreme power saving setups like I described: one might want to keep permanently enabled 1 more little core ("1 0 1 0" + "0 0 0 0" setup) or one big core additionally ("1 0 1 0" + "1 0 0 0").

PS: ur setup (respecting core's attached cache and hotplugging latency) is especially great for gaming where CPU load fluctuates often. We have somewhat reduced active CPU cores decreasing thermal throttling probability while maintaining high performance.

Could u pls give a link to ur script. With default cpu.conf /proc/sys/kernel/sched_heavy_task has 0 value, sched_grp_upmigrate 130, sched_grp_downmigrate 110. It seems to be under-initialized.

Not at all. Ur posts r incredibly useful and in the right place. I've read ur cores<->cache dependencies explanation before but there is nothing wrong with repeating. I tested default config: its smoothness improved. But we might need, and u agreed on that, another config optimized for power saving :)

In the attachment cpu.conf I use for my "reader profile".