Here's my release of a slightly modified kernel for Zuk Z2 Pro. It's all somewhat basic, but still, maybe someone is interested.
void3.5(oc): Old AEX4.5 Android 7.1 Nougat
void5.1bat is only for AEX 5.3.
void5(oc/ocx) for AEX 5.4 <= 0411
void5ocx-mracar: Special version for Cosmicos and RR before full treble (before April 18)
For AEX 5.4-0418 and similar full-treble vendor-partition-enabled ROMs (RR working!) use void5.4.
max GPU frequency raised from 624Mhz to 653MHz (710 for ocx-Edition)
Actually I wouldn't consider this as an overclock because 653Mhz is default for Snapdragon 821, which also has Adreno 530 GPU. Yields around +2-3k in Antutu 3D score, if you're not hitting temp throttling. For that, I've included a modified thermal-engine.conf, which simply makes sense because the default limits are ridiculously low imo. There is no danger involved anyway because there are additional kernel/hardware mechanisms in place to prevent serious overheating. In fact, thermal-engine.conf can be empty (like on RR), but I'd say it's a good idea to keep it in place and prevent the phone from getting uncomfortably hot to touch. It does get warm now though!
Westwood+ TCP congestion algorithm (default)
Supposedly superior for moblie devices, but well, who knows. This had to be benchmarked and profiled in great detail, which is a difficult thing to do. I've made it default anyway, mainly because it seems to be popular and I cannot notice any negatives so far.
Zen I/O scheduler (from dorimanx OP3T kernel)
As above, hard to quantify. But I don't like CFS/BFQ for mobile devices and am in fact leaning towards Deadline, which is also included. Kernel defaults to ZEN nevertheless, but note that this is probably overwritten by the ROM's custom startup scripts. Check with kernel tools like "Kernel Adiutor" and change to Zen if you want to give it a try.
(But beware of Kernel Adiutor - it doesn't quit cleanly and hogs cpu, at least sometimes. Check with some task manager app like "System Panel" and kill it!)
F2FS enabled (untested!)
People seem to be keen on F2FS, so I thought, why not include it. Note that AEX builds from 0825 onwards also have this by default. Untested, because I don't have any F2FS partitions. Might try it in the future though - certainly makes sense.
Cleanup kernel config / Optimize build options
Remove unecessary kernel config options, optimize build, silence debug syslog output.
Ignore specific min CPU frequency request from userspace
Well, yes, totally stupid. But I couldn't find any other way to "disable" AOSP CPU-boost on touchscreen interaction (or whatever it is called). I don't like this feature - we have input boost in the kernel for that. Trying to control CPU freqs from userspace is just no good idea imo.
(Actually... I'd suggest disabling kernel's input boost also. CPUs are fast, even the small cores, and there shouldn't be any noticable lag. And if so, tune/optimize scheduler and/or governor instead.)
This change certainly helps with battery life, but how much exactly... I don't know.
Voltage Control (from optimumpr)
Added voltage control through sysfs interface (/sys/devices/system/cpu/cpuX/cpufreq/UV_mV_table). Use for example Kernel Adiutor to tweak, but beware, undervolting _together_ with overclocking does not play well on this device.
Overclock-Xtreme-Edition (ocx)
CPU is raised to 1.80/2.32 GHz and GPU to 710 MHz (!). Bus speeds are also slightly increased and performance should be a bit better than what the small increase in pure CPU-speed might suggest.
Note that the ocx-kernel is really borderline and certainly depending on the specific phone. If it doesn't boot, blue-led-of-death, and/or random apps are crashing, just use the normal oc-edition. The difference is not that big and battery life of ocx is somewhat worse. This is just for fun!
Underclocked aka battery-optimized edition (bat)
CPU underclocked to 1.4/1.92 per default, GPU 510Mhz. Underclocks can be disabled on runtime, enabling 1.67/2.23 CPU and 653 MHz GPU, which is still oc'd compared to stock, but lower than ocx. To disable underclock:
Big thanks to all involved kernel devs and especially davidevinavil for maintaining Z2 Pro for AEX. :good:
UPDATE 20180418 - void5.4bat - void5.4ocx - AEX/RR full treble with vendor partition
UPDATE 20180402 - void5.1bat Underclocked - AEX 5.3 only!
UPDATE 20180324 - void5oc - void5ocx
UPDATE 20170916 - void3.5 - void3.5oc - For AEX 4.5
3.3 adds a more extensive "tuning"-script, located in /system/etc/void_tuning.sh. This is executed after boot and activates the default profile qpwr. Here's a list of the available profiles with a short description:
qpwr: Goal is congesting tasks on the silver cores, kicking in the bigger cluster only when more capacity is needed. All this with focus on prolonged battery life. (default)
qperf: Somewhat similar to qpwr, but with focus on performance. Freqs ramp up faster and schedulers generally act more "quickly". You can use this for benchmarks, should give the best results, but in real life usage I think the benefits are really non-existent.
qmix: No, this is _not_ intended to strike a balance between pwr/perf. Instead, the idea is to distribute the load evenly across all cores, effectively keeping freqs on a lower level on average. I'm not sure yet how this turns out with regards to battery life, but on SD820/821 it might be a valid strategy. You know, power requirements for the golden and silver cores are about equal for any given freq and both are (nearly) equally efficient. A point against this strategy might be, at least in theory, that esp. the golden cores are more frequently prevented to enter deep sleep states, even during light usage. But well, I'm not sure how big the impact on battery life really is and whether the non-linear power characteristic of these cores make up for it. I am running/testing qmix myself right now...
My suggestion as of now is to run the script manually. There might be some apps helping with that. /system/etc/void_tuning.sh. Just execute it.
BACKUP YOUR DEVICE BEFORE FLASHING THIS PACKAGE! (use latest TWRP for Oreo ROMs!)
I CANNOT GURANTEE IT WILL WORK UNDER ALL CIRCUMSTANCES, ESPECIALLY WITH PREVIOUSLY MODIFIED BOOTPARTITIONS / RAMDISKS / WHATEVER !!!
Kernel source: https://github.com/virtvoid/android_kernel_zuk_msm8996-1
Kernel source: https://github.com/virtvoid/android_kernel_zuk_msm8996-5
---
Other things worth mentioning:
o void5.4ocx Antutu 7.0.6 score on an idle AEX5.4-1704 system is expected to be around 172k, +- 2k. If not, then there's something hogging cpu. Try a reboot, let it settle down and/or check with some task manager app if you still cannot reach these scores.
void3.5(oc): Old AEX4.5 Android 7.1 Nougat
void5.1bat is only for AEX 5.3.
void5(oc/ocx) for AEX 5.4 <= 0411
void5ocx-mracar: Special version for Cosmicos and RR before full treble (before April 18)
For AEX 5.4-0418 and similar full-treble vendor-partition-enabled ROMs (RR working!) use void5.4.
max GPU frequency raised from 624Mhz to 653MHz (710 for ocx-Edition)
Actually I wouldn't consider this as an overclock because 653Mhz is default for Snapdragon 821, which also has Adreno 530 GPU. Yields around +2-3k in Antutu 3D score, if you're not hitting temp throttling. For that, I've included a modified thermal-engine.conf, which simply makes sense because the default limits are ridiculously low imo. There is no danger involved anyway because there are additional kernel/hardware mechanisms in place to prevent serious overheating. In fact, thermal-engine.conf can be empty (like on RR), but I'd say it's a good idea to keep it in place and prevent the phone from getting uncomfortably hot to touch. It does get warm now though!
Westwood+ TCP congestion algorithm (default)
Supposedly superior for moblie devices, but well, who knows. This had to be benchmarked and profiled in great detail, which is a difficult thing to do. I've made it default anyway, mainly because it seems to be popular and I cannot notice any negatives so far.
Zen I/O scheduler (from dorimanx OP3T kernel)
As above, hard to quantify. But I don't like CFS/BFQ for mobile devices and am in fact leaning towards Deadline, which is also included. Kernel defaults to ZEN nevertheless, but note that this is probably overwritten by the ROM's custom startup scripts. Check with kernel tools like "Kernel Adiutor" and change to Zen if you want to give it a try.
(But beware of Kernel Adiutor - it doesn't quit cleanly and hogs cpu, at least sometimes. Check with some task manager app like "System Panel" and kill it!)
F2FS enabled (untested!)
People seem to be keen on F2FS, so I thought, why not include it. Note that AEX builds from 0825 onwards also have this by default. Untested, because I don't have any F2FS partitions. Might try it in the future though - certainly makes sense.
Cleanup kernel config / Optimize build options
Remove unecessary kernel config options, optimize build, silence debug syslog output.
Ignore specific min CPU frequency request from userspace
Well, yes, totally stupid. But I couldn't find any other way to "disable" AOSP CPU-boost on touchscreen interaction (or whatever it is called). I don't like this feature - we have input boost in the kernel for that. Trying to control CPU freqs from userspace is just no good idea imo.
(Actually... I'd suggest disabling kernel's input boost also. CPUs are fast, even the small cores, and there shouldn't be any noticable lag. And if so, tune/optimize scheduler and/or governor instead.)
This change certainly helps with battery life, but how much exactly... I don't know.
Voltage Control (from optimumpr)
Added voltage control through sysfs interface (/sys/devices/system/cpu/cpuX/cpufreq/UV_mV_table). Use for example Kernel Adiutor to tweak, but beware, undervolting _together_ with overclocking does not play well on this device.
Overclock-Xtreme-Edition (ocx)
CPU is raised to 1.80/2.32 GHz and GPU to 710 MHz (!). Bus speeds are also slightly increased and performance should be a bit better than what the small increase in pure CPU-speed might suggest.
Note that the ocx-kernel is really borderline and certainly depending on the specific phone. If it doesn't boot, blue-led-of-death, and/or random apps are crashing, just use the normal oc-edition. The difference is not that big and battery life of ocx is somewhat worse. This is just for fun!
Underclocked aka battery-optimized edition (bat)
CPU underclocked to 1.4/1.92 per default, GPU 510Mhz. Underclocks can be disabled on runtime, enabling 1.67/2.23 CPU and 653 MHz GPU, which is still oc'd compared to stock, but lower than ocx. To disable underclock:
Code:
echo 0 > /sys/module/msm_performance/parameters/void_underfreqUPDATE 20180418 - void5.4bat - void5.4ocx - AEX/RR full treble with vendor partition
UPDATE 20180402 - void5.1bat Underclocked - AEX 5.3 only!
UPDATE 20180324 - void5oc - void5ocx
UPDATE 20170916 - void3.5 - void3.5oc - For AEX 4.5
3.3 adds a more extensive "tuning"-script, located in /system/etc/void_tuning.sh. This is executed after boot and activates the default profile qpwr. Here's a list of the available profiles with a short description:
qpwr: Goal is congesting tasks on the silver cores, kicking in the bigger cluster only when more capacity is needed. All this with focus on prolonged battery life. (default)
qperf: Somewhat similar to qpwr, but with focus on performance. Freqs ramp up faster and schedulers generally act more "quickly". You can use this for benchmarks, should give the best results, but in real life usage I think the benefits are really non-existent.
qmix: No, this is _not_ intended to strike a balance between pwr/perf. Instead, the idea is to distribute the load evenly across all cores, effectively keeping freqs on a lower level on average. I'm not sure yet how this turns out with regards to battery life, but on SD820/821 it might be a valid strategy. You know, power requirements for the golden and silver cores are about equal for any given freq and both are (nearly) equally efficient. A point against this strategy might be, at least in theory, that esp. the golden cores are more frequently prevented to enter deep sleep states, even during light usage. But well, I'm not sure how big the impact on battery life really is and whether the non-linear power characteristic of these cores make up for it. I am running/testing qmix myself right now...
My suggestion as of now is to run the script manually. There might be some apps helping with that. /system/etc/void_tuning.sh. Just execute it.
BACKUP YOUR DEVICE BEFORE FLASHING THIS PACKAGE! (use latest TWRP for Oreo ROMs!)
I CANNOT GURANTEE IT WILL WORK UNDER ALL CIRCUMSTANCES, ESPECIALLY WITH PREVIOUSLY MODIFIED BOOTPARTITIONS / RAMDISKS / WHATEVER !!!
Kernel source: https://github.com/virtvoid/android_kernel_zuk_msm8996-1
Kernel source: https://github.com/virtvoid/android_kernel_zuk_msm8996-5
---
Other things worth mentioning:
o void5.4ocx Antutu 7.0.6 score on an idle AEX5.4-1704 system is expected to be around 172k, +- 2k. If not, then there's something hogging cpu. Try a reboot, let it settle down and/or check with some task manager app if you still cannot reach these scores.
Last edited:
