yashsingh1/xdaforums huggingface dataset:
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] Zola III:
Would actually suggest making that min two cores per cluster as almost any task will need to awake the other core on a same cluster anyway as almost all tasks are MP this day's. Matt did experimenting and found out that this actually even saves some juice (not really much but it does & that part is actually surprising). Thing is integer tasks are much better to be executed on A72's while floating point (vfp) one's will be benefited much less & with NEON SIMD benefit is almost none, both VFP & NEON floating point instructions benefit largely from core parallelism and are for all of that much better to be executed on A53's (especially as they consume much less energy). Any way as we can't influence neither where nor how regarding parallelism will their be executed best we can is ensure optimal setup ready on both clusters. Did my own testing regarding core performance/scaling metrics with Dhrystone, Whetstone & Linpack test from Roy Longbenton.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] mat9v:
Here is my governor and core control setup:

I went back to 1 minimum active core per cluster because by statistics, almost 90% of screen on time my cpu spent with 1 small core and 1 big core active, that kind of put into question the need for 2 core in a cluster being active all the time. I'm currently testing battery life once more, probably with all the rom flashing and modem changes I did not keep "all other things equal state" so I won;t be flashing anything for next 2 weeks :)
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] oatcooky:
Stupid question but how come I can't use the write command in a root shell in a terminal app? Seems like it works only in init scripts. Outside of that, i get a "write: not found" error.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] mat9v:
Change

to

Write is a command used during kernel boot, the listing contains commands used in "init.qcom.power.rc" in kernel ramdisk, you can't use it in user scripts or in terminal.

I have included those as a source for

values

for different settings that I use.

Remember to keep those " " because they are important

write /sys/devices/system/cpu/cpu4/cpufreq/interactive/target_loads "36 400000:20 883200:35 940800:51 998400:56 1056000:61 1113600:68 1190400:77 1248000:89 1305600:95 1382400:96 1612800:97 1747200:98 1804800:99"

to

echo "36 400000:20 883200:35 940800:51 998400:56 1056000:61 1113600:68 1190400:77 1248000:89 1305600:95 1382400:96 1612800:97 1747200:98 1804800:99" >/sys/devices/system/cpu/cpu4/cpufreq/interactive/target_loads
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] Tysovwik:
Will it work with latest nijel kernel (core CTL tweaked) or only with custom like harfix ?)

BTW not all setting applying well as init d script, some ones ignored

So best way to integrate this setup to boot IMG file?
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] grey77:
Nijel, yet u do initialize the symetric settings for the Big cores (cpu4).

Yup, 0% for up_thres caused all the 4 little CPUs to be online permanently. But I do believe setting them with some conservative values wont hurt, like 60% for up and 40% for down. IMHO its better than just skipping them at all.

ppl say its even more buggy, with some demo code pieces left in the release version.

The main question about the current core_ctl is if I dont exclude cpu4 core from core_ctl handling would this wrong "root node" cpu4 handling affect Interactive governor functionality?

As I said I dont care of incorrect statistics I wouldnt like to sacrifice power efficiency cuz the majority of time my usage profile is reading. I ran ur builds w.o forced cpu4\not_preferred="1 0 0 0" and big_cpus_min=1 for like a week and had no major issues. Kernel Adiutor being unable to read governor tunables and some other apps failing to read core status is not a problem for me.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] pawwaap:
Please, explain a little,

as I understand you provide the kernel with some exposed text console interface,

and also the file to push it through net ADB from a PC computer to /data/local/tmp, and then to change its permission to executable and execute it,

just to read processor data in realtime (what data exactly)?

How is it superior to some GUI apps analysing system data e.g. LSpeed, KernelAuditor, CoolTool, SystemPanel, SystemTuner etc?

As also have understood this exposed interface we can also use for setting CPU parametters, and its examples you alresdy shared here.

Where to write them to have them executed and set on every boot?

Are there any settings in ramdisk here and do you recommend to change it on our own?

As this instance:

And maybe easier is to apply somewhere this:

e.g. including in some file in /system/etc/init

or elsewhere (please say where)?

HELIUM 364GB ;) locked BL, Nijel's LineageOS
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] mat9v:
Yes, the best way is to integrate, just like Nijel8 did :)

