[GUIDE]OP3 & CM13 ROMs. Details on the different power modes.

[GUIDE]OP3 & CM13 ROMs. Details on the different power modes. - OnePlus 3 Guides, News, & Discussion

If you've trouble picking a power profile in cyanogen and don't want to compromise on performance, you've came to the right place. Below are all the details you need to make an educated decision on what profile works best for you. These are the values I took from the ROM.
These are relevant for all custom ROMS, to the best of my knowledge, unless modified, and the details below take into account over and underclocked kernels.
They're slightly different from the ones I posted in my original thread. The values there might still be useful to some of you, as that was real-world results from the stock kernel: https://forums.oneplus.net/threads/cm13-power-modes.458290/#post-15134195
https://github.com/CyanogenMod/android_device_qcom_common/blob/cm-13.0/power/power-8996.c
Here goes.
In BOLD is all values manually applied.
Every "0" defines where the value is equal to the lowest frequency the kernel is set to operate at.
Every "FFF" (as it's defined in hex in the repository, I've converted all other values from hex to decimal below, but FFF in decimal is 4095, which is the theoretical maximum defined in the powerhal) defines the max frequency that can be applied by the operating kernel. This isn't set to the actual figure, as this allows, for example, ElementalX kernels that are overclocked to be implemented without interfering with cyanogen's battery profiles, allowing them to work together with no trouble.
(Basically, FFF is your max frequency on that core)
Power Saver: Cores 1,2,4 active
Little - Min(0) Max(1000)
interactive governor
Big - Min(0) Max (1000)
interactive governorEfficiency: Cores 1,2,3,4 active
Little - Min(0) Max(1000)
interactive governor
Big - Min(0) Max(1300)
interactive governorBalanced: Cores 1,2,3,4 active
In balanced mode the ROM changes these values on the fly.Quick: Cores 1,2,3,4 active
Little - Min(0) Max(FFF)
interactive governor
Big - Min(1400) Max(FFF)
interactive governorPerformance: Cores 1,2,3,4 active
Little - Min(FFF) Max(FFF)
interactive governor
Big - Min(FFF) Max(FFF)
interactive governor

Thanks brother, I was wondering what the differences were good stuff

Related

[Info] MBQs CPU Guide thread. (Tips, IO Schedulers, TCP Algorithms, and more!)

MBQsnipers Guide to Kernel Knowledge
It lives again!
----
CPU Guide app:
Want this in app form? Lucky for you, I made one!
Get it here:
https://play.google.com/store/apps/details?id=com.kyler.mbq.mbqscpuguide&hl=en
----
CPUGuide website:
(If you're using it on a mobile browser, enable desktop mode).
http://CPUGuide.MBQonXDA.net
----
Contribute to the app!
It's always very appreciated. I also need translations.
https://github.com/MBQs-CPU-Guide/MBQs-CPU-Guide
---------------------------------------------------------------------------
Governors:
OnDemand:
Ondemand stands for that it scales up on load in frequency and then detects the load and scales back to a frequency which is fullfills the "demand" of the current load dynamically. (AndreiLux)
Interactive:
Interactive scales by default in steps towards max frequency, Ondemand in its default implementation scales immediately to max frequency. (AndreiLux)
InteractiveX(v2):
The same as Interactive, but when you turn your screen off it forces the second CPU core offline until the screen turns on again.
Performance:
Will constantly run at the highest set CPU speed.
Powersave:
Will constantly use your lowest set CPU speed.
Conservative:
Conservative means that it scales conservatively, not that it is conservative. It pretty much very similiar to Interactive in that it scales up and down in frequency steps. It actually can be one of the most aggressive governors out there. (AndreiLux)
Userspace:
Rare in the word of kernels. Typically not used for mobile phones. But what it basically does is, it runs on whatever CPU speeds the user sets through an app.
Lagfree:
More aggressive kernel. It scales the CPU faster, reducing lag and performance, while maintaining decent battery life. Its main goal is to increase performance without reducing battery life.
Min Max:
Only uses your max screen on frequency, and your min screen on frequency.
Hotplug:
Based off of Ondemand. It allows a CPU to go offline with minimal usage. When you're sending messages, browsing settings, or other simple tasks, most likely one of your CPUs will be offline.
PegasusQ:
Samsungs Governor for multi-core phones. Based off of Ondemand. This kernel controls hotplugging as well.
Lazy:
This Governor doesn't scale as fast. It's really a lazy governor, it tends to stick in the same CPU frequency without changing as much. Which can be beneficial to your battery (if your CPU settings are conservative) or can reduce battery life (if your chosen frequencies are aggressive).
Nightmare:
A modified PegasusQ, less aggressive (Which means not as good performance-wise), and doesn't usually hotplug. It is good for a balance between performance and battery life. May prevent the 'Screen of death' as well, since it doesn't hotplug.
HotplugX:
Its basically a smarter Hotplug, to my knowledge, it shuts off the second core much faster, and is a little bit smarter with CPU scaling and power efficiency.
LulzActive:
Based off of the Smartass and Interactive governor(s), the newer version of this Governor gives more control to the user, and he CPU frequency parameters (Ask for a description if you need one) are smarter. Smart at scaling both up and down.
Smartass:
Based off of the Interactive Governor, this is an older version, but this Governor is (or was) one of the smartest Governors, and is smart with performance and battery. More below.
SmartAssV2:
A re-thought version of the original Governor. This one aims for ideal frequencies, meaning it makes up its own frequences in order to meet the requests the CPU needs. Scales down the CPU extremely fast once the screen is turned off, meaning you will get amazing standby times. No upper limit for the CPU frequencies in both the screen on and screen off state(s). (If you want a better detailed explanation of that, please ask.)
Lionheart:
Conservative-based governor off of Samsung update3 source (Line copied directly from a guide, thank you 'Amal Das'), scales aggressively. This Governor is strictly for performance.
BrazilianWax:
Similar to smartassV2, the only real difference is, it scales more aggressively than SAv2 does, which reduces battery life, while improving performance.
SavagedZen:
Based off of SmartassV2, similar to BrazilianWax, but this Governor tends to favor battery over performance. From personal experience, I can say it does a great job of doing so.
Scary:
Conservative-based Governor with some smartass features. Ramps speed up one at a time, and ramps speed down one at a time (ask for description if you don't understand). Caps your screen off speed at 245MHz. Scales just like conservative would. This Governor is more for battery life than performance.
Sakuractive
A governor based off of hotplug and ondemand. The phone hotplugs (when it can) when the screen is on, and can be described as a 'hybrid' of hotplug and ondemand
OnDemandPlus
A governor based off of OnDemand and Interactive. It provides a balance between performance, and saving battery.
DynInteractive
A dynamic interactive Governor. This Governor dynamically adapts it's own CPU frequencies within your parameters based off the system(s) load.[/SIZE]
Advanced CPU Governor settings:
I got most of my information from this thread.
Sampling rate:
Microsecond intervals the governor polls for updates. Assists in the Governor determining whether or not to scale up or down in frequency.
Up threshold:
Defines the percentage from 1 to 100 (percent). Happens less often when clocked at a lower speed, overclocks when you get up into higher CPU frequencies. Using a Governor such as OnDemand prevents it from overclocking nearly 100% of the time.
Ignore nice load:
If you set the value to '1' the Android system will ignore 'nice' loads when the CPU Governor scales up or down.
'Nice' load:
When you turn a process into a 'nice' load, it prevents low activity processes randomly becoming high priority processes, which prevents lag. What a 'nice' load is, is how it handles processes. You can 'Re-Nice' processes, and re-set how processes are determined, based on your current processes that you have. Which helps eliminate lag due to processes being re-prioritized.
Frequency Step(s):
Determines how much the Governor will increase, or decrease, based on your CPU speeds. *This doesn't apply to some Governors
I/O schedulers:
Deadline:
Set to minimize starving of requests. In other words, it is designed to handle system requests as quickly as possible.
Noop:
It handles requests in a basic 'first in, first out' order. So any requests that come in, will also be the first to be executed.
SIO:
A mix between Noop and Deadline. Basic process/request merging. One of the most reliable schedulers out there.
BFQ:
Gives each request a time budget. If the request is not met by the time it is given, the request is skipped. Smarter than the CFQ governor.
CFQ:
'Completely Fair Queuing' scheduler. Scales its requests in an effort to insure smooth task handling. Attempts to give each request equal I/O bandwidth. Typically, lag happens with this scheduler due to the effort of competing tasks on the disk because it tries to give equal bandwidth amongst all requests.
FIOPS:
Relatively new. No I/O seek time, ( potentially better for performance), balanced read/write times, one of the smarter I/O schedulers
ROW:
Read Over Write. It will cause better read times for pictures/media, but when transferring data/installing apps, significant reduction of performance will be present.
V(R):
Best for benchmarks due to performance of requests, but is considered unstable due to random drops in performance. Semi-based off of the CFQ scheduler.
FIFO:
Takes each process in one by one, fair process queuing, balanced queue handling as well, processes go in and out in a numerical fashion.
TCP Congestion Avoidance Algorithms:
Tahoe:
Limits unknown packets being received. Limits the congestion window, and reset itself to a slow-start state.
Reno:
Basically the same as Taho, but.. if 3 of the same packets are received, it will halve the window, instead of reducing it to one MSS. It changes the slow start threshold equal to that of the congestion window.
Vegas:
One of the smoothest (next to cubic), it increases the timeout delay for packets, which allows more to be received, but at a higher rate. It also has set timeouts, which helps with speed because it's constantly being refreshed.
Hybla:
Penalizes connections that use satellite radio. Not usually used with phones.
Cubic:
One of the best, most recommended TCP options available. Less aggressive, Inflects the windows prior to the event. Used in Linux.
Westwood:
A newer version of Reno, and another commonly used one. It controls parameters better, helping out streaming and overall quality of browsing the internet. One of the most 'fair' algorithms out there, and is one of the most efficient algorithms to date.
CPU Governor recommendations:
Performance: Use Wheatley, or Performance.
Battery life: Use lagfree, Hotplug, PegasusQ, InteractiveX, or Sakuractive.
A fine balance: Use SmartassV2, Hotplug, or Sakuractive at less aggressive CPU frequencies.
Android tips:
Developer options:
Go to settings>build number... And tap 'build number' 7 times, go back, and you have now enabled developer options.
Force GPU rendering:
What it does is, it force enabled 2D drawing (such as scrolling, and anything non-game/app related) to the Graphical Processing Unit, instead of the Central Processing unit. What does/can this do? It has the potential to save battery life, and takes some of the load off of your CPU, which increases overall smoothness and reduces lag.
Keeping WiFi on during sleep:
What it does is, as this ^ suggests, keeps WiFi on while your phone is awake. To enable this, (and there are many ways.. I'll give you the way I'd do it.) Go to settings>WiFi>WiFi settings (3 vertical dots)>Advanced settings>keep WiFi on during sleep.. And set it to 'always' or.. You can use tricksterMOD and enable that via the GUI (Graphical User Interface)
WiFi Supplicant Scan Interval:
Before you freak out, I will give you what it means. What it means is this: how often your phone scans for a WiFi signal. Typically, it is 15 seconds. The recommended number is 300. To change it, you can typically find it in the build.prop manually edit it on your computer, or use an app such as ES file explorer and run it as root. Go to build.prop and look for: wifi.supplicant_scan_interval=x. And change x (usually 15) to 300, save, exit, and reboot. Please note it is not available with some ROMs that are driven towards a stock-ish feeling. Such as CM ROMs, or any derivative of that ROM.
Tips to get better battery life:
Turn off sync, location, Bluetooth when you're not using it, along with WiFi and data, don't use app-killer apps, lower CPU frequencies, and change your Governor to something less aggressive if you don't use it for heavy gaming.
Status bar with 1 finger, panel with 2:
If you want to access the tile settings quicker. Drag your status bar down with two fingers. If you want to bring down the status bar, touch the top of your screen and slide your finger down.[/I]
Autobrightness sucks!!:
Download an app called 'lux' and use that app. It'll take of any problems you're having, plus it'll save battery.
Changing your phones screen density:
In your build.prop, there is a line of code that looks like this: ro.sf.lcd_density=320, change it to 240 for a tablet-ish feel. Don't go under 160 though, you'll have endless bootloops
Change your bootanimation:
Go to system/media, you'll see bootanimation.zip, replace it with your desired bootanimation, change permissions to r-w-rr (read-write-read-read), and reboot. (Assuming you're doing this on your phone)
Block ads:
Download an app called 'adblock' on the play store, run it normally, accept the SU request, hit 'skip' and run the program, exit out, and reboot!
4x MSAA:
4 times MultiSample Anti-Aliasing. What this does is smooths out edges in apps that support AA. It makes your game look better, enhances graphics, but has the potential to degrade performance due to the screen enhancement. To enable this, go to settings>developer options>and check the box that says 'Force 4x MSAA'
zRAM:
Avoids disk paging, compresses your RAM. Disk paging means the way your phone saves temporary data. It helps with fragmentation of your disk and the physical space, which, over time, keeps speed stable and prevents any system slowdowns.
Explanation of TricksterMOD Settings:
General:
TCP:
Affects download speed
Scheduler:
How your system responds to, and handles tasks
Readahead:
How far ahead your internal SD caches when you put stuff on it
Frequency profile:
Save your frequencies
Min:
Minimum screen on time
Max:
^Opposite of minimum
Max screen off:
Max screen off frequency
Governor:
How your CPU essentially scales
Specific:
Wifi high performance:
Keep wifi on when the screen is off
Content adaptive brightness:
Better whites at low screen
Force fast charge:
Fast charge when your phone is hooked up to your PC/whatever
Group task:
Equally distribute loads amongst the CPUs
High performance sound:
Better sound
Headphone volume boost:
Boost the headphone volume for louder audio
Touch wake:
Touch your phone after you turn the screen off, and itll turn it back on
Vibrator strength:
Set the strength of the vibration of your phone
FSYNC:
When disabled, provides faster writing (not reading) of files with the risk of data loss if the phone crashes or is shut down improperly. (Thanks renaud)
Temperature limit:
How high your phones temperature can get before your phone reacts
Temp. throttle:
Enable the temperature limit
GPU OC:
Graphical Processing Unit overclock
MPU:
Mathematical Processing Unit
zRAM:
RAM compression to speed up your phone
*Leave on Core, IVA, and MPU
Voltages:
Set the voltages of each CPU frequency.
Feel free to 'thank' me for this, but.. it isn't expected.

Little outdated.
Will update as time goes on.

thanQ vvvery much!!
very useful thread..
can i ask you something?
my phone is very fast and responsive sometimes.. but if i keep screen off for some hours, after turning on when i click on an app (even if it's running on background) it'll
launch with some delay.. i don't like it at all..
i don't play heavy games.. but i need my phone response each touch and launch certain app as quick as possible.. which Governor, Scheduler do you suggest?

Dark Fear said:
thanQ vvvery much!!
very useful thread..
can i ask you something?
my phone is very fast and responsive sometimes.. but if i keep screen off for some hours, after turning on when i click on an app (even if it's running on background) it'll
launch with some delay.. i don't like it at all..
i don't play heavy games.. but i need my phone response each touch and launch certain app as quick as possible.. which Governor, Scheduler do you suggest?
Click to expand...
Click to collapse
Raise your min screen-off frequency

Thanks for taking the time to put this together, you really have outdone yourself. :thumbup:
Sent from my Nexus 4 using XDA Premium 4 mobile app

yeah little outdated but very informative thread for many new android explorers to understand things better. :highfive:

just a suggestion: UI card like in google now, keep

aLNG said:
just a suggestion: UI card like in google now, keep
Click to expand...
Click to collapse
I don't follow...
Sent from my Galaxy Nexus using XDA Premium 4 mobile app

MBQ_ said:
I don't follow...
Sent from my Galaxy Nexus using XDA Premium 4 mobile app
Click to expand...
Click to collapse
i will give you a prototype what i mean by User Interface (UI) card later

This is great, clears up many concepts! Good work bro!

feedtheducks said:
This is great, clears up many concepts! Good work bro!
Click to expand...
Click to collapse
Myyy pleasure.
Have another version of the CPU Guide app coming soon too.
Sent from my Galaxy Nexus using XDA Premium 4 mobile app

[KERNEL][TW/LP][13.10.15][SM-T800][SM-T805] IronKernel V2.5 STweaks

Hey guys, I'm back with a new KERNEL for both Variants of the Tab S 10.5 (T800 and T805)!
Some guys probably know me from the IronRom . I decided myselfe to create a custom kernel for our really great Tab s 10.5, I'm getting better and better at this stuff, I don't thought that
It is basically the normal kernel with some modifications for better performance and hopefully also batterylife. It is for the stock kitkat (4.4.2) touchwiz and not for cyanogenmod or something else.
I excuse all devs here visiting my github page, it is such a mess (with the commits)! I know it, but I'm doing this the first time, so hopefully you will forgive me.
The kernel is pretty stable, I just call it a beta version, because I can't test the T800 version, so if with thisone also all works great -> stable
IF YOU FOLLOW MY STEPS BELOW, YOU WILL MAY LOSE YOUR WARRANTY, KNOX WILL DISPLAY 0x1! I'M NOT RESPONSIBLE FOR ANY DAMAGED DEVICE!
You can try to use the kernel adiutor app, or just the preinstalled sTweaks, but not both at the same time! This will cause problems.
Notice, V2.0 and onwards is only for TW lollipop and not for kitkat anymore!!
Features of my Kernel::- Built with latest 5.2 Toolchain compiled by myself!!
- Latest Kernel version 3.4.109, includes all updates from linux mainstream, patched it form 3.4.39 up to 3.4.109 (was a lot of work)
- Choose between different CPU governors: Interactive (default), Powersave, Performance, Userspace, Conservative, Intellidemand, Intelliactive, Ondemand, Adaptive, Abyssplug, AbyssplugV2, Badass, DanceDance, ZZmove, Nightmare, Wheatley, Lionheart, Darkness, PegasusQ and Intellimm
- Built with latest ramdisk sources from samsung
- Kernelsource from T805XXU1BOG2
- Underclock to 200MHz and Overclock to 2.0GHz
- GPU works from 100MHz to 733MHz (default)
- I/O schedulers: ROW (Default), cfq, No-op, Deadline, Test, BFQ, FIOPS, SIO, VR, ZEN, FIFO and SIOplus
- Readahead can be set
- UKSM (Ultar Kernel Samepage Merging)
- Gentlefairsleeper and ARCH power
- Android Logger
- data and cache f2fs support!
- Init.d Support
- Busybox support
- Full STweaks support
- Charging Control
- Cpufreq voltcontrol
- ZRam and Swap
- Allow ADB-Insecure
- Low Memory Kill
- TCP (Network) control: Cubic (default), Reno, Bic, Westwood, Highspeed, Hybla, HTCP, Vegas, Veno, Scalable, LP, Yeah and Illinois
- SeLinux is set to permissive
- Compiled as small as it could be (just around 6MB)
Download:In the second post
Googy Max STweaks
Bugs/Problems:-sTweaks can't enable the right GPU over and underclock freqency
-Some other stweaks stuff, you will see
-Didn't tried the voltage table
Instructions:
If you want to install the Kernel, follow this:
1. Install a custom recovery for your tablet, like this one here: TWRP Recovery
2. Follow the instructions on the page above, until you get a working recovery
3. Download the Kernel from below and copy it to your external SD Card
4. Reboot to your recovery by pressing volume up, home button and power button at the same time.
5. Install zip, and select the kernel
6. Wipe cache and dalvik cache (recommand)
7. Reboot
Support:If you like my work, please hit a thanks down on my posts. A thanks is enough!:highfive: If you really really really really really like my work, you can donate something to me, but it is not necessary. I created a paypal account, just in case, someone would give me a small donation. :good:
As I said, you don't have to give me something, but this keeps me motivated to built better roms and keep updating everything. It's your choice, and I'm very thankfull for every donation! No matter how big it is! Thank you so much for supporting me, cheers and have a nice day :fingers-crossed:
Donators for the Kernel:- @Hookmt Thank you very much for your support giving to me! I really love that and it also wasn't the first time you donate something to me! Thank you so much, I really really really appreciat that mate. Transaction number: 42P214019W495221S
Credits/Thanks:- Samsung for sources
- @Christopher83 for the compiler
- @UpInTheAir for the work he already did in his own kernel (could use some of his commits on github (opensource) and see what he did when I didn't know what I did wrong). He also inspired me to work on my own stuff and kernel, thank you very much!
- @googy_anas, without him, I would not have a working kernel here, he did so much for me and also for his own kernel! He
let me use everything he already did, I got so much stuff from his page and included it in my kernel. I'm so thankfull for all the support he gave to me! I know a thank you isn't enough, but I wanted to write it here.
- @googy_anas (again this great man!) and @kryten2k35 thank you so much for let me using your stweaks app! Great work you have done on thatone!
- @faux123 for all the great stuff he did for the kernels
- @Yank555
If you want to take my work and need it somewhere, or do other things with it, please ask me first for the permission. Otherwise you are not allowed to take it! Thank you !
XDA:DevDB Information
Stock Based Kernel for Tab S 10.5, Kernel for the Samsung Galaxy Tab S
Contributors
Tkkg1994, @googy_anas
Source Code: https://github.com/Tkkg1994/IronKernel
Kernel Special Features:
Version Information
Status: Stable
Current Stable Version: V2.5
Stable Release Date: 2015-10-13
Current Beta Version: 1.0
Beta Release Date: 2015-02-19
Created 2015-02-20
Last Updated 2015-10-12

Changelog:
Kitkat
IronKernel Beta V1.0 on 20.02.2015:
Initial release!
Ironkernel V1.1 26.02.2015:
-Temporarly removed Intelli-Plug
-Added voltcontroll for CPU
-Added Stweaks support and Stweaks app (all credits and stuff goes to @googy_anas and @Kryten2k35
-Hell lot of improvements
-Init.d support and busybox support
-GPU overclock to 733MHz
-CPU overclock to 2.1GHz (sorry, I couldn't get it stable )
-for more what I had done, visit here: Commits IronKernel
-Added fast charge support
IronKernel V1.2 01.03.2015:
- Built with latest toolchain (2015.02) by christopher83
- Use frandom from now
- Enable dynamic page writeback with earlysuspend
- Better battery charging control (kernel and stweaks)
- Auto install the right sTweaks version
- Reduce overestimating rq->avg_idle
- Optimize find_busiest_queue()
- Some CPUfreq optimizations
- Dynamic sync control with earlysuspend support
- Lowmemorykiller: implement task's adj rbtree
- Check free memory when tasks switch to background
- Dynamic FSync
- SOO Much more but I don't remember all
- After flashing the kernel, it will be successfull, but then show an error (becaus of mounting partition) don't worry, just reboot. Just ignore it
Changelog V1.3.5 08.03.15:
- Prerelease of V1.3 was on the ironrom
- Script auto-removes all knox containors/apps
- cpufreq: Retain only online cpus in managed_policy->cpus
- cpufreq: make the "scaling_cur_freq" sysfs entry pollable
- cpufreq: Make the "scaling_governor" sysfs node pollable
- cpufreq: Save and restore min and max frequencies
- fix some missing stuff with default governor
- cpufreq: Notify governors when cpus are hot-[un]plugged
- Updated nightmare and zzmoove governors
- net: ipv6: Add a sysctl to make optimistic addresses useful candidates
- fs/proc/task_mmu.c: add user-space support for resetting mm
- net: ipv6: allow choosing optimistic addresses with use_optimistic
- sched/idle: Avoid spurious wakeup IPIs
- cpufreq: Return directly in __cpufreq_get if policy is NULL
- new relation between governors
- ARM: 8226/1: cacheflush: get rid of restarting block
Changelog V1.4 23.03.15:
- It is simply to much to write everything here.. what I did
- Wolfson Control for the sound on our Tab S
- Added voltage control (doesen't work 100%)
- sched: Add an rq migration call-back to sched_class
- sched: Account for blocked load waking back up …
- sched: Normalize tg load contributions against runnable time
- sched: Refactor update_shares_cpu() -> update_blocked_avgs()
- sched/fair: Set se->vruntime directly in place_entity()
- sched: provide per cpu-cgroup option to notify on migrations
- sched: Make sure to not re-read variables after validation
- sched: Add WAKEUP_PREEMPTION feature flag, on by default
And this goes on for like 2 or 3 pages lol So the changelog is tooooooo long.
Lollipop
Changelog V2.0 10.04.15:
- Full lollipop compatible! (not with kitkat anymore!)
- Support CIFS
- Overclock to 2.0 GHz (other will be back soon)
- Include all features of all previous releases! Such as stweask, overclocked gpu etc.
- Based on latest samsung opensource T800XXU1BOCC
Was a lot of work to port all to Lollipop
If you got problems with sTweaks showing "loaded", but nothing happen, go to a root explorer, navigate to system/xbin, copy Busybox and past it in /sbin direction!
Changelog V2.1 16.05.15:
- Fix stweaks problems
- Voltage is still NOT working
- add tripndroid scheduler
- add row scheduler
- add and enable UKSM (ultra kernel samepage merging)
- update ramdisk to latest versions
- f2fs
- update linux to 3.4.107
- more stuff I may forgot
Changelog V2.2 08.07.15:
- Update to latest linux mainstream (3.4.108)
- Updated ramdisk source to OE3
- New source patches from official kernel opensource center (samsung)
- this does only work on the newer bases, as BOE3, the old ones will get a bootloop!
Changelog V2.2.5 16.07.15:
- Fixed "slow" charging (Thanks to AndreiLux and UpInTheAir!)
- Incrased sound so it will be a louder by default
- Some other small ramdisk fixes
Changelog V2.3 08.09.15:
- Kernel Rebased on latest OG2 kernel source
- Fix some heating issues that where reported
- Ramdisk update to OG2
- Fully support f2fs in /data and /cache
- Build with latest 4.9.4 toolchain
Changelog V2.4 05.10.15:
- Update to 5.2 toolchain compiled by myself!
- updated to 3.4.109 linux
- ftrace: Make all inline tags also include notrace
- compiler-gcc4.h: correct verion check for __compiletime_error
- compiler.h: add __visible
- compiler{,-gcc4}.h, bug.h: Remove duplicate macros
- some more optimisations concerning compiler
- msm: cpufreq: Only apply driver limits for scaling_min/max_freq writes
- drivers: cpufreq: Send a uevent when governor changes
- cpufreq: Save user policy min/max instead of policy min/max during hotplug
- cpufreq: Fix broken uevents for cpufreq governor and cpu devices
- cpufreq: Always allow update of user policy
- drivers: cpufreq: Upstream optimizations
- cpufreq: Export user_policy min/max
- cpufreq: Add policy notifiers
- cpufreq: Simplify cpufreq_add_dev()
- some more cpufreq things that I made
- cpufreq_stats: do not remove sysfs files if frequency table is not present
- sched/numa: Rewrite the CONFIG_NUMA sched domain support
- sched/numa: Fix the new NUMA topology bits
- sched/numa: Don't scale the imbalance
- sched/debug: Fix printing large integers on 32-bit platforms
- sched: Remove stale power aware scheduling remnants and dysfunctional knobs
- f2fs: update to latest version
- tima debug log disabled
- uksm: disabled by default
Changelog V2.5 13.10.15:
- enabled tima debug again
- fixed some Random reboots people had
- added pegasusq cpugovernor
- arm/crypto: Add optimized AES and SHA1 routines
- added cifs, nfs, exportfs, cdrom, all ramdisk support (joystick too)
- ARM: 7626/1: arm/crypto: Make asm SHA-1 and AES code Thumb-2 compatible
- ARM: 7723/1: crypto: sha1-armv4-large.S: fix SP handling
- ARM: 8119/1: crypto: sha1: add ARM NEON implementation
- ARM: 8120/1: crypto: sha512: add ARM NEON implementation
- a lot of other crypto optimisations (like 10 patches)
- cpufreq: Move get_cpu_idle_time() to cpufreq.c
- workqueue: set delayed_work->timer function on initialization
- workqueue: don't use WQ_HIGHPRI for unbound workqueues
- workqueue: factor out worker_pool from global_cwq
- workqueue: use @pool instead of @gcwq or @Cpu where applicable
- workqueue: separate out worker_pool flags
- workqueue: introduce NR_WORKER_POOLS and for_each_worker_pool()
- workqueue: reimplement WQ_HIGHPRI using a separate worker_pool
- hashtable: introduce a small and naive hashtable
- workqueue: use new hashtable implementation
- workqueue: drop @bind from create_worker()
- much more workqueue updates, to see them all, please visit here: Github Kernel Updates

Governors and I/O Scheduler:
Original Thread: Governor Explained, all credits go to @stempox
1: OnDemand
2: OndemandX
3: Performance
4: Powersave
5: Conservative
6: Userspace
7: Min Max
8: Interactive
9: InteractiveX
10: Smartass
11: SmartassV2
12: Scary
13: Lagfree
14: Smoothass
15: Brazilianwax
16: SavagedZen
17: Lazy
18: Lionheart
19: LionheartX
20: Intellidemand
21: Hotplug
22: BadAss
23: Wheatley
24: Lulzactive
25: Pegasusq/Pegasusd
26: hotplugx
27: AbissPlug
28: MSM DCVS
29: IntelliActive
30: Adaptive
31: Nightmare
32: ZZmove
1: OnDemand Governor:
This governor has a hair trigger for boosting clockspeed to the maximum speed set by the user. If the CPU load placed by the user abates, the OnDemand governor will slowly step back down through the kernel's frequency steppings until it settles at the lowest possible frequency, or the user executes another task to demand a ramp.
OnDemand has excellent interface fluidity because of its high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand is commonly chosen by smartphone manufacturers because it is well-tested, reliable, and virtually guarantees the smoothest possible performance for the phone. This is so because users are vastly more likely to ***** about performance than they are the few hours of extra battery life another governor could have granted them.
This final fact is important to know before you read about the Interactive governor: OnDemand scales its clockspeed in a work queue context. In other words, once the task that triggered the clockspeed ramp is finished, OnDemand will attempt to move the clockspeed back to minimum. If the user executes another task that triggers OnDemand's ramp, the clockspeed will bounce from minimum to maximum. This can happen especially frequently if the user is multi-tasking. This, too, has negative implications for battery life.
2: OndemandX:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
3: Performance Governor:
This locks the phone's CPU at maximum frequency. While this may sound like an ugly idea, there is growing evidence to suggest that running a phone at its maximum frequency at all times will allow a faster race-to-idle. Race-to-idle is the process by which a phone completes a given task, such as syncing email, and returns the CPU to the extremely efficient low-power state. This still requires extensive testing, and a kernel that properly implements a given CPU's C-states (low power states).
4: Powersave Governor:
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
5:Conservative Governor:
This biases the phone to prefer the lowest possible clockspeed as often as possible. In other words, a larger and more persistent load must be placed on the CPU before the conservative governor will be prompted to raise the CPU clockspeed. Depending on how the developer has implemented this governor, and the minimum clockspeed chosen by the user, the conservative governor can introduce choppy performance. On the other hand, it can be good for battery life.
The Conservative Governor is also frequently described as a "slow OnDemand," if that helps to give you a more complete picture of its functionality.
6: Userspace Governor:
This governor, exceptionally rare for the world of mobile devices, allows any program executed by the user to set the CPU's operating frequency. This governor is more common amongst servers or desktop PCs where an application (like a power profile app) needs privileges to set the CPU clockspeed.
7: Min Max
well this governor makes use of only min & maximum frequency based on workload... no intermediate frequencies are used.
8: Interactive Governor:
Much like the OnDemand governor, the Interactive governor dynamically scales CPU clockspeed in response to the workload placed on the CPU by the user. This is where the similarities end. Interactive is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Unlike OnDemand, which you'll recall scales clockspeed in the context of a work queue, Interactive scales the clockspeed over the course of a timer set arbitrarily by the kernel developer. In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. This can eliminate the frequency bouncing discussed in the OnDemand section. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. This is another pro-battery life benefit of Interactive.
However, because Interactive is permitted to spend more time at maximum frequency than OnDemand (for device performance reasons), the battery-saving benefits discussed above are effectively negated. Long story short, Interactive offers better performance than OnDemand (some say the best performance of any governor) and negligibly different battery life.
Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.
9: InteractiveX Governor:
Created by kernel developer "Imoseyon," the InteractiveX governor is based heavily on the Interactive governor, enhanced with tuned timer parameters to better balance battery vs. performance. The InteractiveX governor's defining feature, however, is that it locks the CPU frequency to the user's lowest defined speed when the screen is off.
10: Smartass
Is based on the concept of the interactive governor.
I have always agreed that in theory the way interactive works – by taking over the idle loop – is very attractive. I have never managed to tweak it so it would behave decently in real life. Smartass is a complete rewrite of the code plus more. I think its a success. Performance is on par with the “old” minmax and I think smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Smartass will also cap the max frequency when sleeping to 352Mhz (or if your min frequency is higher than 352 – why?! – it will cap it to your min frequency). Lets take for example the 528/176 kernel, it will sleep at 352/176. No need for sleep profiles any more!"
11: SmartassV2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery.
12: Scary
A new governor wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It will give the same performance as conservative right now, it will get tweaked over time.
13: Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.
14: Smoothass:
The same as the Smartass “governor” But MUCH more aggressive & across the board this one has a better battery life that is about a third better than stock KERNEL
15: Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery
16: SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
17: Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.
18: Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source.
The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
19: LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
20: Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors)
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
21: Hotplug Governor:
The Hotplug governor performs very similarly to the OnDemand governor, with the added benefit of being more precise about how it steps down through the kernel's frequency table as the governor measures the user's CPU load. However, the Hotplug governor's defining feature is its ability to turn unused CPU cores off during periods of low CPU utilization. This is known as "hotplugging."
22: BadAss Governor:
Badass removes all of this "fast peaking" to the max frequency. On a typical system the cpu won't go above 918Mhz and therefore stay cool and will use less power. To trigger a frequency increase, the system must run a bit @ 918Mhz with high load, then the frequency is bumped to 1188Mhz. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 1-2 seconds, depending on the load your system is experiencing)
Badass will also take the gpu load into consideration. If the gpu is moderately busy it will bypass the above check and clock the cpu with 1188Mhz. If the gpu is crushed under load, badass will lift the restrictions to the cpu.
23: Wheatley:
Building on the classic 'ondemand' governor is implemented Wheatley governor. The governor has two additional parameters:
target_residency - The minimum average residency in µs which is considered acceptable for a proper efficient usage of the C4 state. Default is 10000 = 10ms.
allowed_misses - The number sampling intervals in a row the average residency is allowed to be lower than target_residency before the governor reduces the frequency. This ensures that the governor is not too aggressive in scaling down the frequency and reduces it just because some background process was temporarily causing a larger number of wakeups. The default is 5.
Wheatley works as planned and does not hinder the proper C4 usage for task where the C4 can be used properly .
For internet browsing the time spend in C4 has increased by 10% points and the average residency has increased by about 1ms. I guess these differences are mostly due to the different browsing behaviour (I spend the last time more multi-tabbing). But at least we can say that Wheatley does not interfere with the proper use of the C4 state during 'light' tasks. For music playback with screen off the time spend in C4 is practically unchanged, however the average residency is reduced from around 30ms to around 18ms, but this is still more than acceptable.
So the results show that Wheatley works as intended and ensures that the C4 state is used whenever the task allows a proper efficient usage of the C4 state. For more demanding tasks which cause a large number of wakeups and prevent the efficient usage of the C4 state, the governor resorts to the next best power saving mechanism and scales down the frequency. So with the new highly-flexible Wheatley governor one can have the best of both worlds.
Obviously, this governor is only available on multi-core devices.
24: Lulzactive:
Lulzactive:
This new find from Tegrak is based on Interactive & Smartass governors and is one of the favorites.
Old Version: When workload is greater than or equal to 60%, the governor scales up CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step. When screen is off, frequency is locked to global scaling minimum frequency.
New Version: Three more user configurable parameters: inc_cpu_load, pump_up_step, pump_down_step. Unlike older version, this one gives more control for the user. We can set the threshold at which governor decides to scale up/down. We can also set number of frequency steps to be skipped while polling up and down.
When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. When workload is less than inc_cpu_load, governor scales CPU down pump_down_step steps down.
Example:
Consider
inc_cpu_load=70
pump_up_step=2
pump_down_step=1
If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800.
If current frequency =1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.
25: Pegasusq/Pegasusd
The Pegasus-q / d is a multi-core based on the Ondemand governor and governor with integrated hot-plugging.
Ongoing processes in the queue, we know that multiple processes can run simultaneously on. These processes are active in an array, which is a field called "Run Queue" queue that is ongoing, with their priority values arranged (priority will be used by the task scheduler, which then decides which process to run next).
To ensure that each process has its fair share of resources, each running for a certain period and will eventually stop and then again placed in the queue until it is your turn again. If a program is terminated, so that others can run the program with the highest priority in the current queue is executed.
26: hotplugx
It 'a Hotplug modified and optimized for the suspension in off-screen
27: AbissPlug
It 'a Governor derived hotplug, it works the same way, but with the changes in savings for a better battery.
28: MSM DCVS
a very efficient and wide range of Dynamic Clock and
Voltage Scaling (DCVS) which addresses usage models from
active standby to mid and high level processing requirements.
A Krait CPU can smoothly scale from low power, low
leakage mode to blazingly fast performance.
Believe it's a governor that is mfg'd by qualcomm to utilize new on chip features.
MSM is the prefix for the SOC (MSM8960) and DCVS is Dynamic Clock and Voltage Scaling. Makes sense, MSM-DCVS
29: IntelliActive
Based off Google's Interactive governor with the following enhancements:
1. self-boost capability from input drivers (no need for PowerHAL assist)
2. two phase scheduling (idle/busy phases to prevent from jumping directly to max freq
3. Checks for offline cpus and short circuits some unnecessary checks to improve code execution paths
30: Adaptive
This driver adds a dynamic cpufreq policy governor
designed for latency-sensitive workloads and also for demanding
performance.
This governor attempts to reduce the latency of clock
increases so that the system is more responsive to
interactive workloads in loweset steady-state but to
to reduce power consumption in middle operation level level up
will be done in step by step to prohibit system from going to
max operation level.
31: Nightmare
A PegasusQ modified, less aggressive and more stable. A good compromise between performance and battery.
In addition to the SoD is a prevention because it usually does not hotplug.
32: ZZmove
ZZmove Governor optimized for low power consumption with the screen off, with particular attention to the limitation of consumption applications in the background with the screen off, such as listening to music. It has three settings: battery saver, balanced and performance. In addition to a performance boost, there is also the governor zzmove optimized.
I/O Scheduler: Thread:I/O Scheduler explained
The Scheduler is an algorithm that, given a set of requests for access to a resource, establishing a temporal order for the execution of such requests, favoring those that meet certain criteria in order to optimize access to that resource.
The difference between the various scheduler is the focus on certain criteria rather than on others.
The choice of a given scheduler does not produce visible changes so as to the choice of the governor, but still provides some improvements.
As usual schedulers are personally tested to find one that best suits your needs.
Deadline
It aims to provide a deadline, a deadline for all requests in order to avoid undesirable phenomena such as the "starvation" or the eternal waiting for some requests that occurs when one or more background processes are left indefinitely in the queue the ready, because there is always at least one of the highest priority ready process.
V (r)
The next request is performed according to the distance from the last request. In the network running good opinions about this scheduler.
No-op
Push all requests in a single queue simply by their arrival order, grouping together those contiguous.
SIO
E 'the scheduler simpler, does not make any type of sort, is intended only for the purpose of obtaining a low-latency, ie to reduce the amount of time that elapses between the instant at which the request is generated and that in which the request is satisfied.
CFQ
Order requests of different processes in queues for each queue type and assigns a specific interval of time whose duration depends on the priorities assigned to processes. Can be considered the Ondemand the scheduler, the scheduler is in fact more balanced, doing its job in an honest manner.
BFQ
It 's based on CFQ but, instead of the intervals of time, assigns a part of the bandwidth of the disc to each process running in a proportional manner.
Anticipatory
Order requests based on criteria predictive, that puts the demands paused for a short period of time in anticipation that more of this to come to aggregate them.
ADAPTIVE ANTICIPATORY SCHEDULER
For the anticipatory scheduler, we scale up the anticipation timeout (antic expire) using the latency scaling factor over time. When the virtual disk latencies are low a small scaling of the timeout is sucient to prevent deceptive idleness, whereas when the latencies are high a larger scaling of the timeout value may be required to achieve the same. Note that such dynamic setting of the timeout value ensures that we attain a good trade-o between throughput (lost due to idling) and deceptive idleness mitigation. Setting a high value for the scaling factor (increasing idling time) only happens when the disk service latencies themselves are higher. This may not necessarily cause a signicant loss in throughput, because submitting a request from another process instead of idling is not going to improve throughput if the virtual disk itself does not get any faster than it is at the current period. A higher anticipation timeout might also be capable of absorbing process scheduling eects inside the VM. The results for the adaptive anticipatory scheduler are shown in Figure 2. The read time with our modied implementation (third bar in the dierent scheduler combinations) shows that it is possible to mitigate the eects of deceptive idleness by adapting the timeout. An interesting related observation is that the level to which the improve- ment is possible varies for dierent Domain-0 schedulers; noop - 39%, anticipatory - 67% and cfq - 36%. This again points to the fact that the I/O scheduler used in Domain-0 is important for the VM's ability in enforcing I/O scheduling guarantees. Dierent Domain-0 I/O schedulers likely have a dierent service latency footprint inside the VMs, contributing to dierent levels of improvement.
ROW
Row stands for READ Over WRITE which is the main requests dispatch policy of this algorithm. The ROW IO scheduler was developed with the mobile devices needs in mind. In mobile devices we favor user experience upon everything else, thus we want to give READ IO requests as much priority as possible. In mobile devices we won't have as much parallel threads as on desktops. Usually it's a single thread or at most 2 simultaneous working threads for read & write. Favoring READ requests over WRITEs decreases the READ latency greatly.
The main idea of the ROW scheduling policy is: If there are READ requests in pipe - dispatch them but don't starve the WRITE requests too much. Bellow you'll find a small comparison of ROW to existing schedulers. The test that was run for these measurements is parallel read and write.
FIOS
Flash-based solid-state drives (SSDs) have the potential to eliminate the I/O bottlenecks in data-intensive applications However the large performance discrepancy between Flash reads and writes introduces challenges for fair resource usage. Further, existing fair queuing and quanta-based I/O schedulers poorly manage the I/O anticipation for Flash I/O fairness and efficiency. Some also suppress the I/O parallelism which causes substantial performance degradation on Flash. This paper develops FIOS, a new Flash I/O scheduler that attains fairness and high efficiency at the same time. FIOS employs a fair I/O time-slice management with mechanisms for read preference, parallelism, and fairness-oriented I/O anticipation. Evaluation demonstrates that FIOS achieves substantially better fairness and efficiency compared to the Linux CFQ scheduler, the SFQ(D) fair queuing scheduler, and the Argon quanta-based scheduler on several Flash-based storage devices (including a CompactFlash card in a low-power wimpy node). In particular, FIOS reduces the worst-case slowdown bya factor of 2.3 or more when the read-only SPECweb workload runs together with the write-intensive TPC

Sweet! In terms of battery life, did it improve for you? You made one of the best TW roms and now this great job!

DUHAsianSKILLZ said:
Sweet! In terms of battery life, did it improve for you? You made one of the best TW roms and now this great job!
Click to expand...
Click to collapse
Thank you! I think we have less devs here in Tab S section, so I have to do something here
I couldn't test the batterylife till now, I was testing whole 2 weeks to get the kernel working (got holidays) So I will report you back!
Intelli-Plug speeks for better batterylife, it shuts down 3 cores if they are not needed (screen off = only 1 core working with 200Mhz or something)

Tkkg1994 said:
Thank you! I think we have less devs here in Tab S section, so I have to do something here
I couldn't test the batterylife till now, I was testing whole 2 weeks to get the kernel working (got holidays) So I will report you back!
Intelli-Plug speeks for better batterylife, it shuts down 3 cores if they are not needed (screen off = only 1 core working with 200Mhz or something)
Click to expand...
Click to collapse
Thanks! Ill downgrade tommrow or so back to kitkat and try xnote rom. I can try your kernel when I do that.

DUHAsianSKILLZ said:
Thanks! Ill downgrade tommrow or so back to kitkat and try xnote rom. I can try your kernel when I do that.
Click to expand...
Click to collapse
Always a pleasure to have you as a user!
Not the ironrom

Wrong thread

Mokum020 said:
Thank you for your great work (again)!
Your kernel is running perfect here on T805 with X-Note.
would love to be able to try 2.1/2.2Ghz, 2.1Ghz is no problem for my Tab S with SkyHigh.
View attachment 3174370View attachment 3174371
Click to expand...
Click to collapse
I always make kind of a "stresstest" for the CPU freq. I set min freq to 2.1GHz and max freq to 2.1GHz. Than see what happen. I couldn't get it stable enough for daily use, but if I can, I will enable 2.1GHz for sure

Confirmed working on the T800 with xnote rom.

DUHAsianSKILLZ said:
Confirmed working on the T800 with xnote rom.
Click to expand...
Click to collapse
Thank you for testing
I added a description of governors and I/O schedulers above

To install this with Ironrom, should I do anything with Synapse first to either return settings to default or uninstall? Or should I reflash IronRom, leaving out Synapse in Aroma and then flash the new kernel? I plan on trying Kernel Auditor.
Also, will you be adding this kernel to the aroma options soon (or are you waiting for more testing to come in)?

Hookmt said:
To install this with Ironrom, should I do anything with Synapse first to either return settings to default or uninstall? Or should I reflash IronRom, leaving out Synapse in Aroma and then flash the new kernel? I plan on trying Kernel Auditor.
Also, will you be adding this kernel to the aroma options soon (or are you waiting for more testing to come in)?
Click to expand...
Click to collapse
The kernel doesn' support synapse. You can just uninstall it if you like to and than install your kernel auditor.
Yes it will come to aroma soon, I'm waiting for samsung to release a new base for T800
And yes, testing is always welcome

Can you include some tips for let's say performance settings, battery settings, both battery and performance settings etc. I'm still testing a few things too, but can't figure out the best battery settings in faux.

DUHAsianSKILLZ said:
Can you include some tips for let's say performance settings, battery settings, both battery and performance settings etc. I'm still testing a few things too, but can't figure out the best battery settings in faux.
Click to expand...
Click to collapse
Intelli-plug, KSM enabled, Governor... I would say intellimm is good for battery but a bit slow. Interactive with intelliplug is nice

With Stweaks Support does the Kernel support BLN (blinking Soft Keys)? God, this would be awesome!!
If not, could you create a Custom Kernel with this Feature?

haselchen said:
With Stweaks Support does the Kernel support BLN (blinking Soft Keys)? God, this would be awesome!!
If not, could you create a Custom Kernel with this Feature?
Click to expand...
Click to collapse
If you would have read correctly, you will see that I'm currently adding sTweaks support. And it don't supports it now, but seems like a good idea!

Please realize this idea

Tkkg1994, this is what I call a very promising start.
Detailed walkthrough, FAQ style, and a very interesting feature rich kernel... I'm on CM12 right now, but already eager to try this in the coming days with IronRom, of course.
A Big Thanks from the other side of the world... Porto, Portugal.

Tkkg1994 said:
Intelli-plug, KSM enabled, Governor... I would say intellimm is good for battery but a bit slow. Interactive with intelliplug is nice
Click to expand...
Click to collapse
IntellIplug is nice but sometimes you cant turn the tablet on when it's enabled. I even set the screen off frequency to something above 200mhz. I had to force reboot a couple times. Did you managed to get it work? I even tryed all the profiles including balanced etc and also changing the governer. For now I'll keep it off but battery seems good so far!

[KERNEL][TW/LP][13.10.15][SM-T700][SM-T705] IronKernel V2.5 STweaks

Hey guys, I'm back with a new KERNEL for both Variants of the Tab S 8.4 (T700 and T705)!
Some guys probably know me from the IronRom . I decided myselfe to create a custom kernel for our really great Tab s 8.4, I'm getting better and better at this stuff, I don't thought that
It is basically the normal kernel with some modifications for better performance and hopefully also batterylife. It is for the stock kitkat (4.4.2) touchwiz and not for cyanogenmod or something else.
I excuse all devs here visiting my github page, it is such a mess (with the commits)! I know it, but I'm doing this the first time, so hopefully you will forgive me.
The kernel is pretty stable, I just call it a beta version, because I can't test the T700 and T705 version, so if with thisone also all works great -> stable
IF YOU FOLLOW MY STEPS BELOW, YOU WILL MAY LOSE YOUR WARRANTY, KNOX WILL DISPLAY 0x1! I'M NOT RESPONSIBLE FOR ANY DAMAGED DEVICE!
You can try to use the kernel adiutor app, or just the preinstalled sTweaks, but not both at the same time! This will cause problems.
Features of my Kernel::- Built with latest Linaro Toolchain 4.9.3 made by christopher83
- Latest Kernel version 3.4.109, includes all important linux patches, patched it form 3.4.39 up to 3.4.109 (was a lot of work)
- Choose between different CPU governors: Interactive (default), Powersave, Performance, Userspace, Conservative, Intellidemand, Intelliactive, Ondemand, Adaptive, Abyssplug, AbyssplugV2, Badass, DanceDance, ZZmove, Nightmare, Wheatley, Lionheart, Darkness, PegasusQ and Intellimm
- Built with latest ramdisk sources from samsung
- Kernelsource from T805XXU1BOG2
- Underclock to 200MHz and Overclock to 2.0GHz
- GPU works from 100MHz to 733MHz (default)
- I/O schedulers: ROW (Default), CFQ, No-op, Deadline, Test, BFQ, FIOPS, SIO, VR, ZEN, FIFO and SIOplus
- Readahead can be set
- KSM (Kernel Samepage Merging)
- Gentlefairsleeper and ARCH power
- Android Logger
- Init.d Support
- data and cache f2fs support!
- Busybox support
- Full STweaks support
- Charging Control
- Cpufreq voltcontrol
- ZRam and Swap
- Allow ADB-Insecure
- Low Memory Kill
- TCP (Network) control: Cubic (default), Reno, Bic, Westwood, Highspeed, Hybla, HTCP, Vegas, Veno, Scalable, LP, Yeah and Illinois
- SeLinux is set to permissive
- Compiled as small as it could be (just around 6MB)
Download:In the second post
Googy-Max STweaks
Bugs/Problems:-sTweaks can't enable the right GPU over and underclock freqency
-Some other stweaks stuff, you will see
-Didn't tried the voltage table
Instructions:
If you want to install the Kernel, follow this:
1. Install a custom recovery for your tablet, like this one here: TWRP Recovery
2. Follow the instructions on the page above, until you get a working recovery
3. Download the Kernel from below and copy it to your external SD Card
4. Reboot to your recovery by pressing volume up, home button and power button at the same time.
5. Install zip, and select the kernel
6. Wipe cache and dalvik cache (recommand)
7. Reboot
Support:If you like my work, please hit a thanks down on my posts. A thanks is enough!:highfive: If you really really really really really like my work, you can donate something to me, but it is not necessary. I created a paypal account, just in case, someone would give me a small donation. :good:
As I said, you don't have to give me something, but this keeps me motivated to built better roms and keep updating everything. It's your choice, and I'm very thankfull for every donation! No matter how big it is! Thank you so much for supporting me, cheers and have a nice day :fingers-crossed:
Donators for the Kernel:
Credits/Thanks:- Samsung for sources
- @Christopher83 for the compiler
- @UpInTheAir for the work he already did in his own kernel (could use some of his commits on github (opensource) and see what he did when I didn't know what I did wrong). He also inspired me to work on my own stuff and kernel, thank you very much!
- @googy_anas, without him, I would not have a working kernel here, he did so much for me and also for his own kernel! He
let me use everything he already did, I got so much stuff from his page and included it in my kernel. I'm so thankfull for all the support he gave to me! I know a thank you isn't enough, but I wanted to write it here.
- @googy_anas (again ) and @kryten2k35 for the great stweaks app and that I can use your modification in the app (I don't edited it) Thank you so much!
- @faux123 for all the great stuff he did for the kernels
- @Yank555
- @AndreiLux
- @Halaszk87
If you want to take my work and need it somewhere, or do other things with it, please ask me first for the permission. Otherwise you are not allowed to take it! Thank you !
XDA:DevDB Information
Stock Based Kernel for Tab S 8.4, Kernel for the Samsung Galaxy Tab S
Contributors
Tkkg1994, @googy_anas
Source Code: https://github.com/Tkkg1994/IronKernel
Kernel Special Features:
Version Information
Status: Stable
Current Stable Version: V2.5
Stable Release Date: 2015-10-13
Current Beta Version: 1.0
Beta Release Date: 2015-02-20
Created 2015-02-20
Last Updated 2015-10-12

Changelog:
Kitkat
Ironkernel Beta V1.0 20.02.2015:
- Initial Release!
Ironkernel V1.1 26.02.2015:
-Temporarly removed Intelli-Plug
-Added voltcontroll for CPU
-Added Stweaks support and Stweaks app (all credits and stuff goes to @googy_anas and @Kryten2k35
-Hell lot of improvements
-Init.d support and busybox support
-GPU overclock to 733MHz
-CPU overclock to 2.1GHz (sorry, I couldn't get it stable )
-Fast charge control
-for more what I had done, visit here: Commits IronKernel
IronKernel V1.2 01.03.2015:
- Built with latest toolchain (2015.02) by christopher83
- Use frandom from now
- Enable dynamic page writeback with earlysuspend
- Better battery charging control (kernel and stweaks)
- Auto install the right sTweaks version
- Reduce overestimating rq->avg_idle
- Optimize find_busiest_queue()
- Some CPUfreq optimizations
- Dynamic sync control with earlysuspend support
- Lowmemorykiller: implement task's adj rbtree
- Check free memory when tasks switch to background
- Dynamic FSync
- SOO Much more but I don't remember all
- After flashing the kernel, it will be successfull, but then show an error (becaus of mounting partition) don't worry, just reboot. Just ignore it
Changelog V1.3.5 08.03.15:
- Prerelease of V1.3 was on the ironrom
- Script auto-removes all knox containors/apps
- cpufreq: Retain only online cpus in managed_policy->cpus
- cpufreq: make the "scaling_cur_freq" sysfs entry pollable
- cpufreq: Make the "scaling_governor" sysfs node pollable
- cpufreq: Save and restore min and max frequencies
- fix some missing stuff with default governor
- cpufreq: Notify governors when cpus are hot-[un]plugged
- Updated nightmare and zzmoove governors
- net: ipv6: Add a sysctl to make optimistic addresses useful candidates
- fs/proc/task_mmu.c: add user-space support for resetting mm
- net: ipv6: allow choosing optimistic addresses with use_optimistic
- sched/idle: Avoid spurious wakeup IPIs
- cpufreq: Return directly in __cpufreq_get if policy is NULL
- new relation between governors
- ARM: 8226/1: cacheflush: get rid of restarting block
Changelog V1.4 23.03.15:
- It is simply to much to write everything here.. what I did
- Wolfson Control for the sound on our Tab S
- Added voltage control (doesen't work 100%)
- sched: Add an rq migration call-back to sched_class
- sched: Account for blocked load waking back up …
- sched: Normalize tg load contributions against runnable time
- sched: Refactor update_shares_cpu() -> update_blocked_avgs()
- sched/fair: Set se->vruntime directly in place_entity()
- sched: provide per cpu-cgroup option to notify on migrations
- sched: Make sure to not re-read variables after validation
- sched: Add WAKEUP_PREEMPTION feature flag, on by default
And this goes on for like 2 or 3 pages lol So the changelog is tooooooo long.
Lollipop
Changelog V2.0 08.07.15:
- @Richcar confirmed that it works (trust him )
- updated to linux 3.4.108 mainstream
- f2fs update
- add tripndroid scheduler
- add row scheduler
- add and enable UKSM (ultra kernel samepage merging)
- update ramdisk to latest versions
- more things I may forgot
- ONLY for touchwiz lollipop! You MUST have a EO3 base or higher (your rom)
Changelog V2.0.5 16.07.15:
- Fixed "slow" charging (Thanks to AndreiLux and UpInTheAir!)
- Incrased sound so it will be a louder by default
- Some other small ramdisk fixes
- Update to OF1 and OF2 ramdisk
- You have to be on latest samsung based roms (as OEx or OFx) otherwise not booting!
Changelog V2.5 13.10.15:
- Merged latest OG2 source, adapted by OE9 source from T705, fully rebased kernel!
- Update to 5.2 toolchain compiled by myself!
- this kernel is now up-to-date with T800/T805 kernel!
- updated to 3.4.109 linux
- ftrace: Make all inline tags also include notrace
- compiler-gcc4.h: correct verion check for __compiletime_error
- compiler.h: add __visible
- compiler{,-gcc4}.h, bug.h: Remove duplicate macros
- some more optimisations concerning compiler
- msm: cpufreq: Only apply driver limits for scaling_min/max_freq writes
- drivers: cpufreq: Send a uevent when governor changes
- cpufreq: Save user policy min/max instead of policy min/max during hotplug
- cpufreq: Fix broken uevents for cpufreq governor and cpu devices
- cpufreq: Always allow update of user policy
- drivers: cpufreq: Upstream optimizations
- cpufreq: Export user_policy min/max
- cpufreq: Add policy notifiers
- cpufreq: Simplify cpufreq_add_dev()
- some more cpufreq things that I made
- cpufreq_stats: do not remove sysfs files if frequency table is not present
- sched/numa: Rewrite the CONFIG_NUMA sched domain support
- sched/numa: Fix the new NUMA topology bits
- sched/numa: Don't scale the imbalance
- sched/debug: Fix printing large integers on 32-bit platforms
- sched: Remove stale power aware scheduling remnants and dysfunctional knobs
- f2fs: update to latest version
- uksm: disabled by default
- fixed some Random reboots people had
- added pegasusq cpugovernor
- arm/crypto: Add optimized AES and SHA1 routines
- added cifs, nfs, exportfs, cdrom, all ramdisk support (joystick too)
- ARM: 7626/1: arm/crypto: Make asm SHA-1 and AES code Thumb-2 compatible
- ARM: 7723/1: crypto: sha1-armv4-large.S: fix SP handling
- ARM: 8119/1: crypto: sha1: add ARM NEON implementation
- ARM: 8120/1: crypto: sha512: add ARM NEON implementation
- a lot of other crypto optimisations (like 10 patches)
- cpufreq: Move get_cpu_idle_time() to cpufreq.c
- workqueue: set delayed_work->timer function on initialization
- workqueue: don't use WQ_HIGHPRI for unbound workqueues
- workqueue: factor out worker_pool from global_cwq
- workqueue: use @pool instead of @gcwq or @Cpu where applicable
- workqueue: separate out worker_pool flags
- workqueue: introduce NR_WORKER_POOLS and for_each_worker_pool()
- workqueue: reimplement WQ_HIGHPRI using a separate worker_pool
- hashtable: introduce a small and naive hashtable
- workqueue: use new hashtable implementation
- workqueue: drop @bind from create_worker()
- much more workqueue updates, to see them all, please visit here: Github Kernel Updates

Can't wait to try this out on my t700

You might want to amend your OP. If you study the source code a little more and try understand things. You'll find there are no (actual) A7 100 MHz. A7 cores freq are doubled 100-650 (become 200-1300) MHz. A15 cores 800-1900+. Samsung have done it this way for IKS to work easily.
Some CPU control apps will just read the table but not able to differentiate between the A7 and A15 cores, and just display what's read from the frequency table.
You've made a good start, but 99% over those governors aren't suitable and/or optimized for Exynos. A "shotgun" approach isn't always the best way, but hey, this is your toy.

UpInTheAir said:
You might want to amend your OP. If you study the source code a little more and try understand things. You'll find there are no (actual) A7 100 MHz. A7 cores freq are doubled 100-650 (become 200-1300) MHz. A15 cores 800-1900+. Samsung have done it this way for IKS to work easily.
Some CPU control apps will just read the table but not able to differentiate between the A7 and A15 cores, and just display what's read from the frequency table.
You've made a good start, but 99% over those governors aren't suitable and/or optimized for Exynos. A "shotgun" approach isn't always the best way, but hey, this is your toy.
Click to expand...
Click to collapse
Now I understand that a little bit more. Because I added first a 100MHz support and added all stuff to get it work and than, it displayed me 50MHz and I thought, what the heck is going wrong here?
So I removed it again. Thank you for helping out here.
Suitable are they, but optimized not at the moment. You know, otherwise I wont have work left
And that's also why I call it a beta version at the moment.

Tkkg1994 said:
Now I understand that a little bit more. Because I added first a 100MHz support and added all stuff to get it work and than, it displayed me 50MHz and I thought, what the heck is going wrong here?
So I removed it again. Thank you for helping out here.
Suitable are they, but optimized not at the moment. You know, otherwise I wont have work left
And that's also why I call it a beta version at the moment.
Click to expand...
Click to collapse
No, a lot are not suitable, as they are written for krait SoC (4 main cores), just like intelli-plug etc. I found they were more of a hassle and eroded kernel stability, hence I never committed the changes for release. You might find otherwise, so no harm to try. Can be fun, and also a headache too
Snapdragon 810 will be using big.LITTLE architecture same as Exynos, so hopefully faux will port some of his work over. Although it will be HMP, maybe we can adapt to our IKS kernel.

UpInTheAir said:
No, a lot are not suitable, as they are written for krait SoC (4 main cores), just like intelli-plug etc. I found they were more of a hassle and eroded kernel stability, hence I never committed the changes for release. You might find otherwise, so no harm to try. Can be fun, and also a headache too
Snapdragon 810 will be using big.LITTLE architecture same as Exynos, so hopefully faux will port some of his work over. Although it will be HMP, maybe we can adapt to our IKS kernel.
Click to expand...
Click to collapse
Nobody says that we can't port it to 8 cores you know, it is a lot of work for sure, but not impossible.
I barely had problems with the governors, more with intelliplug.
But I think it is good that we don't have the same opinion.
Otherwise we would have 2 similar kernels here.

Tkkg1994 said:
Nobody says that we can't port it to 8 cores you know, it is a lot of work for sure, but not impossible.
I barely had problems with the governors, more with intelliplug.
But I think it is good that we don't have the same opinion.
Otherwise we would have 2 similar kernels here.
Click to expand...
Click to collapse
I don't think you understand me yet. We use IKS and 4 cores at once big.LITTLE . NOT HMP (all cores running). If you study the governors and what exactly the frequency/cores are actually doing in real time, you will find out and learn from it ... Just because something compiles and are able to switch between variables, does not make it compatible.
I never said or implied that anything was impossible, but you need to re-write (not adapt) a lot of code. In effect, create a "new" governor. This is fact, not my opinion
Best of luck with your project, keep at it !

UpInTheAir said:
I don't think you understand me yet. We use IKS and 4 cores at once big.LITTLE . NOT HMP (all cores running). If you study the governors and what exactly the frequency/cores are actually doing in real time, you will find out and learn from it ... Just because something compiles and are able to switch between variables, does not make it compatible.
I never said or implied that anything was impossible, but you need to re-write (not adapt) a lot of code. In effect, create a "new" governor. This is fact, not my opinion
Best of luck with your project, keep at it !
Click to expand...
Click to collapse
I read the wiki article
I think our Exynos5 5420 use HMP and can use all cores together if it uses it?
I was talking about the intelli-plug stuff not the governors. I hope samsung will release a S6 with exynos (only) and than we will get more support.
If you want to talk with me (and yes I like to) than PM?

Tkkg1994 said:
I read the wiki article
I think our Exynos5 5420 use HMP and can use all cores together if it uses it?
I was talking about the intelli-plug stuff not the governors. I hope samsung will release a S6 with exynos (only) and than we will get more support.
If you want to talk with me (and yes I like to) than PM?
Click to expand...
Click to collapse
Keep reading and learning Particularly what IKS is and does. Please don't take this the wrong way, this is relevant and you really need to learn how the basics of our 5420 kernel actually work.
There have been test HMP for Exynos 5420, BUT, no Android powered Exynos 5420 is ever capable of HMP. AndreiLux has explained why in various posts.
HMP kernels (such as I'm using with my Note Edge Skyhigh kernel) is completely different, but some things might be adapted with little work.
I just don't have the time to answer or clarify every single question (I don't pretend to always know), even by PM. It's just a matter of reading, learning, and trial by many errors.

UpInTheAir said:
Keep reading and learning Particularly what IKS is and does. Please don't take this the wrong way, this is relevant and you really need to learn how the basics of our 5420 kernel actually work.
There have been test HMP for Exynos 5420, BUT, no Android powered Exynos 5420 is ever capable of HMP. AndreiLux has explained why in various posts.
HMP kernels (such as I'm using with my Note Edge Skyhigh kernel) is completely different, but some things might be adapted with little work.
I just don't have the time to answer or clarify every single question (I don't pretend to always know), even by PM. It's just a matter of reading, learning, and trial by many errors.
Click to expand...
Click to collapse
I'm doing this the first time, so hopefully you and the others will understand that. I hope you can excuse me I have to learn many things I know that.
See you soon!

Changelog V1.1:
-Temporarly removed Intelli-Plug
-Added voltcontroll for CPU
-Added Stweaks support and Stweaks app (all credits and stuff goes to @googy_anas and @Kryten2k35
-Hell lot of improvements
-GPU overclock to 733MHz
-CPU overclock to 2.1GHz (sorry, I couldn't get it stable )
-for more what I had done, visit here: Commits IronKernel

Tkkg1994 said:
-Temporarly removed Intelli-Plug
-Added voltcontroll for CPU
-Added Stweaks support and Stweaks app (all credits and stuff goes to @googy_anas and @Kryten2k35
-Hell lot of improvements
-GPU overclock to 733MHz
-CPU overclock to 2.1GHz (sorry, I couldn't get it stable )
-for more what I had done, visit here: Commits IronKernel
Click to expand...
Click to collapse
Kernel update is awesome I love the GPU OC seems stable also went to 2GHZ CPU OC no issues I would go to 2.1GHZ but I think it may get unstable
TAPATALKED WITH MY XPE R IA Z
My Z3 app Ports to all devices

danny19901 said:
Kernel update is awesome I love the GPU OC seems stable also went to 2GHZ CPU OC no issues I would go to 2.1GHZ but I think it may get unstable
TAPATALKED WITH MY XPE R IA Z
My Z3 app Ports to all devices
Click to expand...
Click to collapse
Better let it at 2.0 GHz. Best for stability! Great you enjoy it

danny19901 said:
Kernel update is awesome I love the GPU OC seems stable also went to 2GHZ CPU OC no issues I would go to 2.1GHZ but I think it may get unstable
TAPATALKED WITH MY XPE R IA Z
My Z3 app Ports to all devices
Click to expand...
Click to collapse
N/A

fishdrop said:
N/A
Click to expand...
Click to collapse
Just putting N/A doesn't help much if you need help or something

New changelog:
IronKernel V1.2 01.03.2015:
- Built with latest toolchain (2015.02) by christopher83
- Use frandom from now
- Enable dynamic page writeback with earlysuspend
- Better battery charging control (kernel and stweaks)
- Auto install the right sTweaks version
- Reduce overestimating rq->avg_idle
- Optimize find_busiest_queue()
- Some CPUfreq optimizations
- Dynamic sync control with earlysuspend support
- Lowmemorykiller: implement task's adj rbtree
- Check free memory when tasks switch to background
- Dynamic FSync
- SOO Much more but I don't remember all
- After flashing the kernel, it will be successfull, but then show an error (becaus of mounting partition) don't worry, just reboot. Just ignore it

THANKYOU !!! Why is it that most other developers can't use common sense and say right up front that their work will kill Knox.

hillg001 said:
THANKYOU !!! Why is it that most other developers can't use common sense and say right up front that their work will kill Knox.
Click to expand...
Click to collapse
This won't actually trip Knox counter...
By installing a custom recovery (pre-requisite to install kernel.zip) will already trip the counter, and not within the scope of most Developers concern. Wouldn't the user already have tripped the counter prior to flashing the kernel? Think about it. .. Having the warning in OP doesn't hurt though

Team-M8 AOSP kernel MM & LP 3.4.110, GCC 5.3 Antutu 78k+, Battery 5 days+

Team-M8 AOSP kernel
What is it?
This project was initially based on Unicornblood kernel from DirtyUnicorns (@smac0628), which is current with linux 3.4.110. She and I are working together on this project to make a better experience for users.
We aim to include as many tweaks as possible to this AOSP kernel while maintaining stability. We also make extensive efforts to properly give credit the authors of the many features we've added (picked only the original author's commits, instead of kanging entire files).
Settings have intentionally been chosen which favor battery life over performance. With that said, you can definitely squeak out a little better battery life, or you can have some fun and get killer performance instead.
Features:
Hotplugs (only enable one!, more on the way):
IntelliPlug
Great balance between battery life and performance. It is also a popular hotplug driver from faux123.
MSM Hotplug
Great battery life, a custom qualcomm based hotplugging driver by myflux. It is a popular choice for many users.
Alucard Hotplug
A great hotplugging driver by Alucard. It is known to be very battery friendly on devices.
Zen Decision
ZEN only onlines all cores when screen is on, it also takes thermal events into account and wont online any core back, if you're under 15% battery, or currently have a thermal event because of heat. So in the end it isn't a "real" hotplug driver, because it doesnt have any code for active hot plugging in it. That means you can't change its behavior.
Hybrid Hotplug/Governor (Disable all hotplugs if you're going to use this)
zzmoove
The ZZmoove Governor by ZaneZam is optimized for low power consumption when the screen off, with particular attention to the limitation of consumption applications in the background with the screen off, such as listening to music. The unique feature with ZZmoove is that it has predefined profiles and allows profile switching. This governor is still a WIP as the developer is constantly giving updates! Here are the available profiles:
Quote:
1) for Default (set governor defaults)
2) for Yank Battery -> old untouched setting (a very good battery/performance balanced setting DEV-NOTE: highly recommended!)
3) for Yank Battery Extreme -> old untouched setting (like yank battery but focus on battery saving)
4) for ZaneZam Battery -> old untouched setting (a more 'harsh' setting strictly focused on battery saving DEV-NOTE: might give some lags!)
5) for ZaneZam Battery Plus -> NEW! reworked 'faster' battery setting (DEV-NOTE: recommended too! )
6) for ZaneZam Optimized -> old untouched setting (balanced setting with no focus in any direction DEV-NOTE: relict from back in the days, even though some people still like it!)
7) for ZaneZam Moderate -> NEW! setting based on 'zzopt' which has mainly (but not strictly only!) 2 cores online
8) for ZaneZam Performance -> old untouched setting (all you can get from zzmoove in terms of performance but still has the fast down scaling/hotplugging behaving)
9) for ZaneZam InZane -> NEW! based on performance with new auto fast scaling active. a new experience!
10) for ZaneZam Gaming -> NEW! based on performance with new scaling block enabled to avoid cpu overheating during gameplay
11) for ZaneZam Relax -> NEW! based on moderate (except hotplug settings) with relaxed sleep settings
(since version 0.9 beta4: cpu temperature threshold of 65°C enabled if exynos4 cpu temperature reading support was compiled with the governor)
Click to expand...
Click to collapse
CPU Governors (more on the way):
A CPU governor in Android controls how the CPU raises and lowers its frequency in response to the demands the user is placing on their device. Governors are especially important in smartphones and tablets because they have a large impact on the apparent fluidity of the interface and the battery life of the device over a charge.
Abyssplugv2
AbyssPlugv2 is a rewrite of the original CPU governor. It also fixes the problem where the governor is set only for the first core, but now governs all cores right from whatever utility you use. There have been comments on the lack of stability with this governor.
alucard
A favourite choice and one of the original governors that Alucard_24 made. Alucard is based on ondemand but has been heavily tweaked to bring better battery life and performance. It has been known to be battery friendly without sacrificing much performance.
badass
Badass removes all of this "fast peaking" to the max frequency. To trigger a frequency increase, the system must run a bit with high load, then the frequency is bumped. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 1-2 seconds, depending on the load your system is experiencing)
Badass will also take the gpu load into consideration. If the gpu is moderately busy it will bypass the above check and clock the cpu to max frequency, If the gpu is crushed under load, badass will lift the restrictions to the cpu
dancedance
Based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It is a performance focused governor but also blends with some battery savings.
darkness
It's based on nightmare but more simple and fast, basic configs but very complex structure. It is an updated nightmare gov and improved stability, so far it is quite stable in tests
elementalx
If you are an owner of a nexus device, you probably have heard of a governor named ElementalX. Named after the kernel, elementalX is based on interactive but with some additional performance tweaks. This governor focuses on performance and not battery savings!
hellsactive
A heavily modified intelliactive governor by @hellsgod that has been tweaked to improve battery life. Hellsactive is less aggressive compared to intelliactive so the battery life will be more like the original interactive.
intelliactive
Based off Google's Interactive governor with the following enhancements:
1. self-boost capability from input drivers (no need for PowerHAL assist)
2. two phase scheduling (idle/busy phases to prevent from jumping directly to max freq
3. Checks for offline cpus and short circuits some unnecessary checks to improve code execution paths. Therefore, it avoids CPU hotplugging.
This is a more performance oriented CPU governor that still has great battery life like the original Interactive.
intellidemand
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode.
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) by behaving like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
intellimm
A rewrite of the old Min Max governor and has 3 cpu states: Idle, UI and Max. Intelliminmax (intellimm) governor is designed to work with the newer SOCs with fixed voltage rails (ie MSM8974+ SOCs). It is designed to work within those fixed voltage ranges in order to maximize battery performance while creating a smooth UI operations. It is battery friendly and spends most of the time at lower frequencies.
nightmare
A PegasusQ modified, less aggressive and more stable. A good compromise between performance and battery. In addition to the SoD is a prevention because it usually does not hotplug.
ondemand
Ondemand is one of the original and oldest governors available on the linux kernel. When the load placed on your CPU reaches the set threshold, the governor will quickly ramp up to the maximum CPU frequency. It has excellent fluidity because of this high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand was commonly chosen by smartphone manufacturers in the past because it is well-tested and reliable, but it is outdated now and is being replaced by Google's Interactive governor.
smartmax
Ondemand is one of the original and oldest governors available on the linux kernel. When the load placed on your CPU reaches the set threshold, the governor will quickly ramp up to the maximum CPU frequency. It has excellent fluidity because of this high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand was commonly chosen by smartphone manufacturers in the past because it is well-tested and reliable, but it is outdated now and is being replaced by Google's Interactive governor.
yankactive
A slightly modified interactive based governor by Yank555.lu. It has battery tweaks added onto it so expect better battery life! Based on user reports, this governor behaves more battery friendly than the original interactive governor without sacrificing performance.
yankdemand
Full stock (JB) ondemand governor with changed default tunable values aimed at lower battery consumption
interactive
Google's own take on a CPU governor. Interactive scales the clockspeed over the course of a timer set by the kernel developer (or user). In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. It is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.
Interactive is the default governor of choice for today's smartphone and tablet manufacturers.
performance
The performance governor locks the phone's CPU at maximum frequency.
The descriptions in this post were created by @gsstudios and can be found here:
http://forum.xda-developers.com/general/general/ref-to-date-guide-cpu-governors-o-t3048957
Voltage Control (UV/OV)
OC to 2880 MHz
UC to 268 MHz
Set Max frequency in Screen-Off state
As the name says, you get to set a different governer when screen is off. This will override what you chose in the governer choice. Pretty nifty arrangement so that you can flip from a performance governer when on screen and a power save governer when screen is off. This feature was added to the kernel because it was either the developers intention or by popular demand.
Force Fastcharge
A. When set, the phone will charge off of the PC USB ports as if it is connected to wall outlet. This does turn off your access to the phone internal memory and SD card. If you want to access the internal storage on PC then you have to turn this off.
NOTE – Weather to turn on or off, has to be done before connecting to PC. Changing this after connecting has no effect.
Kexec hardboot patch (can be flashed as primary bootimage in multirom)
GPU Governors:
cpubw_hwmon
A hardware (HW) monitor based governor that attempts to determine bandwidth needed by CPU and other hardware. This is a unique GPU governor that is highly customisable, however it is known to be unstable on some devices.
msm_cpufreq
The MSM CPUfreq governor determines the CPU to DDR bandwidth vote based on the current CPU frequency of all the active CPUs. In other words, this governor scales based on CPU usage which could mean more performance.
msm-adreno-tz
The default GPU governor used by qualcomm for their adreno GPUs. It is more performance orientated than ondemand therefore it gives better performance in games but less battery life.
userspace
This governor basically allows the user is able to set a desired frequency for the GPU to run at.
powersave
Like the CPU governor, this keeps your GPU running at the lowest possible frequency. Best battery life, extreme lag in games.
performance
As the name suggests, this keeps your GPU running at the max frequency. This is a governor if you want the best possible experience in games but you don't care about your battery life.
simple_ondemand
KCal display adjustments
IO Schedulers:
Input/output (I/O) scheduling is a term used to describe the method computer operating systems decide the order that block I/O operations will be submitted to storage volumes. I/O Scheduling is sometimes called 'disk scheduling'.
I/O schedulers can have many purposes depending on the goal of the I/O scheduler, some common goals are:
- To minimise time wasted by hard disk seeks.
- To prioritise a certain processes' I/O requests.
- To give a share of the disk bandwidth to each running process.
- To guarantee that certain requests will be issued before a particular deadline.
bfq
Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.
Benefits:
- Has a very good USB data transfer rate.
- The best scheduler for playback of HD video recording and video streaming (due to less jitter than CFQ Scheduler, and others)
- Regarded as a very precise working Scheduler
- Delivers 30% more throughput than CFQ
- Being constantly updated
- Good for multitasking, more responsive than CFQ
Disadvantages:
- Not the best scheduler for benchmarks
- Higher budgets that were allocated to a process that can affect the interactivity and bring with it increased latency.
cfq
Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.
Benefits:
- Has a well balanced I / O performance
- Excellent on multiprocessor systems
- Regarded as a stable I/O scheduler
- Good for multitasking
Disadvantages:
- Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
- Jitter (worst case delay) can sometimes be very high because the number of competing with each other process tasks
- Under constant load, the phone will experience increased I / O latency due to the way how the scheduler tries to create 'fairness'
deadline
The goal of the Deadline scheduler is to attempt to guarantee a start service time for a request. It does that by imposing a deadline on all I/O operations to prevent starvation of requests. It also maintains two deadline queues, in addition to the sorted queues (both read and write). Deadline queues are basically sorted by their deadline (the expiration time), while the sorted queues are sorted by the sector number.
Before serving the next request, the Deadline scheduler decides which queue to use. Read queues are given a higher priority, because processes usually block on read operations. Next, the Deadline scheduler checks if the first request in the deadline queue has expired. Otherwise, the scheduler serves a batch of requests from the sorted queue. In both cases, the scheduler also serves a batch of requests following the chosen request in the sorted queue.
Benefits:
- Nearly a real-time scheduler.
- Excels in reducing latency of any given single I/O
- Best scheduler for database access and queries.
- Does quite well in benchmarks, most likely the best
- Like noop, a good scheduler for solid state/flash drives
Disadvantages:
- If the phone is overloaded, crashing or unexpected closure of processes can occur
fifo
First in First Out Scheduler. As the name says, it implements a simple priority method based on processing the requests as they come in.
Benefits:
- Serves I/O requests with least number of cpu cycles.
- Is suitable for flash drives because there is no search errors
- Good data throughput on db systems
Disadvantages:
- Reducing the number of CPU cycles corresponds to a simultaneous decline in performance
- Not very good at multitasking
fiops
This new I/O scheduler is designed around the following assumptions about Flash-based storage devices: no I/O seek time, read and write I/O cost is usually different from rotating media, time to make a request depends upon the request size, and high through-put and higher IOPS with low-latency. FIOPS (Fair IOPS) ioscheduler tries to fix the gaps in CFQ. It's IOPS based, so it only targets for drive without I/O seek. It's quite similar like CFQ, but the dispatch decision is made according to IOPS instead of slice.
Benefits:
- Achieves high read and write speeds in benchmarks
- Faster app launching time and overall UI experience
- Good battery life
Disadvantages:
- Not very common in most kernels
- Not the most responsive IO scheduler (Can make phone lag)
- Not good at heavy multitasking
noop
Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.
Benefits:
- Serves I/O requests with least number of cpu cycles.
- Is suitable for flash drives because there is no search errors
- Good data throughput on db systems
- Good battery life
- Does great in benchmarks
- Also a very reliable IO scheduler
Disadvantages:
- Reducing the number of CPU cycles corresponds to a simultaneous decline in performance
- Not the most responsive I/O scheduler
- Not very good at multitasking (especially heavy workloads)
row
The ROW IO scheduler was developed with the mobile devices needs in mind. In mobile devices, we favor user experience upon everything else, thus we want to give READ IO requests as much priority as possible. In mobile devices we won't have as much parallel threads as on desktops. Usually it's a single thread or at most 2 simultaneous working threads for read & write. Favoring READ requests over WRITEs decreases the READ latency greatly. The main idea of the ROW scheduling policy is: If there are READ requests in pipe - dispatch them but don't starve the WRITE requests too much.
Benefits:
- Faster UI navigation and better overall phone experience
- Faster boot times and app launch times
Disadvantages:
- Not great for heavy multitasking
- Slower write speeds
sio
Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.
Benefits:
- It is simple and stable.
- Minimized starvation for inquiries
- Good battery life
Disadvantages:
- Slow random write speeds on flash drives as opposed to other schedulers.
- Sequential read speeds on flash drives are not as good as other IO schedulers
tripndroid
A new I/O scheduler based on noop, deadline and vr and meant to have minimal overhead. Made by TripNRaVeR
Benefits:
- Great at IO performance and everyday multitasking
- Well rounded and efficient IO scheduler
- Very responsive I/O scheduler (Compared to FIOPS)
Disadvantages:
- Not found in all kernels
- Performance varies between different devices (Some devices perform really well)
vr
Unlike other scheduling software, synchronous and asynchronous requests are not handled separately, but it will impose a fair and balanced within this deadline requests, that the next request to be served is a function of distance from the last request.
Benefits:
- Generally excels in random writes.
Disadvantages:
- Performance variability can lead to different results (Only performs well sometimes)
- Sometimes unstable and unreliable
zen
ZEN scheduler is based on the VR Scheduler. It's an FCFS (First come, first serve) based algorithm, but it's not strictly FIFO. ZEN does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ones. Other than that, it's pretty much the same as no-op blended with VR features.
Benefits:
- Well rounded IO Scheduler
- Very efficient IO Scheduler
- More stable than VR, more polished
Disadvantages:
- Performance variability can lead to different results (Only performs well sometimes)
- Not found in all kernels
LED Control
Z-Ram
Q. What is ZRAM?
A. ZRAM basically compresses unused apps within the system RAM. This allows the system to swap less needed processes to the zram partition for faster access at a later time, instead of killing them. This does take up some of your ram though, so I imagine that the value you are setting is determining exactly what percentage of your ram that the zram partition is allotted.
FSYNC
TCP Congestion Algorithms:
Congestion control strategies (or algorithms) are used by TCP, the data transmission protocol used by many Internet applications. The main goal of a TCP algorithm is to avoid sending more data than the network is capable of transmitting, that is, to avoid causing network congestion. Different algorithms respond differently to network loads, but they are all based on the same principle of avoiding network congestion.
Things to look out for in TCP algorithms include (but not exclusively):
- Download/Upload speeds - The higher the number, the better
- Latency - The lower the number, the better
bic
Binary Increase Congestion control (BIC):
BIC is optimized for high speed networks with high latency: so-called "long fat networks". It has a unique congestion window (cwnd) algorithm. This algorithm tries to find the maximum where to keep the window at for a long period of time, by using a binary search algorithm.
lp
Low Priority (LP):
A distributed algorithm whose goal is to utilize only the excess network bandwidth as compared to the "fair share" of bandwidth as targeted by TCP. The key mechanisms unique to TCP-LP congestion control are the use of one-way packet delays for early congestion indications and a TCP-transparent congestion avoidance policy.
highspeed
High speed (HSTCP):
High Speed TCP (HSTCP) is a new congestion control algorithm protocol for TCP. Standard TCP performs poorly in networks with a large bandwidth delay product. It is unable to fully utilize available bandwidth. HSTCP makes minor modifications to standard TCP's congestion control mechanism to overcome this limitation.
htcp
Hamilton TCP (HTCP):
HTCP is designed for high-speed, long distance networks that increases aggressiveness as the time since the previous loss increases. It is thought to be a more efficient TCP algorithm than BIC and HSTCP.
hybla
Hybla:
Penalizes connections that use satellite radio. Not usually used with phones.
illinois
Illinois is designed for high-speed, long-distance networks. A sender side modification to the standard TCP congestion control algorithm, it achieves a higher average throughput than the standard TCP and allocates the network resource fairly as the standard TCP.
scalable
Scalable calls for congestion window to be halved for each packet lost. Effectively, this process keeps halving the throughput until packet loss stops. Once the packet loss subsides, slow start kicks in to ramp the speed back up.
vegas
One of the smoothest TCP algorithms(next to cubic), it increases the timeout delay for packets, which allows more to be received, but at a higher rate. It also has set timeouts, which helps with speed because it's constantly being refreshed.
veno
Veno is closely related to Vegas, it is a combination of Vegas and Reno in order to enhance TCP performance over Wireless networks.
westwood
A newer version of Reno, and another commonly used one. It controls parameters better, helping out streaming and overall quality of browsing the internet. One of the most 'fair' algorithms out there, and is one of the most efficient algorithms to date.
yeah
A high speed TCP congestion control algorithm which uses a mixed loss/delay approach to calculate congestion windows. Its purpose is to target high efficiency, fairness, and minimizing link loss while keeping network elements load as low as possible.
reno
Basically the same as Tahoe, but if 3 of the same packets are received, it will halve the window, instead of reducing it to one. It changes the slow start threshold equal to that of the congestion window.
cubic
One of the best, most recommended TCP options available. Less aggressive, Inflects the windows prior to the event. Used in Linux.
Sweep to Wake, Sweep to Sleep, Double-tap to Wake (for these features, please build from branch master-s2w)
How do you get it?
That's a hard question to answer, surprisingly. You're free to flash the zip file below, but it's only the zImage. While this zip will include nearly everything you'll want or need, what you need for OC/UC is part actually of the dts. The dts is another piece that gets packed together with the zImage to make the boot.img. Unfortunately there's all sorts of ramdisk & permissions issues which can be caused by flashing a boot.img, so it's not recommended.
Please make a nandroid before doing anything! Backing up the boot partition takes all of a second and 16 megs of storage. Just do it! Also, do not hold us responsible for anything that happens to your device. It's worked fantastically for us, but you're flashing at your own risk.
Downloads for MM
Download for LP (no Sweep to Wake)
Download for LP (with Sweep to Wake)
The very best method of getting the kernel, is to have it compiled with the ROM itself (as with all kernels).
O.P. is a WIP. Will be adding and editing a lot, especially at first.
Special thanks to @izzaeroth for assisting with the Anykernel zip.
XDA:DevDB Information
Team-M8 AOSP kernel, Kernel for the HTC One (M8)
Contributors
fizbanrapper, smac0628, amirfida
Source Code: https://github.com/Team-M8/android_kernel_htc_msm8974/tree/master
Kernel Special Features:
Version Information
Status: Beta
Created 2015-11-10
Last Updated 2016-08-16

Want to get the most out of your kernel?
What does that mean to you? Battery savings? Performance? Balance between them?
The "most" is a difficult question to even attempt to answer. Even assuming we could define "balance between them", I still could not give you a set of settings that would work well for everyone. Not only are you all using different variants, but you're using different builds of different ROMs with different gapps packages, different apps, different usage habits, and in different areas of the country.
You really have to get an understanding of what different things do, then decide for yourself how you should customize your settings. Trial and error!
How did I get those scores on antutu? Here's a response I provided to that very question later in the thread:
fizbanrapper said:
I don't recall the exact settings, but I'll give you general guidelines.
When I test any kernel, I think it's critical to level the playing field as much as possible. I run it on my primary ROM with PAC ROM. I run few apps on it and disable anything that might sync in the background.
Disable all hotplugs and thermal drivers. Make sure your phone has been booted for a good 5 minutes so that your thermal temps have had a chance to come back down. Since you've disabled your thermal drivers, there's a decent chance you'll get a force reboot half way through the test if you're starting off with a high cpu temp already.
Used one of the zzmoove governor profiles. I think I used zram and disabled fsync too.
If my memory serves me right, this got me to back to back scores of 52776 and 52713.
Click to expand...
Click to collapse

Want great battery life?
Set your governor's max frequency to 268000 (yankactive is pretty good for this).
Set max frequency policy to 268000. Do the same for screen off max as well as any applicable input boost settings.
Set multicore powersaving mode to aggressive.
Choose one hotplug and choose the most conservative settings available.
Don't worry, your device won't completely listen to your request to only run at 268000 under all circumstances. Unfortunately every kernel I've ever run for this device (Team-M8, CM, Candy, DU, Slim, Blissful, Furnace, PAC, and B14ckb1rd) all disrespect my wishes! Abyssplug governor is the only notable exception here.
I'll try to provide more detailed settings when I get more time.

First

Not first! ?....oh wait...
SECOND!?
Great work getting this all together with so many sweet options!

Congrats on releasing this new kernel. I've updated the governor/scheduler guide to include missing description on Yankdemand for people who were curious
gsstudios

gsstudios said:
Congrats on releasing this new kernel. I've updated the governor/scheduler guide to include missing description on Yankdemand for people who were curious
gsstudios
Click to expand...
Click to collapse
Thanks! That was fast! I've updated the OP with your description.

I flashed this on the latest AICP (Android Ice Cold Project) and it kills my data. I'm also on Verizon if that matters...

GohanBurner said:
I flashed this on the latest AICP (Android Ice Cold Project) and it kills my data. I'm also on Verizon if that matters...
Click to expand...
Click to collapse
I've never heard of that happening g from a kernel. Could it be something else causing this? Anyone else experiencing this?

It has to be, I flash the kernel from CandyRom over it and data works again. Flash this again data doesn't work...

GohanBurner said:
It has to be, I flash the kernel from CandyRom over it and data works again. Flash this again data doesn't work...
Click to expand...
Click to collapse
It should work ok if compiled with the ROM. It's one of the downsides of the flashable zip.

Can a boot.img version of this be created? Or would that be just as good as a zip?

GohanBurner said:
Can a boot.img version of this be created? Or would that be just as good as a zip?
Click to expand...
Click to collapse
Well the boot.img would contain even more aicp-specific stuff. So if it was compiled from aicp's source, it would be fine as a boot.img.
If I compiled a boot.img from a ROM I've synced, it would cause even more compatibility issues than the zip.

I don't mind switching ROMs to use this kernel, which one are you running? I assume this will work with CM, correct?

GohanBurner said:
I don't mind switching ROMs to use this kernel, which one are you running? I assume this will work with CM, correct?
Click to expand...
Click to collapse
At the moment I'm on bliss. That's what it was compiled from. That used candy kernel though too, mostly. Let me look for a good build for you to try.

Try this
https://www.androidfilehost.com/?fid=24052804347848888

Try it without the kernel zip first, to make sure it works without it. Then go back and flash to get the updates.

Scozzar said:
What Kernel manager would you guys recommend for this kernel? I use Trickster, but it doesn't have the ability to select all of the hotplug options. With Trickster, I can only seem to choose between mp-decision or intelliplug.
Click to expand...
Click to collapse
I've been using kernel adiutor

Scozzar said:
Ah much better. I'm running all the Alucard hotplug and governor. Battery life isn't great, but I did just flash it twenty minutes ago.
Sent from my m8 using Tapatalk
Click to expand...
Click to collapse
Try zzmoove or a different hotplug. Alucard might not be the right choice for you.

@smac0628 is a current and equal contributor to this project. She's the one who put the work into Unicornblood. I'll update the OP shortly so that this is more clear.
Feel free to keep whining to @Mazda and the mods though. Though I don't think any of them care, it is entertaining.

Interactive governor highly efficient profile for SmartPack Kernel - Android N/O/P

Hello all.
After about a month of researching and testing with the Galaxy S5, I'm finally happy with my SmartKernel profile, with the interactive governor carefully tuned, using known resources and countless trials and errors, as well as other various tweaks, like VM and I/O scheduler, and decided to publish on it's own thread.
The main resources I've used for the Interactive governor tuning includes the well known:
Android Modders Guide;
[GUIDE] Advanced Interactive Governor Tweaks; Buttery smooth and insane battery life! for Nexus 5X; and it's twin
[GUIDE] Advanced Interactive Governor Tweaks; Buttery smooth and insane battery life! for HTC Evo 4G.
First of all, this tweaks should be a little sensible to the ROM, kernel, apps, and other tweaks your using. Like, I just found out that Havoc pie style quicktile settings use way more juice then if I turn it off and go back to Oreo default. Bellow you will see the apps I mainly crafted this profile in mind.
For reference: I have a klte with latest Oreo Havoc installed, nano OpenGapps, Magisk and the SmartPack kernel. For apps I use Facebook lite, cause the normal app is just a big hog, whatsapp and instagram social apps. Chrome. I don't use the Google App or Greenify(uninstall/delete velvet). And play lots of games like Clash Royale, Star Wars Force Arena and Arena of Valor. BetterBatteryStats.
And a lot of random apps that normally don't stay on the background.
DESCRIPTION
On the SmartPack manager profile:
. HIghly Efficient Interactive Governor Tunables (most important part);
. No Touchboost or any other boost, only the governor dictates to CPU in which clock it should to be;
. Overclock disabled, but can be enabled at you will;
. No underclock, I do undervolt my CPU but this you need to find your specific device numbers, mine won't cut;
. LazyPlug Hotplug with all 4 cores on all the time (better performance while using and battery savings while at idle);
. I/O Schedulers: ZEN (the L-Speed profile complement this part, with it's scheduler tunables);
. READ-AHEAD internal 1024kb (for 16GB or more) and external 512 kb (for my 8GB SDCard, adjust accordingly to yours SD Card size conform described here
. Adreno Idler disabled: it doesn't make any effect;
. Speaker Driver Leakage disabled and Boeffla Sound enabled with 0 gain as it does make a difference, at least with ViperFX magisk module installed;
. Screen minimum RGB set to 1 (0 won't stick), for a darker dark on our AMOLED, plus some tweaks;
. Led blinking fade enable;
. VM tweaks: dirty_ratio 30 and dirty_background_ratio 15; for minor battery improvement, with a perceptible lower termperature/cpu usage and almost imperceptible performance hit;
. VM tweaks: page-cluster 1; for better multitasking/memory management
. VM tweaks: oom_dump_tasks 0; disable depuration of dumping tasks, less cpu needed.
. LMK values: 32 48 64 128 176 208 (MBs)
L-Speed Profile
. Logging and I/O stats disabled;
. Animations speed set to 0.25x;
. System battery save trigger at 20%;
If you need to provide or read logs, enable logging and i/o stats back on l speed; i/o stats and oom_dump_tasks 1 on smartpack manager
INSTALLATION
Unzip the attached file and import with SmartPack Manager:
The attached profile should be imported, applied and marked as to run "On Boot" to make effect. It will only work with SmartPack Manager and Kernels for both Nougat and Oreo, maybe even Pie. Just try it, and report back. If you wanna fine tune it. You need to use an app or enable the "show cpu clocks" option if your rom supports it (like Havoc, RR and many more), and monitor at which frequencies the lags happens, while doing the jobs you want the CPU to be efficient at. And mainly tweak the target_load according, maybe above_high_speed delays of 1,7GHz clock and above. You need to read the guides more in-dept too see exactly how to do it, but I'll paste here the most important parts on how to tweak this settings more to your Galaxy S5, with your particularly apps and ROM:
soniCron said:
Optimize Idle Frequency
Now that you've got the base configuration, we need to tweak it so that the CPU stays at your efficient idle frequency (384Mhz in this case) without spontaneously jumping when your phone is actually idle. To do this, open a CPU monitor that displays the current core frequencies (I like CoolTool, but you can use what you like as long as it doesn't significantly impact the CPU use--you're best off using a passive monitor and checking the results after 30-60 seconds of no activity), watch the frequencies and see how often they go above your efficient idle frequency when you're not doing anything at all, and adjust the following:
timer_rate - If your idle frequency is not being exceeded much, adjust this downward in increments of 5000 until it is, then increase it by 5000. If your idle frequency is being exceeded often, adjust this upward in increments of 5000 until your CPU primarily stays at or below your desired idle frequency.
above_highspeed_delay - Only if your timer_rate has matched or exceeded 50000 and still won't stay at or below your desired idle frequency most of the time, set timer_rate to 50000 and adjust the "20000" portion of the value upwards in increments of 5000 until the idle frequency has stabilized.
The lower these two values are, the more snappy/lag free your system will be. So try to get them as low as possible without the idle frequency being exceeded too much, as this inversely affects the snappiness and efficiency of your phone when you're not doing anything. Lower = snappier but uses more CPU when you're not doing anything (such as reading a webpage); higher = less snappy but stays in a power saving state more often reducing CPU use when you're not interacting with the device. These are the most critical in determining your idle power savings, so keep that in mind if you want the most battery life!
Enhance Task Responsiveness
Now use the efficiency and nominal clock rate correlations you made for your master clock rate list in the section above and adjust your frequencies to suit your usage patterns. For example, I had web page scrolling as my 710Mhz/864Mhz rates, so I will open a web page and scroll and see how everything feels. If it feels sluggish, I will increase all the references to "710000" in both above_highspeed_delay and target_loads upwards to the next available clock rate until that task is smooth. What you are looking for is constant poor/sluggish performance when the task you're testing for is using its highest CPU use. If the task becomes sluggish/stuttery as it winds down (such as a scrolling webpage slowing to a stop), we will address that next, so do not take that behavior into consideration as you adjust these values! If the task is smooth until (or after) it slows down, then you have reached your optimal clock rate and can move on.
If you need to exceed your nominal clock rate for a particular task, first measure it again just to be sure you had it correct. If you did indeed have it correct, leave it at your nominal clock rate and adjust the value after the colon next to the task frequency you're tuning downward in increments of 5. For example, if my setting of "864000:80" is still not sufficient, I will adjust it first to "864000:75", then "864000:70", and so on until the task is smooth. However, it almost certainly won't come to this, but if you reach ":50" and the task still isn't performing how you want, set it back to ":80" and increase the clock step once more, then decrease the ":80" until it is smooth.
Do the same for each other frequency in your master clock rate list until you are satisfied. If you have chosen to use more than 2 primary clock rates, add them and use ":##" values between the two surrounding frequency values.
Fix Stuttering
Now that you have adjusted your frequencies for optimal high CPU use in each given task, you may notice some stuttering as the task winds down. (Such as a scrolling webpage slowing to a stop.) If this bothers you, you can tweak this at the expense of some (minor) battery life by adjusting min_sample_time up in increments of 5000 until you are satisfied.
If you have exceeded a value of 100000 for the min_sample_time setting and still are not satisfied, change it back to 40000 and increase (and re-optimize) your idle frequency by one step. This will impact battery life more, but less than if you were to keep increasing the value of min_sample_time.
Adjust High Load Clock Rates
You're almost done! Now you can leave everything as is and be satisfied with your amazing, buttery smooth, snappy experience, or you can optionally tweak things further to either increase the responsiveness of high load tasks (such as loading image previews in Gallery) or increase battery life somewhat.
Adjust the final delay value in above_highspeed_delay to suit your needs. The default ("150000") means that the CPU load at the highest set frequency (default "1026000") will have to be sustained for 150ms before it allows the load to go above that frequency. Increasing this value will prevent the CPU from reaching higher frequencies (which may be unnecessary) as often, saving battery life. This will come at the expense of burst-type high CPU load tasks. Reducing it will allow the CPU to reach higher frequencies more often, at the expense of battery life. However, adjusting this is probably unnecessary, as it will most likely not yield any perceptible difference in performance. It is recommended to leave this value at its default.
Click to expand...
Click to collapse
Besides CPU Voltage and Battery, all tabs on the manager are modified and tuned to achieve best performance, while having best efficiency possible. Is not a battery or a performance, but a efficiency profile.
Refer to this thread if you wanna undervolt your device with a well know secure margin for the CPU Snapdragon 801 2.5ghz MSM8974AC, which our Galaxy S5 contains:
[GUIDE] Snapdragon 805/801/800/600 Clock & Voltage (PVS bin) guide by HD2Owner I've managed to achieve much lower voltages then PSV15+ devices (refer to the sheets).
I also attached the excel spreadsheet I've made with all this thread information, both governor guide equations on target loads, undervolting guide findings, and made my own base calculations and settings. Feel free to use, modify, and discuss it with me. You will see that I based the most efficient clocks in an original thought about which ones are the most efficient, instead of plotting the differentials between voltages of each clocks, I did plotted the difference of the clock divided by voltage, which on itself should be how much voltage 1 mhz uses, on each clock rate. So, the higher the number, more speed each clock rate give us by voltage used. It's kinda complicated and idk if I explained it the right way, and even if it really makes sense under scrutiny, but I couldn't think why not myself, so, any inputs are welcome.
I own my thanks to all the following XDA fellows, without them, I could not have achieved this:
@sunilpaulmathew for the SmartPack Kernel which is the only kernel for the S5 that can turn that damned MPDecision off and SmartPack Manager;
@soniCron for both of the governos Guides;
@Saber for the Android Modders Guide which is immensely helpful.
CHANGELOGS
L-Speed Profile (download the app on PlayStore):
011118 lspeed profile
- first release
031118 lspeed profile
- Removed most tweaks, only left minor stuff, refer to the OP.
L Speed profile is not really needed, SmartPack will do 99% of the job.
SmartPack Manger Profile (download the kernel and the app here):
301018
- first release.
011118 smartpack profile:
- A few Interactive governor tweaks;
- Removed Virtual Memory and LMK tweaks, let it on default or use L-Speed to optimize, as it does a much better job then me.
031118 smartpack profile:
- Governor tunning: better high load management;
- Included back only 3 sane VM configurations, no more freezing, better cooling (less cpu needed, while performance barely took a hit)
- Sane LMK configurations, kills apps not being used faster, retain some multitasking while not let it slow down the device
081118 smartpack profile:
- target_load (no changes up to 1497600) ...1728000:89 1958400:91 2265600:95 -> ...1728000:88 1958400:90 2265600:95
- above_hispeed 20000 1190400:60000 1497600:64000 1728000:77000 1958400:84000 2265600:130000 -> 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000
- external storage read-ahead from 512 -> 2048 (because I've gone from a 8GB to a 32 GB SDCard, ADJUST YOURS ACCORDINGLY TO https://androidmodguide.blogspot.com/p/io-schedulers.html)
- cleaned unused and already default values from profile
101118 smartpack profile:
- Turned Alucard off, accidentally activated it with Lazyplug also enabled, not good!
- Managed to go 1 point higher on freq 1497 MHz, the 2 hotplugs enabled were messing with me trying to test this change before, also 1 point lower on the idle freq 268 MHz for smoother scrolling while still staying at freq 268 while idle. And some more high load optimizations now that I only got 1 hotplug enabled as it should always be.
- target_loads from 268800:29 ... 1497600:86 1574400:5 1728000:88 1958400:90 2265600:95 to -> 268800:28 ... 1497600:87 1574400:5 1728000:89 1958400:91 2265600:94
- above_hispeed 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000 -> 20000 1190400:60000 1728000:74000 1958400:82000 2265600:120000
- dirty_background_ratio 15 -> 10
221118 smartpack profile:
. Reverted new SmartPack Kernel v14r4 changes to Virtual Memory back to original default configurations, if you've have had reboots this should fix it, please report back here and/or the kernel's thread;
. More changes to Interactive governor aiming to optimize high load scenarios according to the profile philosophy:
. above_hispeed_delay 20000 1190400:60000 1728000:74000 1958400:82000 2265600:120000 -> 20000 1190400:60000 1728000:74000 1958400:80000 2265600:105000;
. Enabled fast charge configurations, set at 1200 mhA as I found it's a good charging speed without heating the phone too much on my hot city, nothing you can't change at your will.
241218 smartpack profile:
. Restored missing min_sample_time tunable since 081018 profile
. dirty_ratio 30 -> 25
. General cleanup
. Tested on Pie

@justjr
Nice work friend. Great to see that your finally open a place to share your findings. In my opinion, your profile should work on any klte device with minimum kernel support. I haven't seen much SmartPack specific stuff in your profile except some hotplug related things. So, if you make it as a shell script instead of KA/SP-Kernel Manager profile, it shall be beneficial for everyone. Anyway, as usual, I'll kang your changes to my kernel default profile

sunilpaulmathew said:
@justjr
Nice work friend. Great to see that your finally open a place to share your findings. In my opinion, your profile should work on any klte device with minimum kernel support. I haven't seen much SmartPack specific stuff in your profile except some hotplug related things. So, if you make it as a shell script instead of KA/SP-Kernel Manager profile, it shall be beneficial for everyone. Anyway, as usual, I'll kang your changes to my kernel default profile
Click to expand...
Click to collapse
I think this profile should work on original Kernel Adiutor, or any fork of it, shouldn't it?
It should work on any other kernel if the changes really stick, and uses the same paths, but MPDecision will mess with frequencies all the time. It would still follow the governor tunables anyway, but it will interfere with it and in the end will not gain too much efficiency out of it.
Actually I only state it is for SmartPack specifically because of the fact that is the only one I can disable MPDecision on our device, and because I included all the tweaks other then just governor tweaks.
Actually I'm kinda lazy right now, but I could do a shell script if any demand for it shows up.

justjr said:
I think this profile should work on original Kernel Adiutor, or any fork of it, shouldn't it?
It should work on any other kernel if the changes really stick, and uses the same paths, but MPDecision will mess with frequencies all the time. It would still follow the governor tunables anyway, but it will interfere with it and in the end will not gain too much efficiency out of it.
Actually I only state it is for SmartPack specifically because of the fact that is the only one I can disable MPDecision on our device, and because I included all the tweaks other then just governor tweaks.
Actually I'm kinda lazy right now, but I could do a shell script if any demand for it shows up.
Click to expand...
Click to collapse
Well, official KA (free version) doesn't allow to import profiles (paid feature), but all other mods does.
and yes, it is supposed to work on every klte device as long as the sysfs paths exist. Means it should work on any custom Kernel with lazyplug support (most of the other stuff are actually included in the stock kernel itself). Of course, the default settings provided by the kernel devs might conflict. e.g., as you said, MPDecision, although the line "stop mpdecison" in your profile will disable it. By the way, I'm not the only one who disabled mpdecision and relay on other hotplugs in this klte community

sunilpaulmathew said:
Well, official KA (free version) doesn't allow to import profiles (paid feature), but all other mods does.
and yes, it is supposed to work on every klte device as long as the sysfs paths exist. Means it should work on any custom Kernel with lazyplug support (most of the other stuff are actually included in the stock kernel itself). Of course, the default settings provided by the kernel devs might conflict. e.g., as you said, MPDecision, although the line "stop mpdecison" in your profile will disable it. By the way, I'm not the only one who disabled mpdecision and relay on other hotplugs in this klte community
Click to expand...
Click to collapse
Oh, really? Which one? I must had missed it. I've tested all kernels I could find. At least all the remotely up-to-date, like venom, tuned and boeffla kernels. I didn't see any option to change hotplugs on any. There were hotplug profiles, to keep cores online and stuff, but everyone of them keep changing min and max frequency at MPDecision will.

justjr said:
Oh, really? Which one? I must had missed it. I've tested all kernels I could find. At least all the remotely up-to-date, like venom, tuned and boeffla kernels. I didn't see any option to change hotplugs on any. There were hotplug profiles, to keep cores online and stuff, but everyone of them keep changing min and max frequency at MPDecision will.
Click to expand...
Click to collapse
Boeffla and Venom largely depends on MPDecision. However, as I remember correctly (on the basis of the code review, not from my experience, I never used it by myself), the Tuned kernel by @fbs disabled MPDecision upon booting to work well with its own Tuned hotplug.

sunilpaulmathew said:
Boeffla and Venom largely depends on MPDecision. However, as I remember correctly (on the basis of the code review, not from my experience, I never used it by myself), the Tuned kernel by @fbs disabled MPDecision upon booting to work well with its own Tuned hotplug.
Click to expand...
Click to collapse
I tested it too. And although he claims he uses hes own hotplug, it behave the same as boeffla and venom, it has the same profiles, and it does changes min and max freq out of my control.

justjr said:
I tested it too. And although he claims he uses hes own hotplug, it behave the same as boeffla and venom, it has the same profiles, and it does changes min and max freq out of my control.
Click to expand...
Click to collapse
no it doesn't change any freqs
it works by disabling or enabling cores, just that.
if any cpu reaches the maximum frequency, it enables one more core (as the other ones are already giving their best)
if any cpu reaches the minimum frequency too many times, it disables it (as it doesn't seem to be needed)
so in any moment you can have all 4 cores enabled or only 1. even with display on or off, it doesn't matter
mpdecision will NEVER let you use just 1 core, and it doesn't react as fast: battery hog

fbs said:
no it doesn't change any freqs
it works by disabling or enabling cores, just that.
if any cpu reaches the maximum frequency, it enables one more core (as the other ones are already giving their best)
if any cpu reaches the minimum frequency too many times, it disables it (as it doesn't seem to be needed)
so in any moment you can have all 4 cores enabled or only 1. even with display on or off, it doesn't matter
mpdecision will NEVER let you use just 1 core, and it doesn't react as fast: battery hog
Click to expand...
Click to collapse
Alright, sorry then, it seems my memories got clouded or something, as I've tested it about a month ago. I might go back any day just to test that. Thanks for giving us one more kernel option! :good:

UPDATE OP WITH
Description
Changelogs
New profile 011118, changelog:
. Few governor tweaks
. Removed Virtual Memory and LMK tweaks, let it on default or use L-Speed to optimize, it does a much better job then me
Also uploading the L-Speed profile I use so those who want to use it like I do, but you can choose any VM and LMK profile that fits your needs on the app. Just don't use the governor tuner because it will mess with my tunings, and l-speed governor tuning is a generic one for all devices, VM and LMK is OK to use generic tweaks, but not on governor.
@sunilpaulmathew I took a look at l-speed virtual memory and lmk profiles and they make incredible sense, take a look yourself, they may be what you need to put o that spectrum profiles, because above all they are device independent and do make a noticeable difference.

Is it valide for stock rom (6.0)?

lollazzo said:
Is it valide for stock rom (6.0)?
Click to expand...
Click to collapse
What kernel? It should work if the kernel have lazyplug or alucard hotplug, if is the late you just have to enable it.

Updates
SmartPack Manager Profile 031118:
. Governor tunning: better high load management;
. Included back only 3 sane VM configurations, no more freezing, better cooling (less cpu needed, while performance barely took a hit)
. Sane LMK configurations, kills apps not being used faster, retain some multitasking while not let it slow down the device
LSpeed Profile 031118:
. Removed most tweaks, only left minor stuff, refer to the OP.
L Speed profile is not really needed, SmartPack will do 99% of the job.
OP: descriptions for both profiles updated.

New profile.
I returned to Nougat, RR 5.8.5, same configs works awesomely and the device is cooler/faster then with Oreo. But still will works the same with both N/O and even Pie, not tested.
I also reinstalled Hearthstone as a high load app so I could tune the governor better for it, and up to 1490 MHz nothing is changed, and changed a bit target_loads and above_hispeed of the clocks above it so Hearthstone (and any other high load apps, or, using split screen with youtube) runs smoother/without lags and tasks like opening an app will finish faster, and also go back to a lower clock faster because of that. So, in the end it stays most of the time at lower clocks anyway, only difference is that it will jump faster when needed for less waiting time/lag.
Just to clarify, this is not suppose to waste battery, or drain it faster. As an efficiency profile the goal is to do the job you the want faster the possible, ramping up to the clocks that the jobs demands, without lags (or minimal lags) and go back to idle/lower clocks as soon as high clocks aren't needed anymore, so it don't overstay at a higher clocks then it's needed, very simple.
So, going to a high clock doesn't mean less battery life, finishing a job fast and going back to idle is the key to achieve more battery life, specially during deep sleep, when you really want your device go back to deep sleep fast, but also at any other time. Watching youtube, browsing and using low demand apps still uses the same clocks.
Also, on top of that you will spend more time USING the device instead of WAITING for it to finish a job. Battery life is very subjective, and SoT doesn't mean nothing IRL, I mean, are you spend that SoT waiting for a job to finish or to actually use the device?
081118 smartpack profile:
- target_load (no changes up to 1497600) ...1728000:89 1958400:91 2265600:95 -> ...1728000:88 1958400:90 2265600:95
- above_hispeed 20000 1190400:60000 1497600:64000 1728000:77000 1958400:84000 2265600:130000 -> 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000
- external storage read-ahead from 512 -> 2048 (because I've gone from a 8GB to a 32 GB SDCard, ADJUST YOURS ACCORDINGLY TO https://androidmodguide.blogspot.com/p/io-schedulers.html)
- cleaned unused and already default values from profile
File attached on OP.

I don't use SD card so what do I do?

razor17 said:
I don't use SD card so what do I do?
Click to expand...
Click to collapse
In that case nothing is needed, the configurations related to the absent sd card will not be applied.

Ok guys. I was wondering why my device was heating a lot more these last 2 days. Turns out both Alucard and Lazyplug were accidentally activated on 081119 profile. Turn one of them off and everything will be a lot better. Sorry for that. I will upload a new profile very soon.
edit:
101118 smartpack profile:
- Turned Alucard off, accidentally activated it with Lazyplug also enabled, not good!
- Managed to go 1 point higher on freq 1497 MHz, the 2 hotplugs enabled were messing with me trying to test this change before, also 1 point lower on the idle freq 268 MHz for smoother scrolling while still staying at freq 268 while idle. And some more high load optimizations now that I only got 1 hotplug enabled as it should always be.
- target_loads from 268800:29 ... 1497600:86 1574400:5 1728000:88 1958400:90 2265600:95 to -> 268800:28 ... 1497600:87 1574400:5 1728000:89 1958400:91 2265600:94
- above_hispeed 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000 -> 20000 1190400:60000 1728000:74000 1958400:82000 2265600:120000
- dirty_background_ratio 15 -> 10

I will give this a try. Hope it works well...

Yeah.
You know, try it and report back. I don't see any reports, so I assume is working well for people.
Any reports are welcome.
lentm said:
I will give this a try. Hope it works well...
Click to expand...
Click to collapse
Enviado de meu SM-G900M usando o Tapatalk

justjr said:
Yeah.
You know, try it and report back. I don't see any reports, so I assume is working well for people.
Any reports are welcome.
Enviado de meu SM-G900M usando o Tapatalk
Click to expand...
Click to collapse
No problems so far...greats for daily use..scrolling smoother than default..but pubg still laggy on lower res...may i know which rom are u using?

Database Develop

welcome