[KERNEL][NO FURTHER DEVELOPMENT][14th Jan] HelixKernel v018-Reuploaded FINAL

Status
Not open for further replies.
Search This thread

ZeroInfinity

Recognized Developer
Dec 17, 2011
7,025
74,009
Brighton & Hove
ANNOUNCEMENT 14/01/18 PLEASE READ!


This kernel is based on 100% latest HTC official source. EAS was ported from scratch using @RenderBroken 's commits (with permission from him).



THIS KERNEL IS BATTERY ORIENTED! DO NOT EXPECT AMAZING PERFORMANCE FROM THIS KERNEL! PERFORMANCE IS DECENT ENOUGH FOR NORMAL USAGE! If you are here to try out performance then this is not the kernel for you. Do not go complaining about performance unless it is extremely bad.



Features:
-Compiled using Linaro GCC 6.4.1 Toolchain
-Energy Aware Scheduling r1.3
-HELIX-ENGINE: A pnpmgr replacement compatible with EAS
-Working thermal-engine for Sense without the need of pnpmgr (binary from LOS)
-Much more efficient special CPUSET set-up (big cluster as main rather than little)
-NEW governor: pwrutilx - another governor based on schedutil
-Button Light Notification mod
-LED Pulse/gradient charging mod
-Fast charging
-Backlight dimmer
-Double tap fingerprint 2 sleep
-Maple and BFQ I/O
-Adreno GPU boost
-KCAL Colour control
-Sound Control
-Misc fixes and patches
-Using exFAT driver ported from @dorimanx 's OP3T kernel (since nofuse driver was giving issues and stock HTC texfat was not compatible with EAS kernels)
-F2FS support


pwrutilx - a new EAS governor based on schedutil that aims to be much more efficient by using a different formula to get next frequency.


HELIX-ENGINE v5.0
- SELinux set to PERMISSIVE is MANDATORY to get app engine working!! This is due to using a function called "pipe open" in C which is able to collect the output of terminal commands used, SELinux always blocks this when set to enforcing.


App Engine: dynamically adjusts schedtune.boost and governor tunables in a per-app basis.
- Battery profile sets schedtune.boost to -100, 1000 up_rate_limit and down_rate_limit, 0 iowait_boost.
- Performance sets schedtune.boost to 10, 500 up_rate_limit and 20000 down_rate_limit, 1 iowait_boost.
- Default (apps that are not included in either lists above) sets schedtune.boost 1, 500 up_rate_limit and 20000 down_rate_limit, 0 iowait_boost.

- App package names are added to battery.conf and performance.conf (/system/etc/helix_engine), the engine will check them to see if the top-app (current app) matches with the names scanned through those lists. If a match is found, it will apply one of the profiles above according to what list the package name is in.

Suspend Engine: when display is turned off, it will use battery profile settings until screen-on.

Helix Engine is closed source currently since it is my own work, writting in C completely from scratch. However, devs are free to integrate Helix Engine to their ROMs/Kernels/whatever as they see fit as long as they give me credits.

Read post 2 regarding dev information about Helix Engine.



This kernel is compatible with Sense and AOSP ROMs (Nougat and Oreo supported). This kernel is NOT compatible with Sense-based Oreo ROMs!

Please ensure that you have made a backup of your boot, system, and data partitions in case anything goes wrong.