My settings would replace Nijel8's so be careful not to leave double entries. Also be careful about structure of the file as it defines three distinct domains for configuration: "on boot", "on enable-low-power" and "on charger" and 3 smaller ones at the end of file. Please put all configuration entries under "on enable-low-power" heading.

Or I can link you a modified boot image from latest rom with my changes (if you have Helium, I tried to make one for Hydrogen for my friend, but somehow he gets reboots).

My boot image is modified for Harfix 2.1
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] E90 Commie:
Thank you for this. I would be very grateful if you would share your tweaked Harfix 2.1 based solution since it sounds like a perfect fit for the Helium.

Keep up the good work.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] mat9v:
Ok. Here it is https://drive.google.com/open?id=0B2kA19dFXzvzMzBRVUhtZFZmMmM

This is for Nijel8 rom from 11.march.2017 rom for HELIUM. Flashing on anything else MAY result in non-bootable system

Remember that you have to flash Harfix 2.1 over it!!!
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] E90 Commie:
Harfix 2.1 runs great under RR so I will try your script on it - I guess it will run well. One question before I go ahead: Is it OK to use L Speed or could there be any clashes? I usually use that app to tweak the system.

Thank you very much.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] Viriato.pt:
FM Radio offline is avaiable?

Does this rom have an app like MIUI for listen to radio over FM not by data?

It seems that spirit radio app is not supported any more.

This is a huge reason for me not to swap from miui to LOS.

Thanks in advance
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] pawwaap:
Is it to flash into boot partition? (As when you flash img then TWRP ask for partition to choose)

And just afterwards Harfix, right?

HELIUM 364GB ;) locked BL, Nijel's LineageOS
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] nijel8:
It shouldn't... haven't noticed anything bad. Low level kernel code(incl. governor) has controlled access to nodes(if no bugs of course).

Nothing is exposed. It's just a simple script to monitor in real time how core_ctl do what it does... hotplugging cpu cores. Nothing more.

How is it superior? Can you monitor core_ctl with screen OFF? Or in near perfect idle state with no front tasks running? And with a little digging in /sys you can customize it to monitor anything happening under the hood. ADB over network is to exclude any affect that USB charging might have on all these things like putting something in performance mode or whatever...
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] mat9v:
Harfix, yes it runs great but if you flash kernel from Nijel8's rom and Harfix over it on RR rom I can almost guarantee you won't even boot. Unless something changed in the last few weeks it's a big nono.

If you want to use L Speed, disable anything concerning governors, core control and gpu config before installing kernel - those settings will conflict and most likely overwrite mine so it would be useless.

It works like this:

- when you install RR it comes with it's own kernel, that KERNEL is encased in RAMDISK (where most configuration scripts are)

- when you flash my provided boot image from Nijel8 rom, you will change not only kernel but ramdisk as well along with all configuration scripts - at that point you will most likely get a bootloop or just won't boot

- now if you flash Harfix, it will extract whole boot image from boot partition and unpack it, change kernel leaving ramdisk intact, compress it into new image and flash it to boot partition. In this way you will get Harfix kernel with Nijel8 LAOS based ramdisk - that combo will most likely not boot because scripts are from LAOS (modified by me but still LAOS compatible)

Harfix does things that way to remain compatible with wide selection of roms and it won't change.

For now I don't know which files to modify in RR to get my settings working and do not plan to try.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] Tysovwik:
At 11 March build I still have annoying bug with virtual cursor mouse appear during touching the screen. Dirty flashed from build 21 Feb, system wipe.

Pls fix it :)
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] mat9v:
Found an interesting read about fixes to Linux scheduler :)

https://blog.acolyer.org/2016/04/26/the-linux-scheduler-a-decade-of-wasted-cores/

and the git with changes :)

https://github.com/jplozi/wastedcores

Nijel8, you may find that interesting to read even if those changes are implemented in Android now :) (if you had not read it to date).
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] E90 Commie:
Thank you. I am leaning on making the following experiment:

1. Flash RR.

2. Flash SuperSU.

3. Flash your script.

4. Flash Harfix r2.1.

5. Flash G-apps.

Then I will simply see how it goes. It either works or doesn't work but since your scripts sound very interesting I am ready to simply see what happens.

My personal theory or rather driving force behind testing is that it "*might* work (it is a big but and might) because of the Harfix 2.1 as a common denominator and also because RR is 'built upon' Lineage OS. I am fully aware of the pitfalls and that the risk is for a boot issue but no harm done, just reflash then.

It seems like a new build of RR is coming out for Helium in a few hours so my idea is to experiment tomorrow and see how it goes. I think it is worth a shot.

One other question, though: Would you recommend Kernel Adiutor or another tweaking app to 'clone' as much of your profile as possible in case of a non-booter under RR? I am entertaining the idea of trying to setup KA as close as possible as a backup plan.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] pawwaap:
After flashing new kernel SuperSU doesnt work, needs reflashing, it visbly patches kernel to function.

HELIUM 364GB ;) locked BL, Nijel's LineageOS
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] Zola III:
I think I sent you a results for AMD Ryzen on Linux including

Schedutil governor which by the way is last effort to optimise CPU governing policies to the scheduling one's & as you culd see results are pretty much same to FCQ, overlay it saved 1% power. The article you mentioned whose interesting read almost an year ago and nothing more than that. What people somehow fail to get how it is not neither one way street nor with only one engine on the track. Different core's & different core architecture will behave differently in given workload and accounted to that different workloads will scale different on MP. Trough is 90% tasks today will use symmetric (synchronous) MP on two core's & on a same cluster so it's preferred that you have them idling as the second one will be waked up & employed anyway. Usually scheduling is done on paired two core's that in the ARM's case will have shared L2 RAM which particularly isn't very beneficial as access & access times are shared also. More than that will be used very rarely under 6% & on the smartphone probably under 2% as other MP methods aren't very suitable for most things & more than MP2 never really lived up (all browser engines use only MP2 [Mozilla Servo will be a first one capable utilising more] & that really makes for 90% usage on mobile platforms). The A72 is a rage of fury compared to A53 when it comes to integer performance (app init, system boot and cetera) while it's advantages fall down in case of floating point vector instructions (mostly multimedia related but not exclusively) to mere a 40% advantage on the VFP unit while A72 will still have 3~4 times bigger power consumption & in NEON SIMD case are mostly the same between A72 & A53 while A72 VFP almost matches NEON performance while actual execution is by far faster on VFP as NEON register IO is still rather bad & slow. This particularly makes use of NEON with A72 as an outdated & not really wanted scenario. On the other hand integer based operations won't scale very good with more cores, typically only about 30% while flouting point ones will scale considerably better which brings us to conclusion how is much better idea to execute them on A53 cores no matter are their VFP or NEON one's. In the end I will just mention once more how we really can't influence how workloads are scheduled & to which cores so simplest solution is the best one having two cores idling all time on every cluster.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] mat9v:
What I have linked is not a script but whole Nijel8's kernel with modified settings.

And SuperSU MUST be flashed after LAST kernel flash as it modifies ramdisk.

If you do it the way you posted you won't be able to boot the system because my kernel will overwrite SuperSU settings in ramdisk.

RR is not built on LAOS but AOSP, that is why they are incompatible. - in the RR thread it is plainly stated "Based On Latest Google Android 7.1.1 release" not based on latest LineageOS release.

Kernel Adiutor does not provide core control or busy up and down settings for small cores, does not correctly set values for gpu on Harfix. Other then that, most options are present.

Most importantly interactive governor is fully configurable, although it is a lot of writing to enter all my settings there.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] Zola III:
In detail test results and conclusions with comments & results:

ARM/Intel MP-Dhrystone 2 Benchmark V1.2 28-Feb-2017 19.08

Compiled for 64 bit ARM v8a

Using 1, 2, 4 and 8 Threads

Threads 1 2 4 8

Seconds 0.70 1.07 3.10 7.23

Dhrystones per Second 11478083 14916518 10308284 8857787

VAX MIPS rating 6533 8490 5867 5041

Internal pass count correct all threads

Total Elapsed Time 13.0 seconds

System Information

Device Xiaomi MI MAX

Screen pixels w x h 1080 x 1920

Android Build Version 6.0.1

Processor	: AArch64 Processor rev 0 (aarch64)

processor	: 0

processor	: 1

processor	: 2

processor	: 3

processor	: 4

processor	: 5

Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32

CPU implementer	: 0x41

CPU architecture: 8

CPU variant	: 0x0

CPU part	: 0xd08

CPU revision	: 0