If you update Magisk with this kernel installed, you MUST reflash the kernel. Everytime Magisk gets updated, it will restore the stock init.rc ramdisk file and re-append magisk lines to it, rather than just re-append magisk lines without restorting stock init.rc ramdisk. If you do not reflash the kernel after this, then init.helix.rc will not execute on boot since init.rc has been replaced by stock again due to Magisk update. Which means EAS will not be set up correctly (if you're on sense) and Helix Engine will NOT work.

Bugs:
- custom cpuset config gets overwritten by Oreo ports, you MUST follow this guide to get slightly better battery life, battery life on Oreo is still bad but that is mainly a ROM/port issue.
- msm_thermal may be enabled by default for some (Sense ROMs mainly), DISABLE THIS SETTING IMMEDIATELY AND KEEP IT DISABLED ON BOOT! It can result to bad battery life as this function will prevent both clusters from going below 700MHz.
- exFAT is still a hit or miss, it will work for some people and won't for others. There isn't much I can do about it I'm afraid unless someone has a better solution...
- USB Tethering and WiFi Portable Hotspot are NOT WORKING FOR AOSP ROMS! This should be fixed in the next update (no ETA).



Posts #3 and #4 are very irrelevant now, you can ignore these 2 posts.






Credits:
@RenderBroken - who helped me a lot and taught me more about using git version control
@joshuous - another OP3 developer who helped me with EAS and discussing ideas about it
@Kyuubi10 - tester + coming up with the idea for a new algorithm for helix_schedutil
@p50kombi - Tester + making Magisk-compatible zips
@Mostafa Wael - introduced me to great devs, discussing and researching more about EAS, coming up with the idea of dynamic schedtune.boost
@DeeZZ_NuuZZ @CharliesTheMan - Testers
@Captain_Throwback - helping me a lot with exFAT and his exFAT no-fuse patch to make it work on the 10
@dorimanx - ExFAT driver in his OP3T kernel
@ivicask for making a template of AROMA installer for me to work with for the kernel, inspiration to make my own engine!
@TotallyAnxious - tester + helping me with a few issues + Advanced EAS Tweak scripts
@RogerF81 - tester + Advanced EAS Tweak scripts
@flar2 - backlight dimmer, Adreno boost, Sound Control
@tbalden - double tap fingerprint 2 sleep, BLN, LED pulse/gradient mod, fastcharge, kcal port, AOSP LED light fix
@franciscofranco - misc commits such as WiFi wakelocks and power efficient workqueues, display_on() API
Eliminater74 - ASoC 4.4 backport commits, remove traces of pnpmgr commits, Maple and BFQ I/O commits
PFOS Team - Commits needed for Oreo support

If I have missed anyone, please contact me via PM and I will add you to the list.
 
Last edited:

ZeroInfinity

Recognized Developer
Dec 17, 2011
7,025
74,009
Brighton & Hove
Changelog:
Code:
v018:
Helix Kernel v018:
- Rebased kernel from EAS r1.3 (thanks to @RenderBroken)
- AOSP (both Nougat and Oreo) Support (thanks to @tbalden for LED fix on AOSP and PFOS team for commits that Oreo needs to boot)
- Added thermal-engine binary from LOS to make thermal-engine work on Sense ROMs without needing pnpmgr (Proper thermal throttling on EAS + Sense now)
- Custom thermal-engine.conf for optimal thermal throttling
- Updated Magisk modules to use the latest template for v14

Helix Engine v5.0:
- Re-written engine from scratch
- Slimmed down to App Engine and Suspend Engine
- Dynamically adjusts schedtune.boost for top-app cpuset
- Dynamically adjusts gov tunables on schedutil and schedutil-based govs
- Removed capping of CPU freqs
- Removed powersaver engine and thermal engine
- Removed ability for user configs
- Removed helix_config
- Less user customizability (Will consider adding this back in the future)
- Much more efficient in battery savings with very minimal performance hit.
- Much easier for devs to port Helix Engine to ANY DEVICE with EAS Kernels (literally just requires Helix Engine ROM files, no need for kernel integration).

v017:
- Completely redone the kernel from scratch using latest EAS commits from @RenderBroken
- [HELIX-ENGINE]: Remove dynamic throttlemode
- [HELIX-ENGINE]: Add support for user defined frequencies in powersaver and suspend engines
- [HELIX-ENGINE]: Users can now change freqs of app engine profiles
- [HELIX-ENGINE]: Separate sysfs nodes for frequencies
- Revert "[PATCH] proc: Remove verifiedbootstate flag from /proc/cmdline"
- SafetyNet bypass: Show androidboot.verifiedbootstate=green
- cpufreq/pwrutilx: Lower kthread priority to 25% and fix log info

Helix Engine v4.0:
- Significant code optimizations
- Tons of bug fixes
- Thermal engine values tweaked slightly (balanced is slightly less aggressive than before)
- Add support for user-defined frequencies for all app engine profiles (battery, balanced, performance)
- Introducing helix_config: An executable binary which allows much easier user configuration for Helix Engine!

v016:
- [HELIX-ENGINE]: Separate enable nodes for all parts of engine (Fixes bug when disabling parts of the engine)
- Fixed magisk module for ROM support, it should get rid of any weird bugs with Magisk now

Helix Engine v3.0:
- A f*ck ton of code optimisations to use less CPU time (much more battery friendly and less cpu intensive)
- Fixed app engine bug where thermal manager would still fight app engine under certain cases
- Slightly tweaked thermals for all thermal modes
- User lists are now moved to /system/etc/helix_engine/user
- More package names added to default lists
- Fixed other minor bugs

v015:
* f4837d639b3 - [HELIX-ENGINE]: Add support to enable/disable dynamic throttlemode <ZeroInfinity>
* b4e186792e9 - DEFCONFIG: Added more exFAT related lines <ZeroInfinity>
* 89f562db4d0 - [HELIX-ENGINE]: Change implementation of user-defined app engine lists <ZeroInfinity>
* 21e91a04d2c - [HELIX-ENGINE]: Add sysfs node for user app list <ZeroInfinity>
* 8dd27f4a06b - [HELIX-ENGINE]: Added "mode" sysfs node <ZeroInfinity>
* 59c2824f7f0 - [HELIX-ENGINE] Restore powersaver sysfs node from pnpmgr <ZeroInfinity>

Helix Engine v2.0:
- Added thermal throttling modes
- Added user defined custom lists for app engine thanks to @ChronoReverse for the idea
- Added powersaver mode (links to powersaver or extreme powersaver in settings)
- Set stune to 10 top app as default for everything (to ensure smooth ui) (previously 5)
- App engine can now change adrenoboost
- Code optimisations
- More apps added to app engine lists as per user requests
- Throttle mode changes with app engine thanks to @p50kombi for the idea
- Added Dynamic Throttlemode tunable which allows users to disable throttle mode changing with app engine
- Slightly more aggressive throttling for balanced to keep temps down due to stune set to 10 now
- Fixed Helix Engine on Magisk version (set correct perms in installer now)

v014:
* Added balanced and battery tweaks from Advanced EAS Tweaks (thanks to @RogerF81 @TotallyAnxious)
* Added ZeroInfinity's personal Advanced EAS Tweaks based on battery tweaks
* Added TotallyAnxious' personal Advanced EAS Tweaks
* Added Helix Engine executable binary and necessary files in /system/helix_engine
* 2a19eb9b8e0 - [HELIX-ENGINE]: Added new sysfs node "enginecap" (19 hours ago) <ZeroInfinity>
* 0203d822b4b - [HELIX-ENGINE]: Added more sysfs nodes (3 days ago) <ZeroInfinity>
* 96811d98170 - [HELIX-ENGINE]: Initial kernel integration (4 days ago) <ZeroInfinity>
* 0e51404a512 - exfat: ported driver from Dorimanx's OP3T kernel (9 days ago) <ZeroInfinity>
* 0963424716b - cpufreq_pwrutilx: Remove display_on() API (9 days ago) <ZeroInfinity>
* 8027127f24f - Revert "Add exfat no-fuse" (11 days ago) <ZeroInfinity>
* REBUILT KERNEL FROM STOCK HTC SOURCE AGAIN (much cleaner now)

v013:
* b42fad1 cpufreq_pwrutilx: Upgrade pwrutil to pwrutilx [ZeroInfinity]
* 3604dc3 schedtune: Use display_on API to prevent boosting when screen off [ZeroInfinity]
* 682b3e8 cpufreq_pwrutil: Force big cluster to use min freq during screen off regardless of load [ZeroInfinity]
* ed71a42 cpufreq_pwrutil: Remove utilboost [ZeroInfinity]
* 942e8ea cpufreq_pwrutil: disable utilboost, mincap, cap big cluster to minimum freq on suspend [ZeroInfinity]

v012:
* b166c29 cpufreq_pwrutil: Introduce Load Dependent Minimum Frequency Capping [ZeroInfinity]
* 674bf02 cpufreq_pwrutil: Separate utilboost calculation from get next freq formula [ZeroInfinity]
* 0935b73 sched: freq: Reevaluate throttle if frequency requested changes [Joel Fernandes]
* 8b49109 sched: rt: Fix broken sync wakeup logic [Joel Fernandes]
* c786268 sched: Add back capacity margin in sched_freq_tick_walt [Joel Fernandes]
* 892d614 sched: Use schedtune boosted WALT signal for RT [Joel Fernandes]
* 9ce77da sched: Move schedtune boost utilization calculations to tune.h [Joel Fernandes]
* 19ae3c3 Audio RT glitch fix [DO NOT MERGE]. [Srinath Sridharan]
* d2401ab cpufreq_sched: Fix capacity over accounting. [Srinath Sridharan]
* 93dc2b8 sched/rt: rt cpu selection integration with EAS. [Srinath Sridharan]
* 9ebf753 DEFCONFIG: Disable Capacity Clamping [ZeroInfinity]
* 7e47764 Revert "cpufreq: schedutil: ignore the sugov kthread for frequencies selections" [ZeroInfinity]
* f1518ff Revert "cpufreq: schedutil: ensure max frequency while running RT/DL tasks" [ZeroInfinity]
* e693634 Revert "cpufreq: schedutil: relax rate-limiting while running RT/DL tasks" [ZeroInfinity]
* 6a03559 Revert "cpufreq: schedutil: avoid utilisation update when not necessary" [ZeroInfinity]
* 858f726 Revert "sched/rt: fast switch to maximum frequency when RT tasks are scheduled" [ZeroInfinity]
* c84a2df Revert "cpufreq_pwrutil: Update governor with new schedutil patches" [ZeroInfinity]
* 361d5a1 Revert "DEFCONFIG: Enable CPU_BOOST" [ZeroInfinity]

v011:
* 7025fb4 cpufreq_pwrutil: Default utilboost to 0 [ZeroInfinity]
* 69b314e DEFCONFIG: Disable WALT [ZeroInfinity]
* f6a19de cpufreq_helix_schedutil: Deprecated [ZeroInfinity]
* 49e3761 DTS: MSM8996: EAS Energy Model Change [RenderBroken]
* a658e35 Revert "New Energy Model thanks to @Kyuubi10" [ZeroInfinity]
* 32369c7 DEFCONFIG: Enable CPU_BOOST [ZeroInfinity]
* ce0b5de cpufreq_pwrutil: Update governor with new schedutil patches [ZeroInfinity]
* 9e301d5 trace: add support for boot trace clock [Tim Murray]
* 23a169d cpufreq: cpu-boost: don't boost if input_boost_ms is <= 0 [Francisco Franco]
* 14f8d3b cpufreq: cpu-boost: export input_boost_enable to userspace [franciscofranco]
* 2d11abd cpufreq: cpu-boost: Remove migration sync boost [Junjie Wu]
* 88ffb0b cpufreq: cpu-boost: Use one work to remove input boost for all CPUs [Rohit Gupta]
* 82f33f3 cpufreq: cpu-boost: Support separate input_boost_freq for different CPUs [Junjie Wu]
* 81f59f4 cpufreq: cpu-boost: Make the code 64 bit compatible [Rohit Gupta]
* 7cae16c cpufreq: cpu-boost: Use interruptible wait to not affect load average [Swetha Chikkaboraiah]
* 982bd86 cpufreq: cpu-boost: Consider only task load to decide on sync frequency [Girish S Ghongdemath]
* 76eba85 cpufreq: cpu-boost: Handle wakeup hints received for foreground tasks [Rohit Gupta]
* aabbb34 cpufreq: cpu-boost: Introduce scheduler assisted load based syncs [Rohit Gupta]
* f539a99 cpufreq: cpu-boost: Re-issue boosts above minimum frequency [Patrick Cain]
* 55a52a2 cpufreq: cpu-boost: Don't register for cpufreq notifiers too early [Saravana Kannan]
* 02302fa cpufreq: cpu-boost: Fix deadlock in wake_up of sync threads [Saravana Kannan]
* d3f194b cpufreq: cpu-boost: Fix queue_delayed_work_on() race with hotplug [Saravana Kannan]
* d0e5c17 cpufreq: cpu-boost: Resolve deadlock when waking up sync thread [Srivatsa Vaddagiri]
* 263eefa cpufreq: Add Input Boost feature to the cpu-boost driver [Rohit Gupta]
* 5b49acd cpufreq: Add a sync limit to cpu-boost [Rohit Gupta]
* b9c1495 cpufreq: cpu-boost: Add cpu-boost driver [Saravana Kannan]
* 1b9a8ab sched/rt: fast switch to maximum frequency when RT tasks are scheduled [Patrick Bellasi]
* d82ee60 cpufreq: schedutil: avoid utilisation update when not necessary [Patrick Bellasi]
* 2b5a28f cpufreq: schedutil: relax rate-limiting while running RT/DL tasks [Patrick Bellasi]
* fecdcac cpufreq: schedutil: ensure max frequency while running RT/DL tasks [Patrick Bellasi]
* d2f4a56 cpufreq: schedutil: ignore the sugov kthread for frequencies selections [Patrick Bellasi]
* aabbb34 cpufreq: cpu-boost: Introduce scheduler assisted load based syncs [Rohit Gupta]
* f539a99 cpufreq: cpu-boost: Re-issue boosts above minimum frequency [Patrick Cain]
* 55a52a2 cpufreq: cpu-boost: Don't register for cpufreq notifiers too early [Saravana Kannan]
* 02302fa cpufreq: cpu-boost: Fix deadlock in wake_up of sync threads [Saravana Kannan]
* d3f194b cpufreq: cpu-boost: Fix queue_delayed_work_on() race with hotplug [Saravana Kannan]
* d0e5c17 cpufreq: cpu-boost: Resolve deadlock when waking up sync thread [Srivatsa Vaddagiri]
* 263eefa cpufreq: Add Input Boost feature to the cpu-boost driver [Rohit Gupta]
* 5b49acd cpufreq: Add a sync limit to cpu-boost [Rohit Gupta]
* b9c1495 cpufreq: cpu-boost: Add cpu-boost driver [Saravana Kannan]
* 1b9a8ab sched/rt: fast switch to maximum frequency when RT tasks are scheduled [Patrick Bellasi]
* d82ee60 cpufreq: schedutil: avoid utilisation update when not necessary [Patrick Bellasi]
* d82ee60 cpufreq: schedutil: avoid utilisation update when not necessary [Patrick Bellasi]
* 2b5a28f cpufreq: schedutil: relax rate-limiting while running RT/DL tasks [Patrick Bellasi]
* fecdcac cpufreq: schedutil: ensure max frequency while running RT/DL tasks [Patrick Bellasi]
* d2f4a56 cpufreq: schedutil: ignore the sugov kthread for frequencies selections [Patrick Bellasi]
* 62dec04 cpufreq_pwrutil: Increase max utilboost value and tweak defaults [ZeroInfinity]
* 3949f45 cpufreq_pwrutil: use boosted_cpu_util for PELT to match WALT [ZeroInfinity]
* 1d12c0a EXPERIMENTAL: sched/fair: Use energy_diff for tasks where appropriate [Chris Redpath]
* 7de0e7b EXPERIMENTAL: sched/fair: Reduce balance interval to 0 if we have a misfit task [Leo Yan]
* 275418c EXPERIMENTAL: events: add tracpoint for energy/performance variations [Patrick Bellasi]
* 6472522 EXPERIMENTAL: events: add tracepoint for energy_diff [Patrick Bellasi]
* 0017bf5 EXPERIMENTAL: sched/fair: add support to compute perf/energy variations [Patrick Bellasi]
* 5318ff4 EXPERIMENTAL: sched/fair: make find_new_capacity() to honour the task's boost [Patrick Bellasi]
* 4c702c2 EXPERIMENTAL: sched/fair: use energy_env as single argument [Patrick Bellasi]
* 61c81e7 EXPERIMENTAL: sched/fair: add ENERGY_FILTER sched_feature [Patrick Bellasi]
* 21f110d EXPERIMENTAL: FROMLIST: sched/fair: kick nohz idle balance for misfit task [Chris Redpath]
* dab6f52 sched/tune: don't use schedtune before it is ready [Chris Redpath]
* aaf19575 sched/fair: use SCHED_CAPACITY_SCALE for energy normalization [Patrick Bellasi]
* 367fed9 sched/{fair,tune}: use reciprocal_value to compute boost margin [Patrick Bellasi]
* 3ab0323 sched/tune: Initialize raw_spin_lock in boosted_groups [Srinath Sridharan]
* 857dbc9 sched/tune: report when SchedTune has not been initialized [Patrick Bellasi]
* 4d6437b sched/tune: fix sched_energy_diff tracepoint [Chris Redpath]
* eebdd9e sched/tune: increase group count to 5 [Chris Redpath]
* 6984736 cpufreq/schedutil: use boosted_cpu_util for PELT to match WALT [Chris Redpath]
* 33dac50 sched/fair: Fix sched_group_energy() to support per-cpu capacity states [Morten Rasmussen]
* eb79250 sched/fair: discount task contribution to find CPU with lowest utilization [Valentin Schneider]
* cbce47c sched/fair: ensure utilization signals are synchronized before use [Chris Redpath]
* 1545d32 sched/walt: Add CONFIG_USE_WALT to change default usage of WALT [Chris Redpath]

v010_r2:
* aa59577 cpufreq_pwrutil: Unify cluster-dependent governors into one [ZeroInfinity]
* Fixed thermal-manager script - fully working now!

v010_r1:
* 619427e Revert "drivers: wakeup: add options to disable timerfd, netlink and wlan wakelocks" [ZeroInfinity]
* 32f5e07 Revert "wakeup: add toggles for wlan wakelocks. They are all enabled by default, it's up to the user and I provide no support if Wi-Fi stops working normally without these locks enabled. This is for advanced users" [ZeroInfinity]
* 6008e6f Revert "drivers: wakeup: more thoroughly deactivation of wakelocks" [ZeroInfinity]
* 0826e7f Revert "drivers: wakeup: run the wakelock blockers during wakeup_source activation and every resume" [ZeroInfinity]
* c0b3105 Revert "drivers: wakeup: there's no much point in running the blockers during screen on" [ZeroInfinity]
* 852d5b8 Revert "drivers: wakeup: it's pointless to output the active wakeup sources during screen on, no need to go through the rcu locks and list iterations every now and then" [ZeroInfinity]
* e6d50c0 Revert "wakeup: fix compile error + adapt for more wakelocks to disable" [ZeroInfinity]
* f76e0ee Revert "drivers: wakeup: be more thorough with blocking wakelocks" [ZeroInfinity]

v010: 
* 0407f7e cpufreq_pwrutil: tweak little cluster for better performance [ZeroInfinity]
* 6fcb145 cpufreq_pwrutil: 5% util boost on big cluster [ZeroInfinity]
* d6ed778 cpufreq_helix_schedutil: Add support for max CPU frequency capping [ZeroInfinity]
* b0bce28 cpufreq_schedutil: Add support for max CPU frequency capping [ZeroInfinity]
* 575c3cf cpufreq_pwrutil: Support max frequency changes [ZeroInfinity]
* 28b1248 drivers: wakeup: be more thorough with blocking wakelocks [Francisco Franco]
* 2bfba87 cpufreq_pwrutil: Introduce new gov and deprecate energy-dcfc [ZeroInfinity]
* c0f6a99 cpufreq_energy_dcfc: Change frequency calculation according to cluster [ZeroInfinity]
* f381792 cpufreq_energy_dcfc: Use load2_cap * util / max [ZeroInfinity]
* 516320a wakeup: fix compile error + adapt for more wakelocks to disable [ZeroInfinity]
* 287e941 cpufreq_energy_dcfc: Optimize for schedtune v3 (capacity clamping) [ZeroInfinity]
* 45b6f3c drivers: wakeup: it's pointless to output the active wakeup sources during screen on, no need to go through the rcu locks and list iterations every now and then [Francisco Franco]
* b5f8609 drivers: wakeup: there's no much point in running the blockers during screen on [Francisco Franco]
* 8692581 drivers: wakeup: run the wakelock blockers during wakeup_source activation and every resume [Francisco Franco]
* e6ee126 drivers: wakeup: more thoroughly deactivation of wakelocks [Francisco Franco]
* Added capacity clamping (schedtune v3) ROM support (thanks to @RenderBroken and @joshuous)
* Added thermal-manager service script (thanks to @ivicask and @nkk71)
* Tuned capacity clamping to get a balance of performance and battery (although pulling down status bar may be laggy sometimes)

v009_r1:
* 91fbcb4 cpufreq_energy_dcfc: final tweaks, as balanced as it can be [ZeroInfinity]
* 1ab31e9 Do not allow texfat module to load [ZeroInfinity]
* 7a8bc55 cpufreq_energy_dcfc: Change some lines to make the governor work better [ZeroInfinity]

v009 (Had to revert some changes so went on a new branch to redo some commits):
* 0a2f8b2 cpufreq_energy_dcfc: Implement formula changing by @Kyuubi10 [ZeroInfinity]
* 6dabc23 cpufreq_helix_schedutil: Fix load calculation [ZeroInfinity]
* 4e35b65 cpufreq_energy_dcfc: Fix load calculation [ZeroInfinity]
* d81bcca DEFCONFIG: Enable capacity clamping [ZeroInfinity]
* f74b731 cpufreq_helix_schedutil: fix small mistake [ZeroInfinity]
* 2ca352d cpufreq_energy-dcfc: Energy-DCFC 2.0 [ZeroInfinity]
* 902730d cpufreq_helix_schedutil: Helix_schedutil 2.0 [ZeroInfinity]
* 78b2fc3 sched/{core,cpufreq_schedutil}: add capacity clamping for RT/DL tasks [Patrick Bellasi]
* 4de07b6 sched/{core,cpufreq_schedutil}: add capacity clamping for FAIR tasks [Patrick Bellasi]
* d5e84c1 sched/core: sync capacity_{min,max} between slow and fast paths [Patrick Bellasi]
* e61b7842 sched/core: track CPU's capacity_{min,max} [Patrick Bellasi]
* 04f9dc8 sched/core: add capacity constraints to CPU controller [Patrick Bellasi]
* 562cdd6 sched: cpufreq: add cpu to update_util_data [Steve Muckle]
* 2744d69 cpufreq: Add dvfs_possible_from_any_cpu policy flag [vireshk]
* fb2bec6 cpufreq: schedutil: reset sg_cpus's flags at IDLE enter [Patrick Bellasi]

v008:
* 55a7c81 UPSTREAM staging: ion: Fix error handling in ion_buffer_create [Rohit kumar]
* c293641 ANDROID: sched: fix duplicate sched_group_energy const specifiers [Greg Hackmann]
* 834e64c drivers: wakeup: add options to disable timerfd, netlink and wlan wakelocks [Francisco Franco]
* c8d5019 cpufreq_helix_schedutil: Introduce schedutil formula modifications [ZeroInfinity]
* 8574753 cpufreq_energy_dcfc: Optimize code [ZeroInfinity]

v007:
* ecee901 cpufreq_energy-dcfc: Add new governor [ZeroInfinity]
* 235a893 cpufreq_helix_schedutil: Get sg_cpu instead of using cpumask [ZeroInfinity]

v006:
* 3855be7 cpufreq_helix_schedutil: Update governor to latest schedutil patches [ZeroInfinity]
* 011a079 sched: fixup schedutil patches from EAS-Dev [DespairFactor]
* b1bfc11 sched: cpufreq: enable remote sched cpufreq callbacks [vireshk]
* f162008 sched: cpufreq: detect, process remote callbacks [vireshk]
* a2c41bd sched: cpufreq: remove smp_processor_id() in remote paths [vireshk]
* 954b1d4 sched: cpufreq: extend irq work to support fast switches [vireshk]
* b7f86ef cpufreq: Add dvfs_possible_from_any_cpu policy flag [vireshk]
* 9b7b012 sched: cpufreq: add cpu to update_util_data [Steve Muckle]
* d6ce220 cpufreq: schedutil: ignore the sugov kthread for frequencies selections [Patrick Bellasi]
* 68208fd cpufreq: schedutil: reset sg_cpus's flags at IDLE enter [Patrick Bellasi]
* 3cbf72a fixup: modify ef6728ad to use correct cpu_util signal [Chris Redpath]
* 745b95e cpufreq/schedutil: Fix schedutil's 'default governor' machinery [Chris Redpath]
* 8b29d59 sched/fair: remove task util from own cpu when placing waking task [Chris Redpath]
* f54c3cc trace:sched: Make util_avg in load_avg trace reflect PELT/WALT as used [Chris Redpath]
* 4717b37 Experimental!: sched/fair: Add eas (& cas) specific rq, sd and task stats [Dietmar Eggemann]

v005:
Add exfat no-fuse
mmc: move to a SCHED_FIFO thread
[PATCH] disable crc check
Enable F2FS support
Allow stock crypt and texfat modules to load (although texfat loading causes non-booting kernel so I was forced to rename this upon installing the kernel.)

v004 - Initial PUBLIC release

Integration with Helix Engine and how to use on any device with an EAS kernel
-----------------------------------------------------------------------------------------------------------------
If you are a developer, simply take the files in the system folder of my zip and place into your kernel/rom/whatever and make sure correct permissions are set rwxr-xr-x (chmod 755) for init.helix_engine.sh and helix_engine. The rest of the files should be rw-r--r-- (644).
If you are an advanced user, you can move the files in yourself and try it.

If you use Magisk then it will be even easier, inside the magisk folder of my kernel zip you should see a folder named "helix_engine", I have re-packaged ROM support files and split it with helix engine so now helix engine is its own module. Literally just flash helix_engine.zip in twrp or magisk and you should have helix engine working (assuming you are on an EAS kernel on your device).

YOU WILL ALSO NEED PROPER RAMDISK EDITS TO MAKE THIS RUN AUTOMATICALLY! Check in my kernel.zip, downloadedzip/kernel/kernel.zip/ramdisk/init.helix.rc, scroll all the way to the bottom and you can see the section which starts with "service helix_engine", copy that block of text into your ramdisk (could be any ramdisk file, if you have your custom kernel ramdisk then add it to the bottom of that file, if not then add to the bottom of init.rc). If you are an advanced user who knows how to unpack boot.img, edit ramdisk files, repack boot.img, then feel free to try. If not, ask a developer to add these lines for you.

FYI This will ONLY work on EAS kernels due to schedtune.boost and schedutil/schedutil-based governors. There is no customizability yet, everything is currently hardcoded into the binary. If you are not happy with the values currently set, you will have to wait until I have more free time to add back customizability features.

NOTE: Due to SELinux, we cannot have the binary run by itself as a service in the ramdisk. I could only get this to work by adding a helper script which executes the binary every cycle. However due to this, the rate of execution has a latency of around 3 seconds (you can test this by debugging and measuring how long it takes for a new set of logs appear).

If you want to debug, open command prompt/terminal:
On PC: adb logcat TEAM-HELIX:I *:S
On mobile: logcat TEAM-HELIX:I *:S

If you intend to release your kernel/rom/whatever with Helix Engine, by all means go ahead, but please be sure to add me in the credits! If you have any problems, feel free to PM me.

Do not even try to steal, logcat will show [TEAM-HELIX] when Helix Engine is running and it is hard coded into the binary as well, I can easily tell if you have stolen my work or not.
 
Last edited:

p50kombi

Senior Member
Dec 20, 2005
3,969
2,150
Samsung Galaxy Note 10+
Magisk version of HelixKernel PME EAS v012

AS OF V013 ALL VERSIONS ARE INTEGRATED INTO ONE SINGLE FLASHABLE ZIP, NO NEED TO FLASH SEPERATE FOR MAGISK SYSTEMLESS USERS

I will keep this post up for users of v012 for now.

MAGISK USERS USE INFORMATION AND DOWNLOADS BELOW

If you use magisk, you need to flash the following two files to keep your system untouched and systemless.

TO BE CLEAR, THESE FILES ARE MEANT TO BE USED ON A STOCK ROM
These files are meant to be used on stock rom, either with or without the magisk version of a rom from your favorite rom developper (Like Leedroid Magisk or Viper Magisk).
If you use a custom rom and or your system is not read only, there is no reason to use these files and it could cause conflicts with custom roms.
If you are running a custom rom and not a stock rom, please use the normal kernel file as per post #1 of this thread.

HelixKernel PME EAS Systemless V012
https://drive.google.com/open?id=0B9-84MJYFzJWMElyRGhvdTMyb2M
- The kernel only, system less so your system does not get tampered with.

HelixKernel PME EAS v012 ROM SUPPORT MODULE
https://drive.google.com/open?id=0B9-84MJYFzJWaUJtRC03Y3VpWVE
- The rom support module flashes the rom files as a magisk mod, so your rom uses them as a magisk module.

Without the rom support magisk mod, the kernel will not work optimal.

Flash both in twrp or the kernel in twrp and then the module in magisk manager, it's up to you, easiest is to flash both in twrp one after another.
The rom support file module should then show up in magisk manager, which means it works as should.

For more info on why to flash this version of the kernel, please check this post:
https://forum.xda-developers.com/showpost.php?p=71552602&postcount=252
 
Last edited:

Kyuubi10

Senior Member
Feb 21, 2014
726
542
To understand Helix_schedutil you must first understand the original schedutil algorithm.
Here it is:
next_freq = maxfreq + (maxfreq >> bitshift) * util/maxcapacity

Explanation:
The most obvious difference of this algorithm is that it moves away from the idea of scaling frequencies up or down which were used in previous generations of governors.
Instead the aim of the above algorithm is to calculate the most appropriate frequency for the TOTAL CPU load.
NOTE: This is TOTAL load on CPU, not just load for the current frequency step as Interactive used to calculate with.

Now, for you numberphiles like myself that like understanding algorithms... Let's break it down:

"util/maxcapacity = Load."
The above creates a percentage value in decimal format (80% = 0.8) which represents the TOTAL load on CPU.
the algorithm now reads the following way:
next_freq = maxfreq + (maxfreq >> bitshift) * load

"maxfreq + (maxfreq >> bitshift)"
Essentially the aim of the above is to ensure that next_freq is always a little higher than the exact value needed to cover the load.

Bitshift: (paraphrasing @ZeroInfinity) in programming the ">>" mathematical function allows for shifting the binary values towards the direction of the arrows by "N" times.
In this case it is towards the right.

The relationship between "N" and the calculation in the "()" is as follows:
Bitshift = 1 = maxfreq/2
Bitshift = 2 = maxfreq/4
Bitshift = 3 = maxfreq/8

If the "+()" didn't exist in the algorithm, the chosen frequency would be exactly enough to cover the load.
If load is 0.6, aka 60%, all you need is a frequency = 60% of max frequency.
This would be bad since it doesn't leave any capacity/bandwidth leftover for inevitable bumps in load, nor space for EAS itself to run. Thus inevitably creating lags.
To keep a bit of free bandwidth you add "(maxfreq >> bitshift)".

Finally the problem I encountered, if bitshift = 2, then the result of the algorithm is that any load above 0.8 will result in a next_freq HIGHER than maxfreq. - This is your tipping point. As any load higher than 80% will wake up a new CPU.

Which means you have still about 20% of the CPU's max capacity being unused. Such a CPU is only 80% efficient.

Therefore by increasing bitshift to 3, the algorithm reads:
"maxfreq+(maxfreq/8)*load = next_freq"
This way you can use 89% of capacity before reaching max frequency of the CPU.
With bitshift=4 it reads:
"maxfreq+(maxfreq/16)*load = next_freq"
This allows you to use up to 94% total CPU load before reaching max frequency.
While this is great for improving efficiency at the higher frequencies, it doesn't leave enough bandwidth when calculating lower frequencies, and creates lag when load spikes at lower frequencies.

Helix_schedutil - UPDATE 20/3/17 (v008):
After being inspired by the concept of @ZeroInfinity's new governor - Energy-DCFC, I decided to carry out a couple of tests on HTC 10 using variations of Helix_Schedutil.
The focus was stress-testing by increasing the current frequency load above 100%. (AKA Use up all of the bandwidth of the current frequency step.)
After the testing me and Zero worked on this new version of Helix_Schedutil.

The current behaviour of the governor is the following:
- Boost frequencies when load is below Target_Load1. (Boost can be increased by DECREASING bit_shift1 value.)
- Between Target_Loads there is no bit_shift at all. The governor just uses the following algorithm instead - (max_freq*util/max = next_freq)
- Loads higher than Target_Load2 will be THROTTLED. Bit_Shift2 here is subtracted rather than added. (Throttle effect can be increased by DECREASING bit_shift2 value.)

The result is that low freqs have spare bandwidth to avoid lags, middle frequencies leave no extra bandwidth at all, while higher frequencies are throttled to save battery.
Another focus of the governor update is to reduce overhead as much as possible. This results in a very responsive governor which isn't overly demanding on battery life.
Schedtune.boost values recommended for use with this governor:
Top_App: 5
Foreground: -50
Background: -50
Global: -50

Energy-DCFC is still recommended for those who prefer battery life over performance, but if you prefer greater performance then this governor can be used without making you feel guilty about wasting battery.

Correcting a misconception:
Some people describe tipping point as the load threshold which the governor uses to decide whether to ramp up or down.

While if you look into the behaviour of the governor it may appear that it behaves in such a way, it is technically incorrect.

As I mentioned previously this new algorithm moves away from the behaviour of legacy governor algorithms which focus on the current frequency load.
This governor does no ramping up or down.
It isn't even aware of the current frequency load, as it only knows the load relative to max capacity.

The misconception appears based on a property of the algorithm that results in a consistent load at any chosen frequency. This is a coincidental result of the algorithm, even though the algorithm is completely unaware of it.

Tipping point is in fact the load percentage at which the CPU reaches max frequency and any increase in load forces it to wake up a new core.
 
Last edited:

Mostafa Wael

Inactive Recognized Contributor
Jan 11, 2013
6,107
5,568
24
Gotham
A collection of useful informative links about EAS:
1- My insight about schedutil, sched and HMP's Interactive governor behaviour. Despite the fact that my write up was dependent on the EAS implementation in my OnePlus 3, I think it is fairly relevant since I wasn't having any extra boost drivers or any PowerHAL changes at the time. In fact, I need to rewrite my analysis for the OnePlus 3 now since I got some powerHAL changes :eek:

More to come
 
Last edited:

DeeZZ_NuuZZ

Senior Member
May 16, 2012
11,496
4,550
27
Hanover
F.A.Q.

1. Will this kernel work with LOS/AOSP-based roms?
A. Yes, starting from version v18 we support AOSP/LOS-based roms. We've tested LOS and AOSP Nougat and Oreo roms and they like they should.

2. I have corrupted SDcard!
A. A temporary fix would be to reboot to recovery, mount USB storage, un-mount and reboot to system. Might be an issue with the exFAT nofuse driver.
 
Last edited:

ZeroInfinity

Recognized Developer
Dec 17, 2011
7,025
74,009
Brighton & Hove
There's nothing that should prevent Verizon support correct? Or at least I couldn't see anything on your git. If it's more of the issue of having no Verizon testers, then I'd be happy to clean flash my rom to test it.
If you want to test it for me you may, I don't have any Sprint of Verizon users available but if the kernel is bugged on those devices then it may take some time for me to support them.
 

antonio82

Senior Member
Mar 11, 2015
121
8
The format of the card I do not know because I put the card and I have not modified the card, I have the rom ice and the twrp 3.0.3-9
 

ZeroInfinity

Recognized Developer
Dec 17, 2011
7,025
74,009
Brighton & Hove
The format of the card I do not know because I put the card and I have not modified the card, I have the rom ice and the twrp 3.0.3-9

yeah it must be exFAT. Don't worry though, your card isn't actually corrupted, just the OS could not read it due to something wrong either in kernel or something wrong with texfat module. I advise you restore to your previous kernel until I've fixed this.
 
  • Like
Reactions: antonio82

antonio82

Senior Member
Mar 11, 2015
121
8
yeah it must be exFAT. Don't worry though, your card isn't actually corrupted, just the OS could not read it due to something wrong either in kernel or something wrong with texfat module. I advise you restore to your previous kernel until I've fixed this.

I will keep it installed to see the operation and when it is corrected I will install it again
 

munkyvirus

Senior Member
Dec 21, 2010
848
312
Minnesota
So I installed the kernel and rebooted and Magisk said it was uninstalled. I reinstalled the Magisk zip and everything was working again, but EXKM didn't pick up any EAS governor's beside the Helix one. I then ran the EAS tuning script from totally_anxious and it couldn't find any of the EAS tunables. Is this what the Magisk version will be for?
 

ZeroInfinity

Recognized Developer
Dec 17, 2011
7,025
74,009
Brighton & Hove
So I installed the kernel and rebooted and Magisk said it was uninstalled. I reinstalled the Magisk zip and everything was working again, but EXKM didn't pick up any EAS governor's beside the Helix one. I then ran the EAS tuning script from totally_anxious and it couldn't find any of the EAS tunables. Is this what the Magisk version will be for?

Magisk versions in post 3 as said below the download link which I'm still waiting for @p50kombi to upload when he's free.
 

aer0zer0

Recognized Contributor
Sep 20, 2013
3,304
2,539
Cortland NY
Google Pixel 6 Pro
If you want to test it for me you may, I don't have any Sprint of Verizon users available but if the kernel is bugged on those devices then it may take some time for me to support them.

VZW HTC 10 here, good so far, no SD card problems, magisk is fine, gonna run it and see how it does battery wise.
 
Status
Not open for further replies.

Top Liked Posts

  • There are no posts matching your filters.
  • 42
    To all my fans: it's been a great ride with you guys for the past 5 years here, but unfortunately the time had to come. I am currently selling my HTC 10, and will use that money to buy a OP5t on the 20th January. For those of you who have followed me since the HTC One X, I have stuck with HTC ever since, but I feel like it's time for me to jump ship at last. Flagships are getting much more expensive, and development on HTC devices just isn't as much as it used to be, and certainly not as much as devices like pixel or oneplus devices. As someone who studies software engineering, it's my hobby to tinker with software, I'm getting pretty bored with the 10 mainly due to extremely slow updates (about 2 WWE updates last year). I'm not sure if I will go back to HTC, we will see in the future.

    Development for helix kernel and AcoustiX will be deprecated soon, and I will move to OP5t, not as a kernel developer, but I will focus on improving helix engine itself. Helix Engine will be my main focus now, and it is compatible with any EAS kernel. I will soon make the engine customizable again, and furthermore, make it into an android app. Helix Engine has a long way to go, and it is currently my proudest projects I've done in my own time, so I will continue to work hard on that. I will be making helix engine easier to install on other devices that have EAS kernels and will be making a separate thread for it very soon.

    As for audio mods, I'm done with audio development. I used to be addicted to surround sound effects, but after giving my new bt headphones a try (wh1000xm2), I never want to go back to surround sound effects. The absolute purest audio is what audiophiles should be achieving, no additional effects, no additional processing, just pure audio. It's the best decision I've made, and combined with LDAC, audio quality is indistinguishable from wired (using TIDAL hifi streaming at 44.1/16 FLAC). Additionally, I believe audio on android has evolved quite fast and quite significantly, to the point where I believe that audio mods aren't necessary anymore. Sure, you may still need them for crappy audio hardware, but you'll still be limited to the hardware's capabilities. It might sound better to you, which is good, but nothing can beat better hardware.

    Goodbye to my HTC fans here, and welcome to people who might follow my work onto the OP5t. Thank you to my fans who have followed me since the beginning when I started my first audio mod on the One X back in 2012. Thank you to countless developers who have helped me along the way. Additionally, I would like to give my personal thanks to @Stephen for helping me a lot with issues I've had during my time in the HTC 10 forum, without him, I would have quit a while ago.

    Sent from my HTC 10 using XDA Labs
    34
    ANNOUNCEMENT 14/01/18 PLEASE READ!


    This kernel is based on 100% latest HTC official source. EAS was ported from scratch using @RenderBroken 's commits (with permission from him).



    THIS KERNEL IS BATTERY ORIENTED! DO NOT EXPECT AMAZING PERFORMANCE FROM THIS KERNEL! PERFORMANCE IS DECENT ENOUGH FOR NORMAL USAGE! If you are here to try out performance then this is not the kernel for you. Do not go complaining about performance unless it is extremely bad.



    Features:
    -Compiled using Linaro GCC 6.4.1 Toolchain
    -Energy Aware Scheduling r1.3
    -HELIX-ENGINE: A pnpmgr replacement compatible with EAS
    -Working thermal-engine for Sense without the need of pnpmgr (binary from LOS)
    -Much more efficient special CPUSET set-up (big cluster as main rather than little)
    -NEW governor: pwrutilx - another governor based on schedutil
    -Button Light Notification mod
    -LED Pulse/gradient charging mod
    -Fast charging
    -Backlight dimmer
    -Double tap fingerprint 2 sleep
    -Maple and BFQ I/O
    -Adreno GPU boost
    -KCAL Colour control
    -Sound Control
    -Misc fixes and patches
    -Using exFAT driver ported from @dorimanx 's OP3T kernel (since nofuse driver was giving issues and stock HTC texfat was not compatible with EAS kernels)
    -F2FS support


    pwrutilx - a new EAS governor based on schedutil that aims to be much more efficient by using a different formula to get next frequency.


    HELIX-ENGINE v5.0
    - SELinux set to PERMISSIVE is MANDATORY to get app engine working!! This is due to using a function called "pipe open" in C which is able to collect the output of terminal commands used, SELinux always blocks this when set to enforcing.


    App Engine: dynamically adjusts schedtune.boost and governor tunables in a per-app basis.
    - Battery profile sets schedtune.boost to -100, 1000 up_rate_limit and down_rate_limit, 0 iowait_boost.
    - Performance sets schedtune.boost to 10, 500 up_rate_limit and 20000 down_rate_limit, 1 iowait_boost.
    - Default (apps that are not included in either lists above) sets schedtune.boost 1, 500 up_rate_limit and 20000 down_rate_limit, 0 iowait_boost.

    - App package names are added to battery.conf and performance.conf (/system/etc/helix_engine), the engine will check them to see if the top-app (current app) matches with the names scanned through those lists. If a match is found, it will apply one of the profiles above according to what list the package name is in.

    Suspend Engine: when display is turned off, it will use battery profile settings until screen-on.

    Helix Engine is closed source currently since it is my own work, writting in C completely from scratch. However, devs are free to integrate Helix Engine to their ROMs/Kernels/whatever as they see fit as long as they give me credits.

    Read post 2 regarding dev information about Helix Engine.



    This kernel is compatible with Sense and AOSP ROMs (Nougat and Oreo supported). This kernel is NOT compatible with Sense-based Oreo ROMs!

    Please ensure that you have made a backup of your boot, system, and data partitions in case anything goes wrong.




    If you update Magisk with this kernel installed, you MUST reflash the kernel. Everytime Magisk gets updated, it will restore the stock init.rc ramdisk file and re-append magisk lines to it, rather than just re-append magisk lines without restorting stock init.rc ramdisk. If you do not reflash the kernel after this, then init.helix.rc will not execute on boot since init.rc has been replaced by stock again due to Magisk update. Which means EAS will not be set up correctly (if you're on sense) and Helix Engine will NOT work.

    Bugs:
    - custom cpuset config gets overwritten by Oreo ports, you MUST follow this guide to get slightly better battery life, battery life on Oreo is still bad but that is mainly a ROM/port issue.
    - msm_thermal may be enabled by default for some (Sense ROMs mainly), DISABLE THIS SETTING IMMEDIATELY AND KEEP IT DISABLED ON BOOT! It can result to bad battery life as this function will prevent both clusters from going below 700MHz.
    - exFAT is still a hit or miss, it will work for some people and won't for others. There isn't much I can do about it I'm afraid unless someone has a better solution...
    - USB Tethering and WiFi Portable Hotspot are NOT WORKING FOR AOSP ROMS! This should be fixed in the next update (no ETA).



    Posts #3 and #4 are very irrelevant now, you can ignore these 2 posts.






    Credits:
    @RenderBroken - who helped me a lot and taught me more about using git version control
    @joshuous - another OP3 developer who helped me with EAS and discussing ideas about it
    @Kyuubi10 - tester + coming up with the idea for a new algorithm for helix_schedutil
    @p50kombi - Tester + making Magisk-compatible zips
    @Mostafa Wael - introduced me to great devs, discussing and researching more about EAS, coming up with the idea of dynamic schedtune.boost
    @DeeZZ_NuuZZ @CharliesTheMan - Testers
    @Captain_Throwback - helping me a lot with exFAT and his exFAT no-fuse patch to make it work on the 10
    @dorimanx - ExFAT driver in his OP3T kernel
    @ivicask for making a template of AROMA installer for me to work with for the kernel, inspiration to make my own engine!
    @TotallyAnxious - tester + helping me with a few issues + Advanced EAS Tweak scripts
    @RogerF81 - tester + Advanced EAS Tweak scripts
    @flar2 - backlight dimmer, Adreno boost, Sound Control
    @tbalden - double tap fingerprint 2 sleep, BLN, LED pulse/gradient mod, fastcharge, kcal port, AOSP LED light fix
    @franciscofranco - misc commits such as WiFi wakelocks and power efficient workqueues, display_on() API
    Eliminater74 - ASoC 4.4 backport commits, remove traces of pnpmgr commits, Maple and BFQ I/O commits
    PFOS Team - Commits needed for Oreo support

    If I have missed anyone, please contact me via PM and I will add you to the list.
    25
    v014 is coming very soon!

    WE FINALLY HAVE EXFAT WORKING WITH NO ISSUES (so far from testing for at least a week now). I'm using a totally different driver for it now.

    The clusters are set up differently, v014 is going to be better in performance and battery because of the changes I've made to change how tasks are being processed by different clusters.

    Thermal-manager will be incorporated into HelixEngine, which is a script that infinitely runs in a loop (like thermal manager) every 5 seconds without impacting on battery or performance whatsoever.

    Finally, the kernel has been built again from stock source again. It will be a lot cleaner than before and should be running much better now.
    24
    v014:
    * Added balanced and battery tweaks from Advanced EAS Tweaks (thanks to @RogerF81 @TotallyAnxious)
    * Added ZeroInfinity's personal Advanced EAS Tweaks based on battery tweaks
    * Added TotallyAnxious' personal Advanced EAS Tweaks
    * Added Helix Engine executable binary and necessary files in /system/helix_engine
    * 2a19eb9b8e0 - [HELIX-ENGINE]: Added new sysfs node "enginecap" (19 hours ago) <ZeroInfinity>
    * 0203d822b4b - [HELIX-ENGINE]: Added more sysfs nodes (3 days ago) <ZeroInfinity>
    * 96811d98170 - [HELIX-ENGINE]: Initial kernel integration (4 days ago) <ZeroInfinity>
    * 0e51404a512 - exfat: ported driver from Dorimanx's OP3T kernel (9 days ago) <ZeroInfinity>
    * 0963424716b - cpufreq_pwrutilx: Remove display_on() API (9 days ago) <ZeroInfinity>
    * 8027127f24f - Revert "Add exfat no-fuse" (11 days ago) <ZeroInfinity>
    * REBUILT KERNEL FROM STOCK HTC SOURCE AGAIN (much cleaner now)

    ExFAT is working much better than before but cannot guarantee 100% still. I highly recommend you delete Android/data folder ON YOUR EXTERNAL STORAGE before installing the new update to prevent any problems. Thanks to @TotallyAnxious for testing the new exFAT driver + tip to prevent corruption issue

    [HELIX-ENGINE]

    Consists of 3 different engines:
    -Thermal Manager: a thermal throttling solution built within the binary itself

    -App Engine: similar to pnpmgr, can use per-app profiles and cap frequencies accordingly. Gives more user control than pnpmgr, users can add or remove package names from battery.conf, balanced.conf, and performance.conf lists in /system/helix_engine. Battery profile caps all cpus to 1GHz, gpu to 200MHz, stune boost to 10. Balanced profile caps big cluster to 1.5, little cluster to 1.2, gpu to 300MHz stune boost to 10. Performance does not cap any frequencies at all, it justs boosts stune to 10.

    -Suspend engine, when display is turned off, all cpus are capped to 1GHz, gpu capped to 200MHz, stune boost set to 0.

    -Parts or all of the engine can be turned on/off by turning the "enable" sysfs nodes to 0. Do not touch any other sysfs nodes such as throttlecap and enginecap as those are used by the engines to prevent throttle manager and app engine from fighting each other for control (if you change them anyway they will revert back to normal).

    Helix Engine's binary is closed source to the public currently, it is not part of the kernel so I am not obliged to release the source just yet. I have however released the source for kernel integration only currently due to GPL license. Just like how HTC have done it with their pnpmgr. Before anyone tries to report me for violating GPL, HTC has done the exact same where they keep the source of the binary executable for pnpmgr as closed source, but only released the source for kernel integration of pnpmgr.

    Helix Engine is written in C completely from scratch by me over the past 3 days.

    If this gains more interest, I will consider releasing the whole source code publicly.

    Kernel developers may use Helix Engine in their kernels but would need to set it up the exact same way I have in my kernel. Also, Thermal Monitor must be disabled in the kernel defconfig to prevent conflicts with Helix Engine's thermal manager.

    I have changed the set up of cpusets in a way that it does not task migrate from cluster-to-cluster anymore. This is not necessarily a bad thing! At the start of v014 I was conducting some tests to see what is more energy efficient. The big cluster can do more Instructions Per Cycle at a LOWER frequency than the little cluster at a higher frequency. @RogerF81 did battery tests and concluded that it was much more efficient to run big cluster as the main cluster than the previous with the little cluster running as the main cluster.

    Right now, top-app and foreground has been assigned to big cluster only, while system-background and background has been assigned to little cluster only. Previously, both clusters were assigned to top-app, little cluster + cpu3 assigned to foreground, little cluster only assigned to system-background, and cpu0 assigned to background.

    When profiling, you will see big cluster in use more often than little cluster, do not mistake it as draining more power. It will be normal to see the little cluster so tamed while the big cluster is working more actively in this kernel as of v014.

    When running benchmark apps, it is normal to see multicore score being absolutely destroyed compared to HMP and other kernels, but we are not aiming for maximum performance :) and single core scores are still unaffected.

    READ THIS BEFORE DOWNLOADING!!!: https://forum.xda-developers.com/showpost.php?p=72209807&postcount=712

    Download: https://drive.google.com/open?id=0B8kuEu5c5ohnS2ZmRVBzeGJwNnc
    21
    Right, it's been a while on here so I thought I'd give another update on the progress of helix engine v4.0!

    I've just redone the logic of the code in app engine, which fixes a few bugs encountered with thermal throttling. This should make the app engine work a lot better than it did before, I'm trying to clean up the code a bit now so it'll run better.

    SELinux is still a problem, there is an attempt I have yet to try (basically brute forcing a bunch of dontaudit rules until it works) and I have no clue if it'll even fix our problem. I will need to find time to do this. The final option for SELinux is to just set SELinux to permissive via kernel command line so it'll be permissive on compile. This would get rid of all SELinux related issues.

    It is unknown at this time when I will plan on releasing v017, still got some work to do on it but will definitely keep you guys updated.

    EDIT 30/06: We needed to add pwrutilx gov back again because we noticed schedutil still had insane battery drain compared to what we were used to. We will still be using WALT again though, so no more using PELT.