Hardware	: Qualcomm Technologies, Inc MSM8956

Linux version 3.10.84-perf-gfe86e7b (root@sq-offline-15436) (gcc version 4.9.x-google 20140827 (prerelease) (GCC) ) #1 SMP PREEMPT Fri Jan 6 19:57:00 CST 2017

* Note S650 MiUI 8.2.1

* The cortex A72 is significantly faster hire a 80% than A53 which brings us to 225% performance at the full speed. This also means that one A72 is faster than 2x A53 on full speed for some 32%. Things get more interesting when you look at the dual A72 result as it scales pretty bad there with only 30% performance gain (probably because the two share the same L2 cache & access times grow this way) still situation is present & on native quad A53 cluster SoC when all A53's are employed (the same thing). This time around single A72 [MENTION=4149147]1.8[/MENTION]Ghz is 3% faster than quad A53 @ 1.44GHz.

* ARM/Intel MP-Whetstone Benchmark V1.2 28-Feb-2017 19.33

Compiled for 64 bit ARM v8a

Using 1, 2, 4 and 8 Threads

MWIPS MFLOPS MFLOPS MFLOPS Cos Exp Fixpt If Equal

1 2 3 MOPS MOPS MOPS MOPS MOPS

1T 2519.3 485.4 411.1 448.6 89.1 29.6643289.5 1993.3 1183.0

2T 5095.4 991.9 932.4 902.8 177.1 59.21053197.7 4109.6 2370.3

4T 9106.8 1820.4 1718.7 1622.4 313.8 106.02090874.1 8725.5 5092.3

8T 12874.4 2950.7 2720.7 2297.1 396.0 153.03199558.1 13847.0 8354.6

Overall Seconds 4.97 1T, 4.92 2T, 5.89 4T, 8.18 8T

All calculations produced consistent numeric results

Total Elapsed Time 28.8 seconds

System Information

Device Xiaomi MI MAX

Screen pixels w x h 1080 x 1920

Android Build Version 6.0.1

Processor	: AArch64 Processor rev 0 (aarch64)

processor	: 0

processor	: 1

processor	: 2

processor	: 3

processor	: 4

processor	: 5

Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32

CPU implementer	: 0x41

CPU architecture: 8

CPU variant	: 0x0

CPU part	: 0xd08

CPU revision	: 0

Hardware	: Qualcomm Technologies, Inc MSM8956

Linux version 3.10.84-perf-gfe86e7b (root@sq-offline-15436) (gcc version 4.9.x-google 20140827 (prerelease) (GCC) ) #1 SMP PREEMPT Fri Jan 6 19:57:00 CST 2017

* Note: seams that the A72 is just 12% faster than A53 per megahertz which only brings us to 39~40% difference on the maximum core frequencies.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] mat9v:
You know, I may understand the numbers, but I would like to know what is your conclusion from them. :)
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] nijel8:
There is nothing to fix. Virtual mouse driver is removed from kernel long time ago, you are the only one having this issue as far as I know(and I know...).

Your issue is not rom related...
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] Zola III:
The default mechanism is actually good prone the app start (integer load) to the big cluster & then bounce it back to the small cluster for most future usage as scrolling, vector graphic, music playback, image decoding and cetera (all related to VFP & NEON instructions). As most jump starts are very short you only lose having only one big core idling as it waits the other one to jump in & share load & not on idling frequently either as the first core's frequency is tied & replicated to the all others on the cluster (per cluster CPU frequency & not per CPU as only Kraits & new R series have it per CPU) end result is slower performance & bigger power consumption simply as task takes longer (& with out real neither load nor frequency balancing). In theory this shouldnt be a case but as their is much jumps on the big cluster practice shows otherwise how it's better having a pair idling then a single one (according to your tests and findings).

The other & only certain thing is that you don't need more than two core's idle per cluster.

Edit:

It also partially explains why Qualcomm had it done this way (at least regarding big cluster) on its property MP decision hotplug blobs.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] grey77:
That's truly awesome. ;)

A question u might know the solution for. I used to run bash scripts setting CPU hotplug and CPU governor tunables. In order to do it the correct way one might stop some governor/hotplug daemons, disable thermal and other features, set minimum of online CPU cores to max, etc like in this Xiaomi mi4 code snippet:

perfd_running=$(getprop "init.svc.perfd")
if [ "$perfd_running" = "running" ]; then
# Stop perfd while tuning params
logi "Stopping perfd"
stop perfd
fi

# Make sure core_ctl does not hotplug big cluster
echo "2" > /sys/devices/system/cpu/cpu4/core_ctl/max_cpus
echo "2" > /sys/devices/system/cpu/cpu4/core_ctl/min_cpus

# Disable thermal and bcl hotplug to switch governor
echo 0 > /sys/module/msm_thermal/core_control/enabled
for mode in /sys/devices/soc.0/qcom,bcl.*/mode
do
echo -n disable > $mode
done
for hotplug_mask in /sys/devices/soc.0/qcom,bcl.*/hotplug_mask
do
bcl_hotplug_mask=`cat $hotplug_mask`
echo 0 > $hotplug_mask
done
for hotplug_soc_mask in /sys/devices/soc.0/qcom,bcl.*/hotplug_soc_mask
do
bcl_soc_hotplug_mask=`cat $hotplug_soc_mask`
echo 0 > $hotplug_soc_mask
done
for mode in /sys/devices/soc.0/qcom,bcl.*/mode
do
echo -n enable > $mode
done

# Make sure CPU4 is online for config
echo "1" > /sys/devices/system/cpu/cpu4/online

What is the correct way of initialization in order to change CPU governor/CPU hotplug params on the fly for MI Max? I had issues when some settings were not set, reset or set to random! values.

---------- Post added at 06:19 AM ---------- Previous post was at 05:51 AM ----------

In ur config u set 1382Mhz for cpu0 but touchboost (wake_boost, etc) wont have any effect if cpu0 is offline at the moment the event happened. Tested on Harfix4 2.1/nijel8 kernels. In order to have it set for any little CPU the value should be "0:1382400 1:1382400 2:1382400 3:1382400 4:0 5:0 6:0 7:0"
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] Tysovwik:
Any idea how to fix it? Could it be cos of flashing different firmware? Now I am at 7.2.16

I coming to your rom from miui dev build 7.2.16, clean flash 21 Feb build of your ROM through your twrp and then dirty flashed 11 March version (system wipe only). So I coming to ROM since build, which already have deleted mouse driver... But it appears again and again.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] mat9v:
I can't do it that way as it would bring all online small cores to 1.3Ghz and I don't want that. It works well on nijel8 kernel because of "write /sys/devices/system/cpu/cpu0/core_ctl/not_preferred "1 0 0 0"" but I have no way to force it under Harfix. Maybe Rafcio will implement nijel8 change and it will work there as well. But it seems that CPU0 even under Harfix is mostly online. I would have to monitor it closely (maybe use nijel8 script to do that).
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] Tysovwik:
as i remember, njgel make setup not_preferred "1 0" for cpu 4 core.

Does it have any difference for hydrogen, not_preferred "1 0" vs "1 0 0 0" for cpu4 ?

btw, i use your setup at RR 5.8.2 with harfix RC 2.1 as init'd script by init.d scripts support application from google market.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] nijel8:
Look in init.qcom.power.rc how interactive is set at boot.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] mat9v:
not_preferred is set for Helium for small cores in

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

and for big cores

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

The meaning of "1 0 0 0" is: don't let hotplug affect core 0 but let hotplug control (and allow it to be turned off) cores 1, 2 and 3. The same for big cores. It means that core 0 and core 4 will always be turned on.

In case of Helium we get 4 big cores hence again "1 0 0 0" but for hydrogen we have only 2 cores so "1 0"

About not applying - you did change HOW the values are applied, right? I provided those lines with, I hope, clear info that they need to be changed to work in any script. The way they are provided they will work only in ramdisk in kernel during system boot. To repeat:

this value

must change into

to work in any script, the same must happen to any other value you are trying to change.

One more thing, those values are only changeable by ROOT user so unless this application has root privileges it won't be able to change the settings.

I have not tried but LAOS does have working "init.d" implementation, at least there is "/etc/init.d" folder with 2 scripts inside.

You could try to create script named "99mysettings" and enter into it the changed commands.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] Tysovwik:
yes, i made a little mistake in script, for target loads and input boost string, right now every setting applying well by unit'd :)

I thinking your setting get's the job with RR rom + harfix kernel, need time to test ;)