Database Develop

[AOSP] [KERNEL] Deathly ZE551ML/ZE550ML - ZenFone 2 Android Development

Code:
/*
*
* I not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns do some research
* YOU are choosing to make these modifications,
* and if you point the finger at me for messing up your device, i will laugh at you.
*
*/
Kernel Features:
Updated to latest kernel.org version (3.10.85)
Exfat Support
Interactive Governor from fugu
VNSWAP support
UKSM
BLK-throttle improvements
Async FSync from HTC
CDG congestion control
Optimized Sfck Compression
Tons of under the hood optimizations and tweaks (entropy, mm, readahread, slub, fs, fuse, int_sqrt, memcopy, lib/string)
Compiled with Google's 4.9 x86_64 toolchain instead of 4.8
The following IO's added:
SIO
SIOPLUS
FIOPS
ZEN
FIFO
VR
BFQ
ROW
The following cpu govs added:
BioShock
ConverativeX
LionHeart
YankActive
Adaptive
Wheatley
LagFree (Default)
CM Downloads:
0.4 Z00A
0.4 Z008
CM Older versions:
0.3 Z00A
0.2 Z00A
0.1 Z00A
Slim Downloads:
0.4 Z00A
0.4 Z008
Slim Older versions:
None yet
Paranoid Android Downloads:
0.4 Z00A
Paranoid Android Older versions:
None yet
Kernel Source:
Here
Please look at what zip you are downloading currently i only support CM, Slim, PA please do not flash it on any alternate roms or stock
Credits:
@TheSSJ for his work on the stock kernel
@crpalmer , @jrior001 for bringing up the zf2 and its kernel
@dorimanx for his universal Exfat
@Mazda for bring the kernel up to the latest kernel.org

Changelog:
0.4
Added ROW IO
Added Lagfree CPU Gov (New Default)
Blk-Throttle improvements
CDG congestion control
Enabled/Added the following CDG schedulers:
HHF, FQ_PIE, FQ, FIFO, CAKE
Optimized Sfck Compression
Initial Z008 support
Alphabetize the IO's and CPU Gov's
Kernel updated to 3.10.85
0.3
ADB fixed (forgot to build 0.2 with the cm patches)
Added the BFQ IO (Will switch it to default if my testing goes well)
Added Async Fsync from HTC
Added UKSM support
VNSWAP support aka Virtual Nand Swap Device which simulates Swap Area (Someone on reddit wanted it added and it looks like it could be good)
Tons of under the hood optimizations and tweaks (entropy, mm, readahread, slub, fs, fuse, int_sqrt, memcopy, lib/string)
0.2
Removed THESSJACTIVE cpu gov (Added its hotplugging to YankActive)
Add Wheatley cpu gov (New Default)
Added all of the TCP congestion algorithm's (New default is VENO)
Cleaned up the source code so everything has proper authorship and its cleaner
0.1
Initial Release

Kernel Adiutor is my preferred method of controlling the kernel.
Screenshots (Will not be updated often):
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

My Current setup:
Regular use i do not game at all on this device, which is why i dial back the cpu max (There is no need for 2.3 GHz)
CPU Gov: Lagfree
IO Scheduler: cfq
IO Internal Storage Read-ahead: 1024 kb
IO External Storage Read-ahead: 512 kb
TCP Congestion algorithm: Veno
Max CPU Freq: 1583 MHz
Min CPU Freq: 500 MHz
Packet Schedulers/Congestion Avoidance Algorithms:
Info taken from here
CDG vs. Cubic vs. Westwood:
CDG
CAIA-Delay Gradient (CDG) is a hybrid congestion control algorithm which reacts to both packet loss and inferred queuing delay. It attempts to operate as a delay-based algorithm where possible, but utilises heuristics to detect loss-based TCP cross traffic and will compete effectively as required. CDG is therefore incrementally deployable and suitable for use on shared networks. During delay-based operation, CDG uses a delay-gradient based probabilistic backoff mechanism, and will also try to infer non congestion related packet losses and avoid backing off when they occur. During loss-based operation, CDG essentially reverts to reno-like behaviour. CDG switches to loss-based operation when it detects that a configurable number of consecutive delay-based backoffs have had no measurable effect. It periodically attempts to return to delay-based operation, but will keep switching back to loss-based operation as required.
Cubic
CUBIC is an enhanced version of BIC: it simplifies the BIC window control and improves its TCP-friendliness and RTT-fairness. The window growth function of CUBIC is governed by a cubic function in terms of the elapsed time since the last loss event. Our experience indicates that the cubic function provides a good stability and scalability. Furthermore, the real-time nature of the protocol keeps the window growth rate independent of RTT, which keeps the protocol TCP friendly under both short and long RTT paths.
Westwood
TCP Westwood estimates the available bandwidth by counting and filtering the flow of returning ACKs and adaptively sets the cwnd and the sshtresh after congestion by taking into account the estimated bandwidth.TCP Westwood, is a sender-side-only modification to TCP New Reno that is intended to better handle large bandwidth-delay product paths (large pipes), with potential packet loss due to transmission or other errors (leaky pipes) and with dynamic load (dynamic pipes). TCP Westwood+ is an evolution of TCP Westwood, in fact it was soon discovered that the Westwood bandwidth estimation algorithm did not work well in the presence of reverse traffic due to ACK compression. Westwood+ is friendly towards TCP Reno and fairer than Reno in bandwidth allocation.
Packet Schedulers:
Why use a non default packet scheduler?
Packet schedulers are a portion of the kernel that queues network data on a specific interface and governs how they are transmitted and received including buffers. Below I will breakdown a couple of the packet schedulers included in this kernel.
fq_codel
FQ_Codel (Fair Queuing Controlled Delay) is queuing discipline that combines Fair Queuing with the CoDel AQM scheme. FQ_Codel uses a stochastic model to classify incoming packets into different flows and is used to provide a fair share of the bandwidth to all the flows using the queue. Each such flow is managed by the CoDel queuing discipline. Reordering within a flow is avoided since Codel internally uses a FIFO queue.
pfifo_fast
The FIFO algorithm forms the basis for the default qdisc on all Linux network interfaces (pfifo_fast). It performs no shaping or rearranging of packets. It simply transmits packets as soon as it can after receiving and queuing them. This is also the qdisc used inside all newly created classes until another qdisc or a class replaces the FIFO.
A real FIFO qdisc must, however, have a size limit (a buffer size) to prevent it from overflowing in case it is unable to dequeue packets as quickly as it receives them. Linux implements two basic FIFO qdiscs, one based on bytes, and one on packets. Regardless of the type of FIFO used, the size of the queue is defined by the parameter limit. For a pfifo the unit is understood to be packets and for a bfifo the unit is understood to be bytes.
pie
PIE is designed to control delay effectively. First, an average dequeue rate is estimated based on the standing queue. The rate is used to calculate the current delay. Then, on a periodic basis, the delay is used to calculate the dropping probabilty. Finally, on arrival, a packet is dropped (or marked) based on this probability. PIE makes adjustments to the probability based on the trend of the delay i.e. whether it is going up or down.The delay converges quickly to the target value specified. alpha and beta are statically chosen parameters chosen to control the drop probability growth and are determined through control theoretic approaches. alpha determines how the deviation between the current and target latency changes probability. beta exerts additional adjustments depending on the latency trend. The drop probabilty is used to mark packets in ecn mode. However, as in RED, beyond 10% packets are dropped based on this probability. The bytemode is used to drop packets proportional to the packet size.
fq
A packet scheduler is charged with organizing the flow of packets through the network stack to meet a set of policy objectives. The kernel has quite a few of them, including CBQ for fancy class-based routing, CHOKe for routers, and a couple of variants on the CoDel queue management algorithm. FQ joins this list as a relatively simple scheduler designed to implement fair access across large numbers of flows with local endpoints while keeping buffer sizes down; it also happens to implement TCP pacing.
FQ keeps track of every flow it sees passing through the system. To do so, it calculates an eight-bit hash based on the socket associated with the flow, then uses the result as an index into an array of red-black trees. The data structure is designed, according to Eric, to scale well up to millions of concurrent flows. A number of parameters are associated with each flow, including its current transmission quota and, optionally, the time at which the next packet can be transmitted.
That transmission time is used to implement the TCP pacing support. If a given socket has a pace specified for it, FQ will calculate how far the packets should be spaced in time to conform to that pace. If a flow's next transmission time is in the future, that flow is added to another red-black tree with the transmission time used as the key; that tree, thus, allows the kernel to track delayed flows and quickly find the one whose next packet is due to go out the soonest. A single timer is then used, if needed, to ensure that said packet is transmitted at the right time.
The scheduler maintains two linked lists of active flows, the "new" and "old" lists. When a flow is first encountered, it is placed on the new list. The packet dispatcher services flows on the new list first; once a flow uses up its quota, that flow is moved to the old list. The idea here appears to be to give preferential treatment to new, short-lived connections — a DNS lookup or HTTP "GET" command, for example — and not let those connections be buried underneath larger, longer-lasting flows. Eventually the scheduler works its way through all active flows, sending a quota of data from each; then the process starts over.
There are a number of additional details, of course. There are limits on the amount of data queued for each flow, as well as a limit on the amount of data buffered within the scheduler as a whole; any packet that would exceed one of those limits is dropped. A special "internal" queue exists for high-priority traffic, allowing it to reach the wire more quickly. And so on.
One other detail is garbage collection. One problem with this kind of flow tracking is that nothing tells the scheduler when a particular flow is shut down; indeed, nothing can tell the scheduler for flows without local endpoints or for non-connection-oriented protocols. So the scheduler must figure out on its own when it can stop tracking any given flow. One way to do that would be to drop the flow as soon as there are no packets associated with it, but that would cause some thrashing as the queues empty and refill; it is better to keep flow data around for a little while in anticipation of more traffic. FQ handles this by putting idle flows into a special "detached" state, off the lists of active flows. Whenever a new flow is added, a pass is made over the associated red-black tree to clean out flows that have been detached for a sufficiently long time — three seconds in the current patch.
cake
The CAKE Principle:
(or, how to have your cake and eat it too)
This is a combination of several shaping, AQM and FQ
techniques into one easy-to-use package:
- An overall bandwidth shaper, to move the bottleneck away
from dumb CPE equipment and bloated MACs. This operates
in deficit mode (as in sch_fq), eliminating the need for
any sort of burst parameter (eg. token buxket depth).
Burst support is limited to that necessary to overcome
scheduling latency.
- A Diffserv-aware priority queue, giving more priority to
certain classes, up to a specified fraction of bandwidth.
Above that bandwidth threshold, the priority is reduced to
avoid starving other classes.
- Each priority class has a separate Flow Queue system, to
isolate traffic flows from each other. This prevents a
burst on one flow from increasing the delay to another.
Flows are distributed to queues using a set-associative
hash function.
- Each queue is actively managed by Codel. This serves
flows fairly, and signals congestion early via ECN
(if available) and/or packet drops, to keep latency low.
The codel parameters are auto-tuned based on the bandwidth
setting, as is necessary at low bandwidths.
The configuration parameters are kept deliberately simple
for ease of use. Everything has sane defaults. Complete
generality of configuration is not a goal.
The priority queue operates according to a weighted DRR
scheme, combined with a bandwidth tracker which reuses the
shaper logic to detect which side of the bandwidth sharing
threshold the class is operating. This determines whether
a priority-based weight (high) or a bandwidth-based weight
(low) is used for that class in the current pass.
This qdisc incorporates much of Eric Dumazet's fq_codel code,
customized for use as an integrated subordinate.
How to apply a packet scheduler:
1. Open terminal on your device
2. Use the "su" command to become root
3. Use tc to change the packet scheduler(qdisc) on your device. I have included an example below, the first line is for WiFi and the second for data. In the example, we are setting the qdisc to fq_pie, which is a mix of PIE with per flow rate shaping from fq.
Code:
tc qdisc add dev wlan0 root fq_pie
tc qdisc add dev rmnet_data0 root fq_pie
4. Confirm your packet scheduler has been applied by using the tc tool again. I have included an example below.
Code:
tc qdisc
To use another packet scheduler after applying a previous one, you will need to either reboot or remove the added qdisc from each interface using the command I have included below.
Code:
tc qdisc del root dev wlan0
tc qdisc del root dev rmnet_data0

I never expected that someone would have made a kernel for cm *irony off*
Great job man, looking forward to see the features you are going to implement

DUDE!! Dude... DUDE!!

Already installed . Which programa are you using for kernel info and change between IO and governors?
Thank you so much .
Enviado desde mi ASUS_Z00A mediante Tapatalk

Awesome work! Been waiting for a kernel the past few days since CM dropped.

ppmeis said:
Already installed . Which programa are you using for kernel info and change between IO and governors?
Thank you so much .
Enviado desde mi ASUS_Z00A mediante Tapatalk
Click to expand...
Click to collapse
Kernel Adiutor
https://play.google.com/store/apps/details?id=com.grarak.kerneladiutor&hl=en

@deadman96385 any advice about which governor and IO for best performance?
Enviado desde mi ASUS_Z00A mediante Tapatalk

ppmeis said:
@deadman96385 any advice about which governor and IO for best performance?
Enviado desde mi ASUS_Z00A mediante Tapatalk
Click to expand...
Click to collapse
I have not had time to figure out what the best combo is yet

ppmeis said:
@deadman96385 any advice about which governor and IO for best performance?
Enviado desde mi ASUS_Z00A mediante Tapatalk
Click to expand...
Click to collapse
If you want best performance, I'd say take performance gov with FIOPS scheduler. Don't complain about battery

You are AWESOMEEEEEE MANNNN....!!!!!!!
ask.
What gov and io to save battery?

allasca said:
You are AWESOMEEEEEE MANNNN....!!!!!!!
ask.
What gov and io to save battery?
Click to expand...
Click to collapse
TheSSJactive + SIOPLUS
Best standby battery saving imo . My phone could last 2 days with moderate using , SOT up to 5 hours

Anylove for Z550ML Dude..?

Cyborg.Gangster said:
Anylove for Z550ML Dude..?
Click to expand...
Click to collapse
Not trying to burst your bubble but I'm going to say no; this kernel is for CM and currently CM itself only supports Z00A [Z551ML].

funkencool said:
Not trying to burst your bubble but I'm going to say no; this kernel is for CM and currently CM itself only supports Z00A [Z551ML].
Click to expand...
Click to collapse
Damn,, Even If We Get CM for z500 version also?

Cyborg.Gangster said:
Damn,, Even If We Get CM for z500 version also?
Click to expand...
Click to collapse
Things could be different when/if that happens. As for right now and to the best of my knowledge, none of the current CM devs have a Z550 they can test with, and I doubt they want to be responsible for bricked devices.

funkencool said:
Things could be different when/if that happens. As for right now and to the best of my knowledge, none of the current CM devs have a Z550 they can test with, and I doubt they want to be responsible for bricked devices.
Click to expand...
Click to collapse
Dude........................................................
it bricks only if they install z551 vesion cm on their z550 one na... not if they build a separate one for z550 one na..
Dude please be optimistic.."Crossed Fingers"

Is the kernel working fine with CM? Any bugs?

Related

LuPuS Kernel
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
LuPuS-ARC/S-STOCK KERNEL HERE!!
LuPuS-JB-CM10/AOKP KERNEL HERE
Hi most of you already know my LuPuS-Stock kernel so thought i'd make one for you all that will work with any
cm9 based roms such as AOKP-by Supervenom and Paranoid Android, and obviously CM9 as well. Just wanna say a
big thanks to FXP - Jerpelea for pointing me in the rite direction for wifi to work
and of course the people who help me test besttt and sinkster for testing on both ARC-S and ARC
What i'm going to do is just update this by the end of the week to add everything else in.
So here is whats added so far but first it has to be done ------------
Disclaimer
Code:
[COLOR="DarkOrchid"]#include[/COLOR] [COLOR="Magenta"][/COLOR]
[COLOR="Blue"]/*
* Your warranty is now void.. LOL I guess you knew it already.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, you getting dumped or you getting fired because your phone
* bootloops and alarm does not go off. Please do some research if you have any
* concerns about features included in my kernel before using it! YOU and only
* YOU are choosing to make these modifications.
*/
[COLOR="Magenta"]#if[/COLOR]
You have a [COLOR="DarkGreen"]question[/COLOR] post it in the [COLOR="DarkRed"]thread[/COLOR],
Instead of [COLOR="DarkGreen"]Pm'ing me[/COLOR], as other users may
experience your [COLOR="DarkRed"]problems[/COLOR]
[COLOR="Magenta"]#endif[/COLOR][/COLOR]
What Works --
Wifi - (flash modules)
Data
Camera
Panorama
Video Recording (720p now works)
Video Playback
Front Camera
Bluetooth
Everything Else that works on FXP
What doesn't work --
Anything that doesn't work on FXP
Included in kernel
[/LIST]
Added Io-schedulers --
- Noop
- Anticipatory
- Deadline
- CFQ
- BFQ
- SIO
Added Governors --
- lagfree
- brazillianwax
- smoothass
- scary
- savagedzen
- smartass
- smartassv2
- interactivex
- minmax
- powersave
- performance
- conservative
- ondemand
- interactive
- userspace
+
Lulzactive - Thanks to Tegrak
Based on Interactive and Smartass. 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
Virtuous
Virtuous is a modded smartassV2 which gives even more battery time then smartassV2
Intellidemand - Thanks to faux123
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.
Lazy - Thanks to Ezekeel
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.
-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.
-Lionheart:
Is a conservative-based governor. 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.
To 'experience' Lionheart using conservative, try these tweaks:
sampling_rate:10000 or 20000 or 50000, whichever you feel is safer. (transition latency of the CPU is something below 10ms/10,000uS hence using 10,000 might not be safe).
up_threshold:60
down_threshold:30
freq_step:5
Lionheart goes well with deadline i/o scheduler. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand.
BadAss Governor:
Badass removes all of this "fast peaking" to the max frequency. 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 1024Mhz. If the gpu is crushed under load, badass will lift the restrictions to the cpu.
Superbad -
A "superbad" super smooth rendition of a highly optimized "smartass" governor!
Darkside -
A "slightly more agressive smart" optimized governor!
What else-----
-SLQB - (SLAB allocator with Queue)-(both)
This memory allocator is designed for small number of CPUs system (such as desktop or smart phone devices). This allocator is design to be simple and it is optimized for using order-0 pages as much as possible (order-0 pages are the simplest therefore quickest type of memory in a Linux system to allocate).
- Added Cleancache
- Supports ext 2,3
- Updated zRam
- Lzo compression/decompression speed has doubled on average.
- Init.d support
- Fudgeswap
- And much more
- O/C and stable upto 2ghz, although I do not recommend O/C to 2ghz for long periods of time, do so at your own risk.
Show your support for the kernel and my work by putting this in your signature, its only a quick one I done up with my limited time
Code:
http://i.imgur.com/xtWNL.png
Downloads in post 2
I would like to say a big thanks to -
FXP - Sources/help with wifi (thanks Jerpelea)
Cyanogenmod - Sources
DooMLoRD - for patches and all the work he has done for Xpeeria's
xeozus
NobodyAtAll
Faux123
Erasmus
Leedroid
Jerpelea
Anyone missing please PM me
Sinkster - Testing for ARC
besttt - testing for ARC-S
tempest918 - For the New Logo
Please Click Thanks :good:
Kernel sources -b ics
https://github.com/garwedgess/LuPuS-CM-iCs

Changelog
*** Previous changelog was messed up so I'll include everything in here ***
Code:
[B][U]v3[/U][/B]
- All previous boot issues / issues fixed
- Improved Battery Life alot :)
- Thumbee support
- EXT 2/3 & 4 supported
- Init.d supported
- Init.d scripts added (run at boot)
- SLQB Memory allocator
- ARM7 optimizations
- Brought OC back down to 1.6 max (no need for it above 1.6 unless u want to kill your device)
- Kernel sources completely reworked started from scratch o Sony xx.587 sources
- Tiny RCU
- Updatedd patched and fixed LZO
- lowered vfs cache pressure
- Increased Wifi- Range and added support for channel 14
- 0 % Battery patch - Thanks @ Bazoocaze
- Better memory copy
- Better memory move
- Deep sleep issue fixed
- LMK Optimizations (LowMemoryKiller)
- VDD support (voltage conrol)
- Linaro Optimzations
- Compaction added
- KSM
- CIFS (improved support)
- NTFS
- Updated to newest SIO Io-Scheduler
- Google Snappy Compress & Decompress
- Added Vibrate To Recovery (Notification to enter CWM)
- Wifi module size drasticly reduced
** Possibly missing a few things **
Downloads
If you like my work please consider buying me a beer or something else
by clicking the DONATE ME button, of course it isn't needed but greatly appreciated and keeps me motivated.
Thank you to members -
~ Frenchdroid
~ [user_99]
For your kind donations
ARC/S CM9 KERNEL
LuPuS-ARC-CM9.img
MD5 = 0638186df6b258457ed440e76991f6fa
Wifi modules in attachments
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Check your MD5 match the above if not re-download
Zram is not enabled by default- to enable it flash the zip below
If for whatever reason you want to disable it after you have flashed the .zip, just go to ect/init.d and delete 00zram :victory:

CIFS
The attached zip for CIFS is not a flashable zip read below
Make sure you download Cifs-v2 if your using v2 of kernel
What is CIFS???
Server Message Block (SMB) or Common Internet File System (CIFS) are normally used to provide shared access to files on a network, mostly involving computers running MS Windows.
It allows you to conveniently mount/unmount your network accessible file resources and access the files transparently via your favourite Android app (playing music / videos, accessing documents etc.) Settings are stored on your SD card with permissions to write also to your SD card.
Instructions
- extract cifsfile.zip from below
- save cifs,ko file to your sdcard
- in terminal emulator
- cd sdcard
- su
- insmod cifs.ko
Now download CifsManager or similar app and configure it

Ooh, was waiting for it. Gonna try that as soon as I get to office (home PC doesn't recognize fastboot mode :-\)
Sent from nowhere

tajimura said:
Ooh, was waiting for it. Gonna try that as soon as I get to office (home PC doesn't recognize fastboot mode :-\)
Sent from nowhere
Click to expand...
Click to collapse
try to install drivers for x10 from drivers folder in flashtool instalation folder.
i gotta try this kernel tomorow
Sent From Xperia Arc - CM10 Using Xda Premium!

Marchello1 said:
try to install drivers for x10 from drivers folder in flashtool instalation folder.
i gotta try this kernel tomorow
Sent From Xperia Arc - CM10 Using Xda Premium!
Click to expand...
Click to collapse
All drivers are in place, and I can use Flash mode, but when I connect in fastboot mode (blue led) Flashtool says "phone connected in flash mode" and fastboot itself complains that there are no connected devices.
Sent from nowhere

tajimura said:
All drivers are in place, and I can use Flash mode, but when I connect in fastboot mode (blue led) Flashtool says "phone connected in flash mode" and fastboot itself complains that there are no connected devices.
Sent from nowhere
Click to expand...
Click to collapse
Reinstalled flashtool recently, got that error, reinstalled the drivers one by one and it worked. For further help (from those that i'm sure know better than me) go to the flashtool sticky thread.

wi fi information
because your rom has the last modules from fxp kernel perhaps the signal is no so good do the follow
go to setings wifi delete from memory the pass and create it again and now wi fi is turbo i get from bencmark quadrand 2340 score with settings sio intelidemand oc min346 oc max 1800

seeing how there's an overwhelming amount of governors and schedulers lol can anyone recommend a combination for bother performance and battery?
btw why is there only 341 MB of ram instead of the usual 360 MB..

h.debnath said:
seeing how there's an overwhelming amount of governors and schedulers lol can anyone recommend a combination for bother performance and battery?
btw why is there only 341 MB of ram instead of the usual 360 MB..
Click to expand...
Click to collapse
Less ram because of 720p recording, was going to remove it but though people would want it, fxp have re-added it to fxp137, I can i Ilsa remove it for next release of people don't want it.
As for governors for performance I recommend intellidemand, superbad, darkside or battery life smartass, smartassv2 or virtuous. And keep SIO as scheduler it default in all my kernels
Sent from my GT-I9300

Left it overnight, 3g on, sync on, bad ass/noop. Battery drained 11% over 10 hours, which is great compared to any cm9 previously.

Someone tried this on Arc S with the cm9 wi-fi problem (getting ip address loop)?
Inviato dal mio Xperia Arc con Tapatalk 2

Disable BT.
Remove the two files from /data/misc/dhcp.
Reboot.
You're done

mekayzer said:
Disable BT.
Remove the two files from /data/misc/dhcp.
Reboot.
You're done
Click to expand...
Click to collapse
I know, but for me never worked, but thank you for your answer.
Xperia Arc S with aokp jb

Then, fix you ip adress and don't use dhcp.

Thank's for the kernel Wedgess, but can you post one based on CM7.2

mekayzer said:
Thank's for the kernel Wedgess, but can you post one based on CM7.2
Click to expand...
Click to collapse
No problem, unfortunately I do not plan on making one for CM7, I've had this request for the play also. CM9 is stable so no need for cm7. I do not have time to maintain any more kernels cm 10 kernel will be out this week and that will take my. Kernels to 10, I simply don't have the time, and besides I'll get in Trouble with the missus.......sorry
Sent from my GT-I9300

Running for approximately 6 hours, great so far. Using Virtuous gov., sio scheduler, 249-1130. Smooth, stable and battery friendly.
However, didn't test Wi-Fi yet.
Sent from nowhere

Just waiting for FXP137 to finish downloading then going to use this. Thanks.

wi fi problems
cm9.1 cm10 roms use kernels from 431 firmware dont use people baseband 77 only 72 with that roms.....if kernel changed we need other baseband

GOAL
The goal of this kernel is to have a central place for developers in the community, who don't want the burden to maintain their own kernel, to have a place to do so. Many times, developers who work on these devices constantly develop issues with others or don't have time to incorporate new features. Our goal is to avoid all that. Anything and everything will be accepted, granted it doesn't break anything. @show-p1984 has been kind enough to not only host the source but grant the use of his buildbot for this project. Every time source is pushed, the bot will start to build the kernel, zip up the package and finally upload it to my goo.im account. If you'd like to become part of this project then go ahead and reach out to me on twitter (@jassycliq) or PM me on here. My short term goal for this kernel is to add all the hotplug drivers available for mako and incorporate them into this one kernel. As it stands we can only use Qcom's binary, show's mpdecision and faux123's intelli-plug as they have switches to turn them off. These can be changed on the fly, as long as the user turns off all the hotplug drivers first then turns on the desired hotplug method. I'd also like to have an app that can control this, well a proper application to be exact.
Features
* CPU OC up to 1.9ghz, Default to 1.5GHz
* CPU UC down to 162mhz
* UV down to 600,000uVolts
* Intelli-plug hotplug driver
* Qualcomm's MPDecision
* MSM MPDecision (kernel based mpdecision)
* Dynamic FSync
* Sweep2Wake
* Snapdragon S4 and Krait optimizations
* 3-Phase Thermal
* GPU OC up to 487mhz
* Faux's Gamma Interface
* Faux Sound/Speaker Control
* Fast Charge
* Schedulers
FIOPS
SIO
NOOP
ROW
CFQ
DEADLINE (tuned for flash devices)
* Governors:
DanceDance
Interactive
Ondemand
Performance
* Advance TCP Congestion Control
Westood+
Reno
Bic
Cubic
Htcp
Veno
* Compiled with gcc 4.7.3 (Linaro 4.7-2013.04)
* -Ofast optimized
* WLAN, TUN and CIFS compiled as modules due to size of kernel from the high amounts of optimizations
* OTG support
* Too much to write!
Choosing between the 3 hotplug drivers
This kernel comes with 3 hotplug drivers (intelli-plug, qcoms mpdecision and kernel based mpdecision) by default only Qualcomm's MPDecision is used. To turn one of the others you must use their respective sysfs interfaces after turning off the one's you're not using. To make it easier for you, I have included a small little application that helps you turn through this. If you'd like to make an init.d script to choose which one you want on boot then use the following commands
For kernel based mpdecision
Code:
echo "0/1" > /sys/kernel/msm_mpdecision/conf/enabled
echo "0/1" > /sys/kernel/msm_mpdecision/conf/scroff_single_core
For Intelli-Plug
Code:
echo "0/1" > /sys/module/intelli_plug/parameters/intelli_plug_active
echo "0/1" > /sys/module/intelli_plug/parameters/eco_mode_active
For Qualcomm's MPDecision
Code:
start mpdecision
stop mpdecision
Downloads
http://goo.im/devs/jassycliq/mako
Why do I have no WLAN?
Due to this kernels very high optimization settings it is too big for our boot.img with WLAN included into the kernel, so it is built as a module. That means it needs to be inserted into the kernel upon boot up, which needs to be automated for maximum comfort = userinit (init.d) support.
The zip adds init.d support to your ramdisk, if that fails for some reason the wlan module cannot be inserted.
if
Code:
adb shell lsmod
doesn't show this:
Code:
tun 14701 0 - Live 0x00000000
cifs 275399 0 - Live 0x00000000
wlan 2964650 0 - Live 0x00000000 (C)
Then init.d support is probably missing.
You can test it by going to /system/etc/init.d/ and executing 00wlan.
Code:
adb shell
su
. /system/etc/init.d/00wlan
Wait a few seconds and try to enable wifi and repeat the above lsmod command (should now show wlan, you can execute 01cifs and 02tun too).
If WLAN now works, init.d support is missing.
You need to have busybox installed in order to be able to get init.d support going, this shouldn't be a problem for most people, since it is usually installed when rooting your phone anyway.
It does not matter if busybox is installed in /system/bin or /system/xbin, my script will detect the location upon flashing and patch the ramdisk accordingly.
If no busybox is found, the script will add init.d support to your ramdisk with the default location: /system/xbin/busybox. All you need to do is install busybox there and reboot your phone.

Changelog:
8 May 2013​
Code:
4c59771 defconfig: Update defconfig.
596b56b cpufreq: Add smartmax. Let's test this, see how it does.
1cb9bb0 msm: cpufreq: Always update frequency limits when core is online
d822b01 msm_mpdecision: boost: detect changed min frequency and update accordingly
213609a msm_mpdecision: tune hotplug values
7 May 2013​
Code:
cfcfcbe4 Revert "msm: kgsl: Add GFP_NORETRY to the page_alloc flags and handle errors"
4750928 defconfig: Update for new touch_boost feature for kernel based mpdecision.
085ba61 msm: kgsl: Reduce cmd buffer size for adreno_iommu_setstate
caed023 msm: kgsl: Fix hang detection to be 50ms or more
bf9a788 msm: kgsl: Add minimum amount of wait in adreno_waittimestamp
28780a3 msm: kgsl: Lower bounds check the number of power levels
3a7120b msm: kgsl: Avoid NULL pointer in adreno setstate functions
5db5ceb msm: kgsl: Fix guilty context logic for GPU hangs
eab59a3 msm: kgsl: Remove an uneeded register write for A3XX GPUs
da07ff9 msm: kgsl: Remove non-critical error messages
f33358f msm: kgsl: unprepare clocks when we move from NAP to SLEEP
3efbea6 msm: kgsl: Do not allocate space in ringbuffer for hung context
f41b6a2 msm: kgsl: Do not save context if it is being destroyed
b1d7357 fix error
d663e19 msm_fb: display: update var in display commit
f2c1e69 msm: display: non-blocking for overlay update
6fe5638 msm: kgsl: Remove extra interrupts when setting MMU state
7e8a134 msm: kgsl: Support user specified timeouts in adreno_waittimestamp
cf18f63 msm: kgsl: Move the adreno WPTR poke logic to the hang detection
6a808d0 msm: kgsl: Invalidate base pointers when tlb is flushed
a8bafcd msm: kgsl: Add GFP_NORETRY to the page_alloc flags and handle errors
cef0287 msm: kgsl: Fix adreno idle detection during hang
29916e4 msm: kgsl: Do not check for hang when graphics core is idle
01c3627 msm_mpdecision: input event boost: fix not resetting boost if cpu was unplugged before
643164e msm_mpdecision: add sysfs interface for input event boost
55f7b76 msm_mpdecision: add input event boost [read more]
5 May 2013​
Code:
6c31838 defconfig: trying -Ofast flag really quick
8684551 workqueue: silence 'warning: array subscript is above array bounds'
832bfbb Makefile: add -Ofast
230f31c Revert "mako LCD: keep RGB custom colors alive after screen off/on"
0a8b0db input: lge: re-work the patches I just reverted to fix a bug that was causing some leaks and some IRQ exceptions during screen on.
2f521e9 Sound Control: Added headphone poweramp controls
b9451d3 af_unix: use freezable blocking calls in read
74e437e sigtimedwait: use freezable blocking call
a479733 nanosleep: use freezable blocking call
b7b7d43 futex: use freezable blocking call
87e9542 select: use freezable blocking call
ce6c00a epoll: use freezable blocking call
abeafac binder: use freezable blocking calls
3995281 freezer: add new freezable helpers using freezer_do_not_count()
ff4bd25 freezer: skip waking up tasks with PF_FREEZER_SKIP set
23f2b45 freezer: shorten freezer sleep time using exponential backoff
6f57272 defconfig: Add new defconfig for test branch. Release 1.
74681b3 mach-msm: msm_mpdecision: default off. We will boot using Qualcomm's binary. Change zip to mirror this.
f063703 defconfig: Lower min clock, enable mpdecision (which I was advised could be turned off with 2 commands) so we will boot up with that as
d413876 auto_hotplug: Prepare for being able to run alongside show-p1984's mpdecision.
0919ae2 defconfig: Turn off auto-hotplug until it can be turned off and compiled alongside the other hotplug drivers.
38bbd31 Restrict slave mountspace so Dalvik apps can mount system-wide volumes
31cbf8b auto_hotplug: rev 4 - let's lean a little more towards performance.
4e4adbb auto_hotplug: stack the deck on auto_hotplug_late_resume to get things moving quickly again
e04373f auto_hotplug: parameter validation for max_online_cpus
751eb27 auto_hotplug: enhancements (rev 3)
9367500 auto_hotplug: enable the min_online_cpus value
689e712 auto_hotplug: enhancements (rev 2)
af7748f auto_hotplug: enhancements
5a17cb6 arm: auto hotplug - wrap all pr_info into the existing debug mode so we don't spam the kernel log
937748e Change dependencies to allow kernel to be built with ARM hotplug, and without MSM_RUN_QUEUE_STATS. These are only needed for proprietary
2527619 arm: Add auto hotplug driver
637ffac mm: vm_swappiness set to 20 (down from the default 60) since we have plenty of RAM on the Nexus 4
1e4db08 ARM: remove NWFPE and VFP emulation code from the kernel
3291b82 usb: otg: Fix? for compiling with OTG. If its wrong, I hope someone can help here.
Big thanks to @show-p1984, he really kick started this project.:highfive: One night I received a PM from him asking if I'd like to take this challenge on. He also helped me out a ton while setting up the repo and build. He really has been a great help.
Others I'd like to thank for their source, commits, hardwork, blood and tears:
@faux123
@francisco.franco
@_motley
@morfic
@Harsh
@r_data
@semaphore (or the creator of it)
@intersectRaven
@mathkid95 sorry for taking so long in adding you

Source
https://github.com/jassycliq/mako/commits/master
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
https://github.com/jassycliq/mako/commits/test

Thanks for starting this, seems a good idea. Question: are these builds tested before they are uploaded?

wow new kernel for mako, will try it man
Goodluck.

gianton said:
Thanks for starting this, seems a good idea. Question: are these builds tested before they are uploaded?
Click to expand...
Click to collapse
No, but as it stands right now nothing has changed that would be broken. In the future the test folder should be treated like a nightly build and the master folder should be treated like a stable build.
BTW I'm running the first one on that folder. The only change the newest one had is that it fixes an error where mpdecision was renamed, but now that we default to that, we don't want that to happen.
Sent from my Nexus 4 using Tapatalk 2

Just a question. I already flashed but does this have any of those modules /drivers that increase touch screen sensitivity? Considering it is compiled from every other kernel I would think so, but I'd just like to make sure
Sent from my Nexus 4 using xda app-developers app

Ranaquajaro said:
Just a question. I already flashed but does this have any of those modules /drivers that increase touch screen sensitivity? Considering it is compiled from every other kernel I would think so, but I'd just like to make sure
Sent from my Nexus 4 using xda app-developers app
Click to expand...
Click to collapse
It has Faux's patch. I will implement Franco's tomorrow or some other day. I'd like to have more than one commit for a change.

jassycliq said:
It has Faux's patch. I will implement Franco's tomorrow or some other day. I'd like to have more than one commit for a change.
Click to expand...
Click to collapse
No worries just wondering. Great work by the way
Sent from my Nexus 4 using xda app-developers app

Any reason why i lost wifi? I flashed coming from franco kernel first i flashed the kernel reset then your kernel no wifi then i flashed your kernel again and no wifi?
NEXUS⁴

casonswag said:
Any reason why i lost wifi? I flashed coming from franco kernel first i flashed the kernel reset then your kernel no wifi then i flashed your kernel again and no wifi?
NEXUS⁴
Click to expand...
Click to collapse
Check OP, it goes over this.
Since the kernel is highly optimized WiFi, TUN, and CIFS need to be built as modules. Because of this, we use init.d scripts to load them at boot, this requires busybox. You can check if it loaded by typing the following in terminal:
lsmod
If it doesn't say WLAN, then the WiFi module needs to be loaded manually by typing this in terminal:
su
./system/etc/init.d/00wlan
If that works then try updating your busybox it might have an issue. Also if you have another init.d that starts with 00 change the wlan to 08wlan
Sent from my Nexus 4 using Tapatalk 2

Is it possible to add a changelog somewhere and add the direct link to it to the first post (like Franco does)?
Would be great, thanks!

jassycliq said:
GOAL
....
Features
....
* OTG support
* Too much to write!
...
Click to expand...
Click to collapse
and OTG would be using Y-Cable only right?
Is it already included or planned feature?
Thanks again for a wonderful combo :good:

SudevG said:
and OTG would be using Y-Cable only right?
Is it already included or planned feature?
Thanks again for a wonderful combo :good:
Click to expand...
Click to collapse
Yes with Y-Cable. Well, unless I missed something the code is there, so it'd be something small like a missing file or something.
Sent from my Nexus 4 using Tapatalk 2

MaluNoPeleke said:
Is it possible to add a changelog somewhere and add the direct link to it to the first post (like Franco does)?
Would be great, thanks!
Click to expand...
Click to collapse
I'd like for people to read the OP. It has important information changelog will come. There was a lot to write considering this kernel has been in the works for a bit.
Sent from my Nexus 4 using Tapatalk 2

How does that differ from your builds in bricked kernel?

sMtt said:
How does that differ from your builds in bricked kernel?
Click to expand...
Click to collapse
Compare the features of the two of them and see . This one seems to be more feature filled while his Bricked builds are more stability.
Also check the git's of both.
Sent from my Nexus 4 using Tapatalk 2

About time you released this Been reading all your tweets lately.

This looks awesome! Just a quick question because I'm a junkie for optimizations:
Will this include the various performance improvements from Franco's Franco Kernel, Morfic's Trinity Kernel, and the super fast CodeFireX MakoKangBang kernel? Also, I myself would recommend compiling it with CodeFireX's 4.8.1 Linaro Tool chain with back ports from the 4.9 Tool chain.
Can't wait to see how this turns out! Keep up the awesome work!
Connor Baker

How often do you plan on making stable releases? Thanks.

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Welcome to the Twisted Kernel. Most of you know me for my roms all the way back to the S4. So, I figured it was time to step
up my game and give building kernels a shot. Well, here is the outcome....................
*****************************************************************************
FEATURES
Built with DOL1 and patched COF8 Sources
Unification Commits making it "universal"
Compiled w/ GRAPHITE Optimazations
LowMemoryKiller Tweaks
Cache Tweaks
CPU OC/UC
A53 UnderClockable To 200Mhz Oc To 1600Mhz
A57 UnderClockable To 200Mhz Oc To 2400Mhz
Voltage Optimizations
Enabled LZ4 Compression
Enabled DCACHE Word Access
Enabled HMP Boosting On Initial Touch Level
Entropy Tweaks
Enabled Frandom
Optimized CPU Idle Time
11 I/O Schedulers
22 CPU Governors
Deep Sleep Fix
I/O Latency increased 34%
Dynamic CPU Hotplug tweaks
Linux Updated to 3.10.95
Memory Leak Patches
VMA Caching
Optimized GPU Thermal
Memory Leak Fixes
Injects SU through ramdisk
and a crap load of other Optimizations (I"m not typing all of that...)
*****************************************************************************
CPU Governors:
Darkness
Nightmare
Wheatly
Smartass2
Ondemandplus
Bluactive
Intellimm
Pegasusq
Hyper
Preservative
ConservativeX
Alcuard
Wave
Ktoonservative
Dancedance
Conservative
Ondemand
Userspace
Lionheart
Bioshock
Interactive
Performance
*****************************************************************************
I/O Schedulers
Noop
Deadline
CFQ
BFQ
Sioplus
Tripndroid
Fiops
Sio
Fifo
Zen
VR
*****************************************************************************
WARNING
I am NOT responsible for ANYTHING you do to your phone. This kernel has been tested and ran by several of my users....
Credits to the following who made this possible
@G.lewarne
@ktoonsez
@ShinySide
@Xileforce
@hrtkernel
and to many others
*****************************************************************************
Special Notes
To control the kernel you MUST use 3C Toolbox from the Play Store. There is a free version as well as a pro version.
Both will work just fine. Now, IF there are any questions on how to use this app, OR any kernel related questions, then
by all means ASK............
****************************************************************************
Code:
April 3
Release of V7.1
Fixed ktoonsevative gov
Fixed reboot issues
Compiled with GRAPHITE
Compiled with Ccache
LowMememoryKiller Tweaks
Enabled Frandom
and more crap.....
DOWNLOADS
Twisted-Kernel-V7.1​
XDA:DevDB Information
Twisted-Kernel, Kernel for the T-Mobile Samsung Galaxy S6
Contributors
The Sickness
Source Code: https://github.com/The-Sickness/DOL1-S6.git
Kernel Special Features:
Version Information
Status: Stable
Stable Release Date: 2016-03-07
Beta Release Date: 2016-02-23
Created 2016-03-08
Last Updated 2016-03-29

Here is a list of governors (not all are in my kernel) and what they do......
CPU Governors
OnDemand
OnDemandX
Performance
Powersave
Conservative
Userspace
Min Max
Interactive
InteractiveX
Smartass
SmartassV2
Scary
Lagfree
Smoothass
Brazilianwax
SavageZen
Lazy
Lionheart
LionheartX
Intellidemand
Hotplug
Badass
Wheatley
Lulzactive
PegasusQ\PegasusD
HotplugX
Abyssplug
MSM DCVS
Intelliactive
Adaptive
Nightmare
ZZmove
Sleepy
Hyper
SmartassH3
SLP
NeoX
ZZmanX
OndemandPlus
DynInteractive
Smartmax
Ktoonservative\KtoonservativeQ
Performance may cry (PMC)
Dance Dance
AbyssPlugv2
IntelliMM
InteractivePro
Slim
Ondemand EPS
Smartmax EPS
Uberdemand
Yankactive
Impulse
Bacon
Optimax
Preservative
Touchdemand
ElementalX
Bioshock
Bluactive
Umbrella_core
ConservativeX
Hyrdxq
DevilQ
Yankasusq
Darkness
Alucard
Descriptions:
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 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.
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. 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. 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.
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 Goveronor:
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 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. Wheatley works as planned and does not hinder the proper C4 usage for task where the C4 can be used properly. 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.
Wheatley is a more performance orientated governor as it scales more aggressively than ondemand and sticks with higher frequencies.
24. Lulzactive:
It's based on Interactive & Smartass governors.
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.
25. Pegasusq/Pegasusd The Pegasus-q / d is a multi-core based on the Ondemand governor and governor with integrated hot-plugging. It is quite stable and has the same battery life as ondemand. However, it is less stable than HYPER on some devices like the S2 (before the PegasusQ governor was updated). 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 will run 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's a modified version of Hotplug and optimized for the suspension in off-screen
27. AbyssPlug It's a Governor derived from 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. It makes the phone's CPU smoothly scale from low power, from low leakage mode to blazingly fast performance.Only to be used by Qualcomm CPUs.
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. Therefore, it avoids CPU hotplugging.
This is a more performance oriented CPU governor but isn't that much different from interactive (in terms of code).
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 so that the system is more responsive to interactive workloads in lowest steady-state but 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
The ZZmove 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. ZZmoove is not a good gaming governor as it aims to save battery. This governor is still a WIP as the developer is constantly giving updates! Here are the available profiles:
33. Sleepy
The Sleepy (formerly known as Solo) is an attempt to strike a balance between performance and battery power to create. It is based on Ondemand. It includes some tweaks like the Down_sampling variable and other features that set by the user through the sysfs of "echo" call. Sleepy is quite similar to Ondemandx.
34. Hyper
The Hyper (formerly known as kenobi) is an aggressive smart and smooth governor based on the Ondemand and is equipped with several features of Ondemandx suspend profiles. It also has the fast_start deep_sleep variable and detection features. In addition, the maximum frequency is in suspend mode 500Mhz. This is a more smoothness oriented governor which means that it is good for performance, without sacrificing much battery life.
35. SmartassH3
The SmartassH3 governor is designed for battery saving and not pushing the phones performance, since doing that drains battery and that's the one thing people keep asking for more of. Based on SmartassV2.
36. SLP
It is a mix of pegasusq and ondemand. Therefore, it has a balance between battery savings and performance.
37. NeoX
An optimized version of the pegasusq governor but with some extra tweaks for better performance. This means more battery drainage than the original PegasusQ.
38. ZZmanx
ZZmanx is exactly the same as ZZmove, but it has been renamed because DorimanX made it into his own version (possibly better performance) . However, it still suffers from below average gaming performance. (Refer to ZZmoove description for guide on profiles)
39. OnDemandPlus Ondemandplus is an ondemand and interactive-based governor that has additional power-saving capabilities while maintaining very snappy performance. While the interactive governor provides a modern and sleek framework, the scaling logic has been been re-written completely. Reports have found that users find ondemandplus as a more battery friendly governor. In ondemandplus, the downscaling behavior from ondemand is only very slightly modified. However, the upscaling has been modified to not scale up to maximum frequency immediately.
40. DynInteractive A dynamic interactive Governor. This Governor dynamically adapts it's own CPU frequencies within your parameters based off the system(s) load.
41. Smartmax
This is a new governor which is a mix between ondemand and smartassv2. By default this is configured for battery saving,so this is NOT a gamer governor! This is still WIP!
42. Ktoonservative\KtoonservativeQ
A combination of ondemand and conservative. Ktoonservative contains a hotplugging variable which determines when the second core comes online. The governor shuts the core off when it returns to the second lowest frequency thus giving us a handle on the second performance factor in our CPUs behavior.
43. Performance may cry (PMC)
A governor based on Smartmax except it's heavily tweaked for better and maximum battery life. This is not a gaming governor!
44. Dance Dance
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.
45. 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.
46. 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.
47. Interactive Pro
A newer (modified) version of interactive which is optimized for devices such as the One Plus One. It is a more efficient than the original Interactive because it continuously re-evaluates the load of each CPU therefore allowing the CPU to scale efficiently.
48. Slim
A new governor from the cm branch and the slimrom project. This is a performance optimized governor and has been tuned a lot for newer devices such as the One Plus One.
49. Ondemand EPS
Once again, a modified version of Ondemand and is optimized for newer devices. It is based on the Semaphore Kernel's Ondemand which is more optimized for battery life and better performance than the traditional ondemand governor.
50. Smartmax EPS
A newer smartmax governor that has been slightly optimized for newer devices.
51. Uberdemand
Uberdemand is Ondemand with 2-phase feature meaning it has a soft cap at 1728 MHz so your cpu won't always go directly to max, made by Chet Kener.
52. 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.
53. Impulse
An improved version of interactive modified by neobuddy89. Impulse aims to have a balance between battery and performance just like interactive but has some tweaks to save battery.
54. Bacon
This is nothing but polished interactive governor branded as "bacon" since it was adapted from bacon device thanks to neobuddy89. Most of the tweaks are for performance/latency improvements
55. Optimax governor
This is based on ONDEMAND, like almost all governors that have arisen from XDA. It contains some enhancements from LG, particularly to freq boost handling so it will boost to a set level, almost like HTC's governor. It has different tunables to the HTC governor but it behaves pretty similar, the tunables it comes with default are a bit more conservative.
It originates from Cl3kener's Uber kernel for Nexus 5, where it has quite a reputation for battery life
56. Preservative governor
This is based on the idea that the CPU will consume a lot of power when it changes frequency. It is based on the conservative governor. The idea is that it will stay at the step specified (702MHz selected by the creator Bedalus) unless needed. You will notice it will hover around 702 a lot, and not go above too much, and only to min freq when NOTHING is happening at all. This is most beneficial when you are doing something like reading; the screen is static or playing light games that won't need boosting any more
The governor comes from Moob kernel for nexus 4
57. Touchdemand
Touchdemand is based on the ondemand cpu governor but has been modified for the Tegra 3 chip (tablet only) and has additional tweaks for touchscreen responsiveness.
58. 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!
59. Bioshock
Not the game, but rather the CPU governor developed by Jamison904. A mix of ConservativeX and Lionheart. Good balance between battery savings and performance.
60. Blueactive
A new cpu governor based on interactive with tweaks to improve battery life. This governor is heavily focused in battery savings while performing decent in multitasking. Not a recommended gaming governor.
61. Umbrella_core
A new cpu governor based on interactive that is focused on battery life and not performance. It will still ramp up to a set frequency but will not stay at high frequencies for long. Users have reported weird behavior with this governor
62. ConservativeX
Essentially, it is a less aggressive version of conservative. More battery life, less performance.
63. HydrxQ
Simply a lulzactiveq governor with tweaks to performance (thanks to tegrak).
64. DevilQ
An aggressive pegasusq governor which keeps the hotplugging at max 2 cpu cores to offline). This is pretty much a more optimized pegasusq for phone's with quad core processors.
65. YankasusQ
Yankasusq is another modified pegasusq but with including screen off freq tunable and some other modifications as well. Possibly better battery life.
66. 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
67. 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.
Thanks to poondog for some of his governor descriptions!
Continued in next post

For performance:
Single-core:
- Performance - Best
- Min Max - Great
Multi-core:
- Performance - Best
- Min Max - Great
For battery life:
Single-core:
- Conservative - Best
- Powersave - Good
Multi-core:
- Conservative - Best
- SLP/Sleepy - Great
- Perfomance may cry (PMC) - Best
- Powersave - Good
- Ktoonservative(Q) - Great
- Smartmax - Best
- ZZMove/ZZmanX - Requires tuning, use battery plus or battery profile
For balanced battery saving and performance:
Single-core:
- Interactive/Intelliactive - Best
- Ondemand/OndemandX - Stock, Best
- SmartassV2 - Great
Multi-core:
- MSM DCSV - Great, not common
- LulzactiveQ - Good
- Intelliactive - Good
- Interactive/InteractiveX - Great
- Ondemandplus - Great
- Darkness - Great
- Nightmare - Great
- Yankactive - Great
- Ondemand/OndemandX - Stock, Best
- Pegasus(q/d) - Best
- SmartassV2 - Great
- Wheatley - Good
- Hotplug/HotplugX - Good
- NeoX - Great
- HYPER - Best
- ZZMove/ZZmanX - Requires tuning, use optimized or default profile
- Dancedance - Good
For gaming:
Single-core:
- Interactive/InteractiveX - Best
- Performance - Great
- Ondemand/OndemandX - Great
- SmartassV2 - Best
Multi-core:
- Lionheart/LionheartX - Best
- Dancedance - Great
- Intelliactive - Great
- Yankactive - Good
- NeoX - Great
- Interactive/InteractiveX - Best
- SmartassV2 - Great
- Pegasus(Q/D) - Best
- Ondemand/OndemandX - Great
- HYPER - Best
- Performance - Great
- LulzactiveQ - Best
- Intellidemand - Good
- ZZMove/ZZmanX - Requires tuning, use gaming or performance profile
Other CPU Governors not mentioned in the recommended section are either not used by people anymore or they are not suited for most people or have been removed from kernels.
Why change your phones I/O Scheduler?
Most phone manufacturers keep your phones I/O Schedulers locked so users are unable to modify any values which could change the performance of your phone. However, once your phone is rooted, you can change these values allowing the potential to boost your phones performance and even slightly increase battery life. Here is a thorough guide on all of the common i/o schedulers.
What is an I/O Scheduler:
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.
Which schedulers are available?
CFQ
Deadline
VR
Noop
Anticipatory
BFQ
FIOPS
SIO (Simple)
Row
ZEN
Sioplus
FIFO
Tripndroid
Descriptions:
Anticipatory:
Two important things here are indicative of that event:
- Looking on the flash drive is very slow from boot
- Write operations while at any time are processed, however, be read operations preferred, ie, this scheduler returns the read operations a higher priority than the write operations.
Benefits:
- Requests of read accesses are never treated secondarily, that has equally good reading performance on flash drives like noop.
Disadvantages:
- Requests from process operations are not always available
- Reduced write performance on high-performance hard drives
- Not very common in most kernels (or even phones these days)
CFQ:
The CFQ - Completely Fair Queuing - similar to the Dead Line maintains a scalable continuous Process-I/O, the available I / O bandwidth is fairly and evenly shared to all I / O requests to distribute. It creates a statistics between blocks and processes. With these statistics it can "guess" when the next block is requested by what process, each process queue contains requests of synchronous processes, which in turn is dependent upon the priority of the original process. There the V2 version has some fixes, such as I / O request improvements, hunger fixes , and some small search backward integrated to improve responsiveness.This is the default IO scheduler for Samsung smartphones.
Benefits:
- Has a well balanced I / O performance
- Excellent on multiprocessor systems
- Easiest to tune.
- Best performance of the database after the deadline
- Regarded as a stable I/O scheduler
- Good for multitasking
Disadvantages:
- Can make your phone lag when multitasking between intensive applications
- 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
Deadline:
This scheduler has the goal of reducing I / O wait time of a process of inquiry. This is done using the block numbers of the data on the drive. This also blocks an outlying block numbers are processed, each request receives a maximum delivery time. This is in addition to the Governor BFQ, it is very popular and is in many well known kernels.
Benefits:
- It is 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
- Like noop, it is a good scheduler for solid state/flash drives
- Good for light and medium multitasking workloads
Disadvantages:
- If the phone is overloaded, crashing or unexpected closure of processes can occur
- Bad battery life if doing a lot of multitasking
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. It is sometimes used by default for custom roms and custom kernels
Benefits:
- Faster UI navigation and better overall phone experience
- Faster boot times and app launch times
- Possibly better battery life
Disadvantages:
- Slower write speeds
- Not a scheduler for benchmarking
- Some intensive applications like games could slow down your phone
SIO (Simple):
It aims to achieve with minimal effort at a low latency I / O requests. Not a priority to put in queue, instead simply merge the requests. This scheduler is a mix between the noop and deadline. There is no conversion or sorting of requests.
Benefits:
- It is simple and stable.
- Reliable I/O scheduler
- 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
Noop:
The noop scheduler is the simplest of them. It is best suited for storage devices that are not subject to mechanical movements, such as our flash drives in our phones use to access the data. The advantage is that flash drives do not require rearrangement of the I / O requests, unlike normal hard drives. the data that come first are written first. It's basically not a real scheduler, as it leaves the scheduling of the hardware.
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
- Does great in benchmarks
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
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. It is a very good scheduler with elements of the deadline scheduler. It is the best for MTD Android devices. Vr can make the most of the benchmark points, but it is also an unstable scheduler. Sometimes the scores fluctuate below the average, sometimes it fluctuates above the average.
Benefits:
- Generally excels in random writes.
Disadvantages:
- Performance variability can lead to different results (Only performs well sometimes)
- Very often unstable and unreliable
BFQ:
Instead requests divided into time segments as the CFQ has, on the BFQ budget. The flash drive will be granted an active process until it has exhausted its budget (number of sectors on the flash drive). The awards BFQ high budget does not read tasks. BFQ has received many updates to the scheduler and the performance is consistently improving.
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.
- Slower UI navigation
ZEN:
Based on the VR Scheduler. It's an FCFS (First come, first serve) based algorithm. It's not strictly FIFO. It does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ones. Other than that, pretty much the same as no-op.
Benefits:
- Well rounded IO Scheduler
- Very efficient IO Scheduler
- More stable than VR, mainly because it doesn't really behave like VR.
- Relatively battery friendly
Disadvantages:
- Not found in all kernels
Sioplus:
Based on the original Sio scheduler with improvements. Functionality for specifying the starvation of async reads against sync reads; starved write requests counter only counts when there actually are write requests in the queue; fixed a bug).
Benefits:
- Better read and write speeds than previous SIO scheduler
- Good battery life
Disadvantages:
- The same as SIO scheduler
- Not found in all kernels
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.
Benefits:
- Achieves high read and write speeds in benchmarks, usually performs the best
- Faster app launching time and overall UI experience
- Good battery life
- Low impact to system performance
Disadvantages:
- Not very common in most kernels
- Not the most responsive IO scheduler (Lags in UI)
- Not good for heavy multitasking
FIFO (First in First Out):
A relatively simple io schedulers that does what has been described. It is also known as FCFS (First come first serve) but this really isn't true. It does basic sorting; sorting the processes according to the appropriate order and nothing else. In other words, it is quite similar to noop.
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
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)
- Relatively battery friendly
Disadvantages:
- Not found in all kernels
- Performance varies between different devices (Some devices perform really well)
Recommended IO schedulers:
For everyday usage:
- SIO (My personal favourite)
- NOOP
- CFQ (Forth choice)
- Deadline
- ROW
- Tripndroid (Third choice)
- ZEN (Second choice)
For battery life:
- SIO (Third choice)
- FIOPS (Second choice)
- NOOP (First choice)
- Tripndroid
- ROW (Forth choice)
- FIFO
For gaming:
- Deadline
- CFQ
- SIO (First choice)
- Tripndroid (Second choice)
- ZEN (Third choice)
- BFQ
- ROW
- FIOPS
For performance(Benchmarking):
- NOOP
- Tripndroid (Third Choice)
- SIO
- Deadline (Second choice)
- FIOPS (First choice)
For multitasking:
- BFQ (First choice)
- Deadline (Second choice)
- CFQ (Second choice)

Good luck brother...been a long time coming... v3 is a beast

VERY NICE!!!
Downloading now and will definitely follow this thread!! Looking forward to this and future updates!!

What what downloading now and will let you know how this beast rides!

slickrick54 said:
What what downloading now and will let you know how this beast rides!
Click to expand...
Click to collapse
Better strap in bro

Downloading, flashed, ready to play! Is cache clear necessary or should I be good?

Nice....been off the charger for bout an hr or so

So far, so TWISTED. Will report in battery life later today.

Running awesome here! Getting good battery life even with all the testing I've been doing with schedulers and governers. Once it settles in I bet battery life will get even better.

Already working on V4....

Hey bro,
I'm still in a crazy amount of sim training right now fighting V1 cuts and engine fires, so still haven't had time to flash your new rom, but I found time to flash this kernel on top of Sick As Hell V7 (yeah, that's out of date too lol). All I can say is, wow. This time of day my battery is usually around 45%, and since flashing this kernel, it's currently at 71%. Battery life is back baby!!
Loving the speed and response time as well. Once again man, you've breathed new life into my phone I'll keep you posted as soon as I'm able to flash some Twisted back onto my phone, and report on that as well! I'm looking forward to it!!

Ummm....the other 40 or so who downloaded my kernel....could I get maybe a "little" feedback? Or something....

The Sickness said:
Ummm....the other 40 or so who downloaded my kernel....could I get maybe a "little" feedback? Or something....
Click to expand...
Click to collapse
My bad bro been running it for 2 days now and wow it's even better than V2 and my battery life is great as well! :good:

The Sickness said:
Ummm....the other 40 or so who downloaded my kernel....could I get maybe a "little" feedback? Or something....
Click to expand...
Click to collapse
Good luck

The Sickness said:
Ummm....the other 40 or so who downloaded my kernel....could I get maybe a "little" feedback? Or something....
Click to expand...
Click to collapse
My fault man. I have been running V3 for about 3 days now and my phone has been silky smooth with great battery life. I have not tweaked the settings at all either just the stock settings. Great job @TheSickness.

I was beginning to wonder if I should continue with building V4....there hasn't been a kernel posted here for close to a year.
But....we'll see.

I installed v3 and noticed that the governor options were far far fewer than what was originally outlined in the first post. I'm guessing that is because a lot of them were/are no longer being used.
Prior to installing, I was running Unikernel v9.1 and getting about 4 hours Screen On Time.
The settings and what have you for the Twisted kernel in the 3C Toolbox seem to be a bit over my head.
I'd like to utilize the Kernel but could use a bit of guidance in setting it up.
Let me know if any of you can provide some minor support.
Thanks

The first post shows exactly how many governors are in V3. Post #2 shows governors as a whole, not what's in V3...
I have the best battery settings set as default. You can get more battery if you use Wheatly....

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Pure, powerful and fast as hell.
These shall be the characteristics of my HellSpawn kernel for the Nexus 4 (MAKO).
Why another kernel for the Nexus 4?
Answer is simple.. why not! I started to look around for an appropriate kernel which could be an enrichment in my BeanStalk ROM (abbr. BS). One of the fastest candidates has definitely been the hells-Core kernel. But I didn't want to depend on other devs, hence I decided to start my own project based on the awesome work by hellsgod (big thanks to you!).
Your constant feedback is welcome and essential for the further development! Even if I probably cannot fulfil the wishes by everyone, I am trying to consider the most promising features requested. However, I will try to keep the number of new features limited in order to not bloat up the kernel which could easily result in a degradation of its stability.
I am looking forward to fruitful discussions with you and figuring what the hell turn out to be the most suitable kernel features in terms of performance and battery life!
Note: This kernel is compatible with Android 6.0.1 (Marshmallow) and with Android 7.x (Nougat). Please pay attention which build you are downloading. Builds for Android 7.x might be backwards compatible.
Features:
Linux 3.4.112 based on sources of hells-Core N4 kernel b88-M (hats off to hellsgod) and tweaks from other kernels, e.g. Quanta-Mako (thanks zaclimon), TaUrUs_Kernel (thanks txuki2005), Unleashed (thanks ion-storm) and Mirage (thanks mgr666)
Compiled with the latest Cortex-A15 optimized UberTC 5.x with some kernel based optimizations: graphite, NEON
AOSP/BeanStalk/CM compatible
MultiROM compatible (Kexec patch)
Alucard-hotplug (alucard)
AutoSMP-hotplug (Mgr666) set as default
dyn_hotplug (stratosk)
Mako-hotplug (franciscofranco)
msm-sleeper: upgrade to version 2 (thanks flar2)
Zen Decision Hotplug (bbedward)
CPU Governors: hellsactive (default), conservative, ondemand (tweaked by stratosk), interactive (tweaks from neobuddy and franciscofranco), performance, elementalX (flar2), pegasusQ (ByungChang Cha), alucard (alucard), smartmax (maxwen), intelliminmax (faux123)
GPU Governors: ondemand, performance, simple, conservative
GPU Overclocking up to 487.5MHz
Bricked thermal driver (showp1984)
Gamma control by faux123
Userspace Voltage Control (faux123)
Marshmallow: Sound Control (faux123)
USB fast charging (Chad Froebel/faux123)
Doubletap2wake/power suspend support (stratosk) incl. profiles (Center, Full screen, Bottom half, Top half) (savoca )
DT2W: fire a small vibration when device is woken up
Exponential brightness driver (stratosk)
USB-OTG Support (ziddey/faux123)
Marshmallow: Support for android-keyboard-gadget (You can use your device as a keyboard/mouse for your PC) (zaclimon)
Knob for Fsync on/off (franciscofranco)
Knobs for Arch Power and Gentle Fair Sleepers
Knobs for preventing wakeups: bluesleep wakelock, bluedroid_timer wakelock, wlan wakelocks and msm_hsic_host wakelock
Qualcomm Slimbus driver incl. tweaks
Partial-resume framework & quickwakeup driver
No F2FS support (don't ask me for adding it)
Tested on the following ROMs:
* Pure Nexus M/N (AOSP)
* BeanStalk M (CM-13 based)
* Resurrection Remix M (CM-13-based)
* [NMF26O] Fake nexus rom for Nexus 4
* NeXus4ever ROM N (AOSP)
Known issues:
* According to a user report it doesn't appear to work on latest Chroma.
* Changing CPU governors doesn't work in CM-based ROMS
DISCLAMER
Your warranty is now void.
I am not responsible for bricked devices, dead SD cards, thermonuclear war, or you getting fired because the alarm app failed. Please do some research if you have any concerns about features included in this Kernel before flashing it! YOU are choosing to make these modifications, and if you point the finger at me for messing up your device, I will laugh at you.
Click to expand...
Click to collapse
Download:
In order to change dt2w profiles (e.g. bottom half, center etc.) you need to install my Kernel Adiutor Mod.
Nougat release for AOSP/CM based ROMs:
HellSpawn-N4-Nougat-R05-AOSP-UBERTC-6.x-CPUSET
HellSpawn-N4-Nougat-R05-AOSP-UBERTC-6.x
HellSpawn-N4-Nougat-R05-CM-UBERTC-6.x
Mirror for nougat releases:
https://www.androidfilehost.com/?w=files&flid=136250
Last release version for Marshmallow:
hellspawn-N4-mm-6.0-r18-AOSP-UBERTC-5.4
hellspawn-N4-mm-6.0-r18-AOSP-UBERTC-7.0
hellspawn-N4-mm-6.0-r18-BS-UBERTC-5.4
hellspawn-N4-mm-6.0-r18-BS-UBERTC-7.0
hellspawn-N4-mm-6.0-r18-CM-UBERTC-5.4
hellspawn-N4-mm-6.0-r18-CM-UBERTC-7.0
Archived marshmallow builds until r13:
>HERE<
Installation:
1. Wipe cache/dalvik cache
2. Flash kernel zip over stock kernel of the ROM
3. Wipe cache/dalvik cache again (optional)
4. Reboot system
IMPORTANT NOTE:
With r05 and higher, you don't have to worry about clean and/or dirty flashing problems. The anykernel installer will reuse the ramdisk of your previous kernel and apply a patch with my HellSpawn Kernel Tweaks.
Credits:
Special thanks to
- AOSP
- hellsgod
- zaclimon
- ganachoco
- txuki2005
- yoinx
- Cl3Kener
- franciscofranco
- faux123
- eng.stk
- stratosk
- show-p1984
- mrg666
- Defconoi
- neobuddy89
- flar2
- CallMeAldy
- AK
- DespairFactor
- Alucard
- mydongistiny
- And anyone I forgot
XDA:DevDB Information
HellSpawn-N4, Kernel for the Google Nexus 4
Contributors
spezi77, jolinnard
Source Code: https://github.com/spezi77/hellspawn-N4
Kernel Special Features:
Version Information
Status: Stable
Current Stable Version: R05
Stable Release Date: 2016-12-28
Current Beta Version: r17
Beta Release Date: 2016-08-13
Created 2016-03-30
Last Updated 2016-12-28

Change log Nougat:
R01
* Initial nougat release for AOSP and CM based ROMs
* no longer a separate build variant for BeanStalk
* no longer compiling with TC-7.0 (I never heard by anyone that they felt a difference incl. myself) -> compiled with UBER TC 5.4.1
* no longer franco's gamma control by franco -> faux123 gamma control
* incl. security patches from October 2016 (fix CVE-2016-3857, CVE-2016-5340, etc.)
R02
* Manual rebase of HellSpawn on the basic nougat kernel which is the built-in kernel in my NeXus4ever ROM
* This build allows to switch the SELinux mode between permissive and enforcing (you can do this with Kernel Adiutor)
* Added a new build variant for Fake nexus ROM (incl. cpuset feature) as requested by @xenyz
* Omitted a few unnecessary things, e.g.: toggleable software crc, custom sound control, disable IO stats per default, Lock initial TCP window size to 64k, interactive CPU governor mods, impulse CPU governor, mpdecision based hotplug (Bricked), etc.
* Added the latest security patches from November 2016, e.g.: mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
* Doubletap2wake/power suspend support incl. profiles (Center, Full screen, Bottom half, Top half)
* DT2W: fire a small vibration when device is woken up
R03
* Add franco sound control
* Fix SELinux toggle
* This time we really use sd-card filesystem
* Change max readahead size to 512KB
* Revise GPU normal- & overclock frequencies: ... 400MHz, 487MHz
* Optimize apply_slack() for size and speed -- http://lkml.indiana.edu/hypermail/linux/kernel/1201.3/03172.html
* Add latest fixes from franco's nexus 5 kernel
R03 hotfix: solve battery drain while device is in IDLE
* Revert faulty commits (smpboot) which prevent the device from entering deep sleep
R04
* cpufreq: ondemand: MICRO_FREQUENCY_MIN_SAMPLE_RATE to 10K (return to a more sane default value)
* merged latest updates from security bulletin
* USB: msm_otg: Fix a bug in charger detection procedure
* USB: msm_otg: Fix host mode suspend bug
R05
* Linux 3.4.113
* Switch toolchain to uber/arm-eabi-6.x (more details: https://github.com/spezi77/hellspawn...ba15b6cc23629b)
Change log Marshmallow:
r01
* Initial beta release for CM (based on hells-Core N4 kernel b88-M)
* Add MSM OTG hack (ziddey/Chad Froebel/faux123)
* Use simplified thermal driver (franciscofranco)
* Add gamma control (franciscofranco)
* Add tweaks and optimizations from Quanta-Mako kernel (zaclimon)
* Add support for android-gadget-keyboard (zaclimon)
r02
* Beta Release for AOSP/CM
* Add Qualcomm Slimbus driver and use tweaks (CallMeAldy)
* Add fsync on/off support (franciscofranco)
* Add relaxed power savings from NVIDIA (experimental) (Tk-Glitch/zaclimon)
* Add ElementalX CPU governor (flar2)
r03
* Beta Release for AOSP/CM
* CPU-boost: add wake up boost, input boost and minor improvements (neobuddy89)
* Mako-hotplug: add toggle
r04
* Stable Release for AOSP/CM
* Fix USB problem: copying files via MTP was not working (at least in my device)
* Apply marshmallow patch by Dmitry Grinberg (Updated from flo: partialresume, uid-cputime, kernel wakeup reasons)
* MPDecision disabled per default
* Anykernel: disabled ramdisk patcher for now
r05
* Stable Release for AOSP/CM and each variant compiled with UBER TC 4.9.x and 5.3.x
* Partial revert of marshmallow patch by Dmitry Grinberg
* Remove CPU BOOST (caused battery drain and potential conflicts with mako hotplug)
* Add Simple GPU governor (faux123)
* Anykernel: re-enabled ramdisk patcher
r06
* Stable Release for AOSP/CM and each variant compiled with UBER TC 4.9.x and 5.3.x
* Added bricked hotplug driver as alternative (showp1984)
* Replaced franco's simplified thermal driver with bricked thermal driver (showp1984)
* Added more CPU governors: slim (based a lot on elementalX), badass (power-efficient)
* Anykernel: many improvements
r07
* Stable Release for AOSP/CM and each variant compiled with UBER TC 4.9.x and 5.3.x
* Added AutoSMP hotplug driver
* Added PegasusQ CPU governor and removed Slim governor
* Anykernel: set AutoSMP as default while other hotplug driver remain disabled
r08
* From now on the kernel is also compatible to CM-13.0 based roms (thanks to @redj12 and @MrRisan for making me aware of that)
* In order to reduce build time, future builds will always use UBER TC 5.3.x, and ensure compatiblity with AOSP, BS and CM based roms
* Added upstream fixes from CM-13 to improve compatibility and stability
r09
* In order to offer greater flexibility, future builds will always use UBER TC 5.3.x (stable & battery-friendly) and TC 7.0 (experimental)
* Disable msm_mpdecision/bricked hotplug
* Add Alucard Hotplug & introduce Alucard CPU governor
* Enable 487.5 Mhz GPU Overclocking (experimental)
r10
* Fix video recording feature (Thanks to you for letting me about this issue!)
* Add Zen Decision Hotplug (Details. Thanks bbedward)
* Add Smartmax CPU governor (Based on OnDemand & SmartAss2; Usage scenario: Power-efficiency)
* Add powersuspend: new PM kernel driver for Android w/o early_suspend (Thanks yank555-lu & faux123)
* Add further wakelock knobs (Thanks franciscofranco):
** wakeup: add toggle for bluesleep wakelock
** wakeup: add toggle for bluedroid_timer wakelock
** wakeup: add toggles for wlan wakelocks. They are all enabled by default, it's up to the user to turn them off.
* Add quickwakeup (Thanks txuki2005 for discovery.):
** Allow kernel driver to do periodic jobs without resuming the full
system. This option can increase battery life on android powered
smartphone.
r9.5
* In order to reduce battery drain (introduced in r10) I decided to
** Exclude new PM kernel driver for Android w/o early_suspend
** Exclude zen_decision
* Remove the ultra-low CPU frequencies to prevent bad UX
r11 (official)
* Fixed headset not being recognized
* Reduced logspam (nf: uid field in the msg) (big thanks @ivanich for pointing this out)
* Added quite a few tweaks & performance improvements used in franciscofranco's msm-kernel (flo) and ion-storm's Unleashed-N4 kernel
* Replaced deprecated earlysuspend hooks with lcd notify
* msm-sleeper: upgrade to version 2 (thanks flar2) & change to use lcd-notifier.
* Updates for CPU hotplug drivers
** ALUCARD_HOTPLUG: Implemented use msm rq stats. fixed issue with min. CPUs online.
** zen decision: re-introduce & deactivate battery threshold (like lightning!) (big thanks @txuki2005 for pointing me to a version that has been adapted to 3.4.x branch)
* Updates for CPU governors
** Abandon badass: causes too much UI stuttering/scrolling lags
** Ondemand: use optimizations from Semaphore kernel (credits stratosk)
** Smartmax: update for battery savings. Hotfix NULL pointer dereference.
** Introduce Impulse governor (Experimental) (credits neobuddy89)
** Introduce intelliminmax (credits faux123): 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.
** Intellimm: fully sync w/dorimanx
** Alucard: tune for performance and to reduce idle drain. enable io is busy on alucard.
** Introduce Interactive: reduce timer with screen off (might be interesting for people who are listening music and experience audio issues due to measures for power saving while screen is off)
r11 dev notes:
I have tried many things & tested a lot of different configurations recently, e.g. to add back cpuboost driver, and also to add msm_limiter (replacement for msm_sleeper). Also worth to mention.. I have stabilized intelli_plug, which was temporarily added into r11-test-builds, but then it turned out that it has had impacts on the overall performance.. all those cool stuff didn't help to further improve this kernel, so I decided to abandon it in the official r11 build.
At this point I would like to thank two awesome guys: @dragos281993 @Cristiano Lira who supported me extremely with testing and help me on the right track! BTW, I am constantly measuring changes with help of Antutu and my own eyes..
Rumors:
Last but not least.. You might be interested in learning about how my "experiments" with lazyplug have went. Well, there is not much to say, except for it didn't work. And hence I decided to give up.
r12
* Fix camera crash (thanks zaclimon).
* Improve battery life and phone sleep state by revert lcd_notify.
* Add system wide Linaro lsk-v3.10 based workqueues aligned towards power saving.
* Patch to Linux 3.4.112
* Add tweaks from mirage kernel (thanks mrg666)
r13 (official)
* Merge UPSTREAM fixes from msm-flo-3.4-mm-mr2
* Add a few performance tweaks from mirage kernel (thanks mrg666)
* Add latest version of dyn_hotplug from stratosk (lollipop branch)
* Switch to latest ubertc 5.4.1
* cpufreq: interactive: Use hellsgod's defaults
* cpufreq: conservative: add back cpufreq_notify_utilization. Required to work with mako_hotplug.
* Remove impulse, thunderX & thunderplug
r14 (official)
* Add interactive updates from myfluxi
* Merge July bulletin fixes (thanks CM & thanks @txuki2005)
r15 (official)
* Fix for deep sleep issue/kernel panic by making a revert of smpboot related commits
* cpufreq: interactive: set timer_rate to 60ms on screen off (previously 50ms) (thanks franco)
* Performance improvements (thanks franco)
* Faster boot up through increased timer frequency (thanks franco)
* Set rate to 250 Hz for mako (thanks zaclimon)
r16 (official)
* Included CPU governor stockdemand
* Added Voltage interface for GPU
* GPU: Add 27MHz GPU idle frequency for battery savings
* Power-efficiency: series of power efficiency patches from NVIDIA
* Many tweaks for stability and to reduce lags/improve battery life
* Enable quickwakeup driver
* AIO: Optimization for SSD-only machines
* Security patches: crypto: arm/aes update NEON AES module to latest OpenSSL version
* RAM optimizations: enable KSM and KSM check page
* Disable OOB interrupt when WLAN is off
* dyn_hotplug: optimize for performance
r17 test (currently only for AOSP and BS ROM)
* Security update: Fix CVE-2016-5340 (Quadrooter Vulnerability)
* A few performance related enhancements (sched_clock, framebuffer imageblit function)
* Add toggle to control software CRC
* Updated the kernel installer script to reduce logcat spam (powerhal) and to disable mpdecision / thermald
r18 (official) CM COMPATIBLE
* Revert: CPU governor stockdemand (not working with CM-based ROMs)
* Revert: updates for kernel installer script (not working with CM-based ROMs)
* Revert: series of power efficiency patches from NVIDIA (has introduced a performance decrease)
* Ondemand patch: update frequency when limits are relaxed (currently ondemand doesn't do that when limits are relaxed, wasting power on systems with relatively low sampling rate.)
* AIO SSD ONLY: enable the SSD-only optimization for the Linux Asynchronous IO
framework.

FAQ:
Pac-Man said:
And... What is the difference between normal and CPUSET?
Click to expand...
Click to collapse
jer_ying_fd said:
It's meant to be used ONLY with fake nexus rom, because it is the only rom with the modifications to use CPUSET properly. As a result, using it with another rom will result in one core being used only.
Click to expand...
Click to collapse
What's the difference between UBERTC-5.x, -6.x and -7.0
Click to expand...
Click to collapse
Tc 5.x and 6.x are the most up-to-date and stable toolchains provided by UBER devs. Tc 7.0 was temporarily in use (experimental).
Why do I need so many different CPU governors and what are they for?
Click to expand...
Click to collapse
1: 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.
2: Performance
The performance governor locks the phone's CPU at maximum frequency.
3: Conservative
This governor 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". The original and unmodified conservative is slow and inefficient. Newer and modified versions of conservative (from some kernels) are much more responsive and are better all around for almost any use.
4: Interactive
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.
5: BadAss (has been removed in r11)
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.
6: Pegasusq
The Pegasusq is a multi-core based on the Ondemand governor and governor with integrated hot-plugging. It is quite stable and has the same battery life as Ondemand. 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 will run 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.
7: Smartmax
Smartmax is a mix between Ondemand and Smartassv2. It behaves mostly like Smartass with the concept of an "ideal" frequency. By default this is configured for battery saving, so this is NOT a gaming or benchmark governor! Additionally, to make it "snappy", Smartmax has "touch poke". So input events from the touchscreen will boost the cpu for a specific time to a specific frequency. Developed by XDA user Maxwen.
8: 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.
9: Impulse
An improved version of interactive modified by neobuddy89. Impulse aims to have a balance between battery and performance just like interactive but has some tweaks to save battery.
10: ElementalX
The ElementalX CPU governor has been specifically designed and tuned to get the best balance between battery life and performance. By default, it is more conservative than Ondemand. During routine usage, the CPU frequency does not ramp up very often. If gboost is enabled, during gaming or any other graphics intensive situation, the CPU frequencies boost much easier in order to maintain maximum performance. There is also a built in input boost.
11: 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.
12: 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.
Why do I need so many different GPU governors and what are they for?
Click to expand...
Click to collapse
1: Simple
It's a new governor for the gpu frequency scaling. It will allow a more fine grained control over how the gpu scales up and down then the previous ones. Depending how you tune it, it can be better for battery life or performance.
2: Ondemand
Much like the CPU governor, Ondemand will ramp up the frequency when a load is detected. A good balance between performance and battery savings. This is a widely used governor in qualcomm devices.
3: Powersave
Like the CPU governor, this keeps your GPU running at the lowest possible frequency. Best battery life, extreme lag in games.
4: Conservative
Like the CPU governor, this one is the opposite of Interactive; it is slow to ramp up the frequency, then quickly drops the frequency once the GPU is no longer under a certain threshold of load.
5: 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.
Why do I need so many different CPU Hotplug drivers and what are they for?
Click to expand...
Click to collapse
1: MPDecision (disabled by intension -- do not even think of enabling it)
Qualcomm's default hotplugging driver. One of the most widely used hotplug drivers in all android devices.
2: Alucard-Hotplug
A great hotplugging driver by Alucard. It is known to be very battery friendly on devices.
3: Mako-Hotplug
A new popular hotplugging driver found in Francokernel. This is a highly configurable driver that can be configured to use dual core for light-loads and quad-core for heavy loads.
4: 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.
5: Bricked Hotplug (has been temporary added, but then removed again from this kernel)
Conservative hotplug driver by showp1984. It is based on mpdecision but has been optimized for better balance between battery life and performance.
6: msm_sleeper (always on by default)
The main feature with this hotplug is that you can customize the screen off frequency. Two cores are always on, the third and fourth are independent and come online if needed. By default, if the load is over 80 for 400ms another core comes online. The third and/or fourth cores stay online as long as the load demands it or for a minimum of one second. While the screen is off, it goes down to a single core. Created by flar2.
7: AutoSMP
A highly-efficient hotplug driver by mrg666, works in-sync with the CPU governor to enable off-line cpu cores when the the CPU frequency reaches a high threshold and still more compute power is needed. Therefore, touch boost bloat is removed.
What are recommended settings for performance?
Click to expand...
Click to collapse
For a good performance you don't have to tweak anything, but use my defaults (AutoSMP/Hellsactive).
Using ElementalX as CPU governor will apply a GPU boost when GPU is at max power which should have a positive effect on gaming performance.
Using Pegasusq as CPU governor allows you to reach the highest end score in Antutu Benchmark tool.
What are recommended settings for increased battery life?
Click to expand...
Click to collapse
Change CPU hotplug to Alucard and CPU governor to Smartmax or Intellimm.
Partially based on: http://androidmodguide.blogspot.de/p/blog-page.html

Can I use UKM or HKM to control kernel settings?

snacs said:
Can I use UKM or HKM to control kernel settings?
Click to expand...
Click to collapse
HKM should work as this kernel is hells-core based. It seems that HKM is no longer available in Playstore. Do you have a download link?
I don't know about UKM, I personally never used it. Could you give it a shot?
But I can tell you that it works with KernelAdiutor.
Cheers!

Another thing to flash! Really thanks for support. I will try it ASAP and give feedback.
Wysłane z mojego Nexus 4 przy użyciu Tapatalka

spezi77 said:
HKM should work as this kernel is hells-core based. It seems that HKM is no longer available in Playstore. Do you have a download link?
I don't know about UKM, I personally never used it. Could you give it a shot?
But I can tell you that it works with KernelAdiutor.
Cheers!
Click to expand...
Click to collapse
HKM here. Sound control never work for me in KernelAdiutor, and it don't have C-States control too. I'll try UKM and post here later.

Installed, now just testing how it works

snacs said:
HKM here. Sound control never work for me in KernelAdiutor, and it don't have C-States control too. I'll try UKM and post here later.
Click to expand...
Click to collapse
HKM works in general.
You should not enter Display Control, otherwise FC. It's because the kernel has Franco's gamma control instead of the one by faux123.

Btw, I have added performance profiles (francescofranco). But I am not sure how to get them working. But I believe that this can be achieved with Franco's kernel manager..

Kernel is smooth. Working great with cooperation with DU10.0. Elementalx is Nice governor, no random reboots, cold and no glitches here.
Wysłane z mojego Nexus 4 przy użyciu Tapatalka

Working quite nicely with BrokenOS as well. Love the addition of the USB-OTG. Thanks!

str3tch72 said:
Kernel is smooth. Working great with cooperation with DU10.0. Elementalx is Nice governor, no random reboots, cold and no glitches here.
Wysłane z mojego Nexus 4 przy użyciu Tapatalka
Click to expand...
Click to collapse
¿What's DU10.0?
Enviado desde mi Nexus 4 mediante Tapatalk

Dirty Unicorns.
Wysłane z mojego Nexus 4 przy użyciu Tapatalka

r03 is up.

How about adding kexec-hardboot patch into it ?

Lycris11 said:
How about adding kexec-hardboot patch into it ?
Click to expand...
Click to collapse
Already therein, was added by hellsgod.

I gotta say, this kernel is slick as **** man. Kudos to you, @spezi77
Sent from my Nexus 4 using Tapatalk

Best kernel for smoothness and battery life. Definetely. @spezi77 you are a guarantee of high quality work, really. ?
Wysłane z mojego Nexus 4 przy użyciu Tapatalka

Can I dirty flash r3 over r2?
BTW, UKM works very well

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
OK folks......This thread will contain TWO kernels. Let me repeat that "TWO KERNELS". One for the S6 Flat,
and one for the S6 Edge. MAKE SURE you download the right kernel for your phone. Or you will have some very
serious issues.
Both of these are built from the same source, just different config files. Both have ALL of the same features, tweaks, etc.
These kernels are for the T-Mobile S6 and Edge ONLY. If you flash this to a different device then you are on your
own. If some brave soul flashes this to anything but a T-Mobile S6 Flast or Edge, let me know and I can make a list
of compatibility.......
This kernel has alot of tweaks that can be adjusted by YOU. In order to change any of the kernel parameters you need use a kernel app. Both kernels
support Synaspe....
I want to remind the Edge users........I built this for YOU, not me. I have NO USE for a Edge kernel. So it may be a good idea to at
least tell me Thank you for the time I had to spend just for yall. Lack of appreciation will bring Edge development to a halt on my end.
***FEATURES***
EPD1, EPH2, EPK5 Ramdisk
Synaspe Support
Built with Sabermod 7.0 Toolchain (optimized)
Compiled with Graphite
Linux 3.10.104
Injects Root via SuperSU "systemless"
-A53 UnderClockable To 200Mhz OC to 1704Mhz
-A57 UnderClockable To 200Mhz OC to 2304Mhz
VMA Caching
Sleep/Suspend Patches
22 CPU Governors
11 I/O Schedulers
and a ton of other crap........
SYNASPE
OC/UC
CPU Voltage
GPU Voltage
GPU Overclock
HMP Threshold
Power Aware Scheduling
Live CPU Stats
Input-Booster
Thermal Control
HMP Voltage
I/O Tunables
LMK Profiles
UKSM
Dynamic FSYNC
Dynamic Dirty Page Writeback
Virtual Nand Swap
ZSwap Memory Pool
Kernel Entropy
Gentle Fair Sleepers
Arch Power
Google Play Services Battery Drain Fix
Wakelock Control
Audio Control (ie EQ)
Live Battery Stats
Battery Settings
LED Control
And more........
Keep in mind that this is a work in progress. Which means I will be adding more improvements for
our phones. Your job is to participate in my thread, my job is to give you have kick azz kernel.
Flashing either kernel is pretty easy. Go into recovery and flash.....Do not wipe anything. Modules
are now built into the kernel and not separate like back in the day.
***DOWNLOADS***
Twisted-Kernel-Flat-V11.5
Twisted-Kernel-Edge-V11.5
I have done my part. Now its YOUR turn...........​
XDA:DevDB Information
Twisted Kernel 6.0.1, Kernel for the T-Mobile Samsung Galaxy S6
Contributors
The Sickness
Source Code:https://github.com/The-Sickness/Twisted-MM
Kernel Special Features: G920T/G925T
Version Information
Status: Stable
Stable Release Date: 2016-05-11
Beta Release Date: 2016-05-09
Created 2016-05-12
Last Updated 2016-07-12
XDA:DevDB Information
Twisted-Kernel, ROM for the T-Mobile Samsung Galaxy S6
Contributors
The Sickness
ROM OS Version: 6.0.1 MM
Version Information
Status: Testing
Created 2016-10-29
Last Updated 2016-10-29

Here is a list of governors (not all are in my kernel) and what they do......
CPU Governors
OnDemand
OnDemandX
Performance
Powersave
Conservative
Userspace
Min Max
Interactive
InteractiveX
Smartass
SmartassV2
Scary
Lagfree
Smoothass
Brazilianwax
SavageZen
Lazy
Lionheart
LionheartX
Intellidemand
Hotplug
Badass
Wheatley
Lulzactive
PegasusQ\PegasusD
HotplugX
Abyssplug
MSM DCVS
Intelliactive
Adaptive
Nightmare
ZZmove
Sleepy
Hyper
SmartassH3
SLP
NeoX
ZZmanX
OndemandPlus
DynInteractive
Smartmax
Ktoonservative\KtoonservativeQ
Performance may cry (PMC)
Dance Dance
AbyssPlugv2
IntelliMM
InteractivePro
Slim
Ondemand EPS
Smartmax EPS
Uberdemand
Yankactive
Impulse
Bacon
Optimax
Preservative
Touchdemand
ElementalX
Bioshock
Bluactive
Umbrella_core
ConservativeX
Hyrdxq
DevilQ
Yankasusq
Darkness
Alucard
Descriptions:
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 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.
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. 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. 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.
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 Goveronor:
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 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. Wheatley works as planned and does not hinder the proper C4 usage for task where the C4 can be used properly. 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.
Wheatley is a more performance orientated governor as it scales more aggressively than ondemand and sticks with higher frequencies.
24. Lulzactive:
It's based on Interactive & Smartass governors.
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.
25. Pegasusq/Pegasusd The Pegasus-q / d is a multi-core based on the Ondemand governor and governor with integrated hot-plugging. It is quite stable and has the same battery life as ondemand. However, it is less stable than HYPER on some devices like the S2 (before the PegasusQ governor was updated). 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 will run 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's a modified version of Hotplug and optimized for the suspension in off-screen
27. AbyssPlug It's a Governor derived from 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. It makes the phone's CPU smoothly scale from low power, from low leakage mode to blazingly fast performance.Only to be used by Qualcomm CPUs.
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. Therefore, it avoids CPU hotplugging.
This is a more performance oriented CPU governor but isn't that much different from interactive (in terms of code).
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 so that the system is more responsive to interactive workloads in lowest steady-state but 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
The ZZmove 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. ZZmoove is not a good gaming governor as it aims to save battery. This governor is still a WIP as the developer is constantly giving updates! Here are the available profiles:
33. Sleepy
The Sleepy (formerly known as Solo) is an attempt to strike a balance between performance and battery power to create. It is based on Ondemand. It includes some tweaks like the Down_sampling variable and other features that set by the user through the sysfs of "echo" call. Sleepy is quite similar to Ondemandx.
34. Hyper
The Hyper (formerly known as kenobi) is an aggressive smart and smooth governor based on the Ondemand and is equipped with several features of Ondemandx suspend profiles. It also has the fast_start deep_sleep variable and detection features. In addition, the maximum frequency is in suspend mode 500Mhz. This is a more smoothness oriented governor which means that it is good for performance, without sacrificing much battery life.
35. SmartassH3
The SmartassH3 governor is designed for battery saving and not pushing the phones performance, since doing that drains battery and that's the one thing people keep asking for more of. Based on SmartassV2.
36. SLP
It is a mix of pegasusq and ondemand. Therefore, it has a balance between battery savings and performance.
37. NeoX
An optimized version of the pegasusq governor but with some extra tweaks for better performance. This means more battery drainage than the original PegasusQ.
38. ZZmanx
ZZmanx is exactly the same as ZZmove, but it has been renamed because DorimanX made it into his own version (possibly better performance) . However, it still suffers from below average gaming performance. (Refer to ZZmoove description for guide on profiles)
39. OnDemandPlus Ondemandplus is an ondemand and interactive-based governor that has additional power-saving capabilities while maintaining very snappy performance. While the interactive governor provides a modern and sleek framework, the scaling logic has been been re-written completely. Reports have found that users find ondemandplus as a more battery friendly governor. In ondemandplus, the downscaling behavior from ondemand is only very slightly modified. However, the upscaling has been modified to not scale up to maximum frequency immediately.
40. DynInteractive A dynamic interactive Governor. This Governor dynamically adapts it's own CPU frequencies within your parameters based off the system(s) load.
41. Smartmax
This is a new governor which is a mix between ondemand and smartassv2. By default this is configured for battery saving,so this is NOT a gamer governor! This is still WIP!
42. Ktoonservative\KtoonservativeQ
A combination of ondemand and conservative. Ktoonservative contains a hotplugging variable which determines when the second core comes online. The governor shuts the core off when it returns to the second lowest frequency thus giving us a handle on the second performance factor in our CPUs behavior.
43. Performance may cry (PMC)
A governor based on Smartmax except it's heavily tweaked for better and maximum battery life. This is not a gaming governor!
44. Dance Dance
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.
45. 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.
46. 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.
47. Interactive Pro
A newer (modified) version of interactive which is optimized for devices such as the One Plus One. It is a more efficient than the original Interactive because it continuously re-evaluates the load of each CPU therefore allowing the CPU to scale efficiently.
48. Slim
A new governor from the cm branch and the slimrom project. This is a performance optimized governor and has been tuned a lot for newer devices such as the One Plus One.
49. Ondemand EPS
Once again, a modified version of Ondemand and is optimized for newer devices. It is based on the Semaphore Kernel's Ondemand which is more optimized for battery life and better performance than the traditional ondemand governor.
50. Smartmax EPS
A newer smartmax governor that has been slightly optimized for newer devices.
51. Uberdemand
Uberdemand is Ondemand with 2-phase feature meaning it has a soft cap at 1728 MHz so your cpu won't always go directly to max, made by Chet Kener.
52. 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.
53. Impulse
An improved version of interactive modified by neobuddy89. Impulse aims to have a balance between battery and performance just like interactive but has some tweaks to save battery.
54. Bacon
This is nothing but polished interactive governor branded as "bacon" since it was adapted from bacon device thanks to neobuddy89. Most of the tweaks are for performance/latency improvements
55. Optimax governor
This is based on ONDEMAND, like almost all governors that have arisen from XDA. It contains some enhancements from LG, particularly to freq boost handling so it will boost to a set level, almost like HTC's governor. It has different tunables to the HTC governor but it behaves pretty similar, the tunables it comes with default are a bit more conservative.
It originates from Cl3kener's Uber kernel for Nexus 5, where it has quite a reputation for battery life
56. Preservative governor
This is based on the idea that the CPU will consume a lot of power when it changes frequency. It is based on the conservative governor. The idea is that it will stay at the step specified (702MHz selected by the creator Bedalus) unless needed. You will notice it will hover around 702 a lot, and not go above too much, and only to min freq when NOTHING is happening at all. This is most beneficial when you are doing something like reading; the screen is static or playing light games that won't need boosting any more
The governor comes from Moob kernel for nexus 4
57. Touchdemand
Touchdemand is based on the ondemand cpu governor but has been modified for the Tegra 3 chip (tablet only) and has additional tweaks for touchscreen responsiveness.
58. 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!
59. Bioshock
Not the game, but rather the CPU governor developed by Jamison904. A mix of ConservativeX and Lionheart. Good balance between battery savings and performance.
60. Blueactive
A new cpu governor based on interactive with tweaks to improve battery life. This governor is heavily focused in battery savings while performing decent in multitasking. Not a recommended gaming governor.
61. Umbrella_core
A new cpu governor based on interactive that is focused on battery life and not performance. It will still ramp up to a set frequency but will not stay at high frequencies for long. Users have reported weird behavior with this governor
62. ConservativeX
Essentially, it is a less aggressive version of conservative. More battery life, less performance.
63. HydrxQ
Simply a lulzactiveq governor with tweaks to performance (thanks to tegrak).
64. DevilQ
An aggressive pegasusq governor which keeps the hotplugging at max 2 cpu cores to offline). This is pretty much a more optimized pegasusq for phone's with quad core processors.
65. YankasusQ
Yankasusq is another modified pegasusq but with including screen off freq tunable and some other modifications as well. Possibly better battery life.
66. 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
67. 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.
Thanks to poondog for some of his governor descriptions!
Continued in next post
Credits for this info can be found at the original thread by clicking the link below.
I want to apologize to the original author......I was given all of this info via a ReadMe file.
Original Thread

For performance:
Single-core:
- Performance - Best
- Min Max - Great
Multi-core:
- Performance - Best
- Min Max - Great
For battery life:
Single-core:
- Conservative - Best
- Powersave - Good
Multi-core:
- Conservative - Best
- SLP/Sleepy - Great
- Perfomance may cry (PMC) - Best
- Powersave - Good
- Ktoonservative(Q) - Great
- Smartmax - Best
- ZZMove/ZZmanX - Requires tuning, use battery plus or battery profile
For balanced battery saving and performance:
Single-core:
- Interactive/Intelliactive - Best
- Ondemand/OndemandX - Stock, Best
- SmartassV2 - Great
Multi-core:
- MSM DCSV - Great, not common
- LulzactiveQ - Good
- Intelliactive - Good
- Interactive/InteractiveX - Great
- Ondemandplus - Great
- Darkness - Great
- Nightmare - Great
- Yankactive - Great
- Ondemand/OndemandX - Stock, Best
- Pegasus(q/d) - Best
- SmartassV2 - Great
- Wheatley - Good
- Hotplug/HotplugX - Good
- NeoX - Great
- HYPER - Best
- ZZMove/ZZmanX - Requires tuning, use optimized or default profile
- Dancedance - Good
For gaming:
Single-core:
- Interactive/InteractiveX - Best
- Performance - Great
- Ondemand/OndemandX - Great
- SmartassV2 - Best
Multi-core:
- Lionheart/LionheartX - Best
- Dancedance - Great
- Intelliactive - Great
- Yankactive - Good
- NeoX - Great
- Interactive/InteractiveX - Best
- SmartassV2 - Great
- Pegasus(Q/D) - Best
- Ondemand/OndemandX - Great
- HYPER - Best
- Performance - Great
- LulzactiveQ - Best
- Intellidemand - Good
- ZZMove/ZZmanX - Requires tuning, use gaming or performance profile
Other CPU Governors not mentioned in the recommended section are either not used by people anymore or they are not suited for most people or have been removed from kernels.
Why change your phones I/O Scheduler?
Most phone manufacturers keep your phones I/O Schedulers locked so users are unable to modify any values which could change the performance of your phone. However, once your phone is rooted, you can change these values allowing the potential to boost your phones performance and even slightly increase battery life. Here is a thorough guide on all of the common i/o schedulers.
What is an I/O Scheduler:
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.
Which schedulers are available?
CFQ
Deadline
VR
Noop
Anticipatory
BFQ
FIOPS
SIO (Simple)
Row
ZEN
Sioplus
FIFO
Tripndroid
Descriptions:
Anticipatory:
Two important things here are indicative of that event:
- Looking on the flash drive is very slow from boot
- Write operations while at any time are processed, however, be read operations preferred, ie, this scheduler returns the read operations a higher priority than the write operations.
Benefits:
- Requests of read accesses are never treated secondarily, that has equally good reading performance on flash drives like noop.
Disadvantages:
- Requests from process operations are not always available
- Reduced write performance on high-performance hard drives
- Not very common in most kernels (or even phones these days)
CFQ:
The CFQ - Completely Fair Queuing - similar to the Dead Line maintains a scalable continuous Process-I/O, the available I / O bandwidth is fairly and evenly shared to all I / O requests to distribute. It creates a statistics between blocks and processes. With these statistics it can "guess" when the next block is requested by what process, each process queue contains requests of synchronous processes, which in turn is dependent upon the priority of the original process. There the V2 version has some fixes, such as I / O request improvements, hunger fixes , and some small search backward integrated to improve responsiveness.This is the default IO scheduler for Samsung smartphones.
Benefits:
- Has a well balanced I / O performance
- Excellent on multiprocessor systems
- Easiest to tune.
- Best performance of the database after the deadline
- Regarded as a stable I/O scheduler
- Good for multitasking
Disadvantages:
- Can make your phone lag when multitasking between intensive applications
- 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
Deadline:
This scheduler has the goal of reducing I / O wait time of a process of inquiry. This is done using the block numbers of the data on the drive. This also blocks an outlying block numbers are processed, each request receives a maximum delivery time. This is in addition to the Governor BFQ, it is very popular and is in many well known kernels.
Benefits:
- It is 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
- Like noop, it is a good scheduler for solid state/flash drives
- Good for light and medium multitasking workloads
Disadvantages:
- If the phone is overloaded, crashing or unexpected closure of processes can occur
- Bad battery life if doing a lot of multitasking
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. It is sometimes used by default for custom roms and custom kernels
Benefits:
- Faster UI navigation and better overall phone experience
- Faster boot times and app launch times
- Possibly better battery life
Disadvantages:
- Slower write speeds
- Not a scheduler for benchmarking
- Some intensive applications like games could slow down your phone
SIO (Simple):
It aims to achieve with minimal effort at a low latency I / O requests. Not a priority to put in queue, instead simply merge the requests. This scheduler is a mix between the noop and deadline. There is no conversion or sorting of requests.
Benefits:
- It is simple and stable.
- Reliable I/O scheduler
- 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
Noop:
The noop scheduler is the simplest of them. It is best suited for storage devices that are not subject to mechanical movements, such as our flash drives in our phones use to access the data. The advantage is that flash drives do not require rearrangement of the I / O requests, unlike normal hard drives. the data that come first are written first. It's basically not a real scheduler, as it leaves the scheduling of the hardware.
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
- Does great in benchmarks
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
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. It is a very good scheduler with elements of the deadline scheduler. It is the best for MTD Android devices. Vr can make the most of the benchmark points, but it is also an unstable scheduler. Sometimes the scores fluctuate below the average, sometimes it fluctuates above the average.
Benefits:
- Generally excels in random writes.
Disadvantages:
- Performance variability can lead to different results (Only performs well sometimes)
- Very often unstable and unreliable
BFQ:
Instead requests divided into time segments as the CFQ has, on the BFQ budget. The flash drive will be granted an active process until it has exhausted its budget (number of sectors on the flash drive). The awards BFQ high budget does not read tasks. BFQ has received many updates to the scheduler and the performance is consistently improving.
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.
- Slower UI navigation
ZEN:
Based on the VR Scheduler. It's an FCFS (First come, first serve) based algorithm. It's not strictly FIFO. It does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ones. Other than that, pretty much the same as no-op.
Benefits:
- Well rounded IO Scheduler
- Very efficient IO Scheduler
- More stable than VR, mainly because it doesn't really behave like VR.
- Relatively battery friendly
Disadvantages:
- Not found in all kernels
Sioplus:
Based on the original Sio scheduler with improvements. Functionality for specifying the starvation of async reads against sync reads; starved write requests counter only counts when there actually are write requests in the queue; fixed a bug).
Benefits:
- Better read and write speeds than previous SIO scheduler
- Good battery life
Disadvantages:
- The same as SIO scheduler
- Not found in all kernels
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.
Benefits:
- Achieves high read and write speeds in benchmarks, usually performs the best
- Faster app launching time and overall UI experience
- Good battery life
- Low impact to system performance
Disadvantages:
- Not very common in most kernels
- Not the most responsive IO scheduler (Lags in UI)
- Not good for heavy multitasking
FIFO (First in First Out):
A relatively simple io schedulers that does what has been described. It is also known as FCFS (First come first serve) but this really isn't true. It does basic sorting; sorting the processes according to the appropriate order and nothing else. In other words, it is quite similar to noop.
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
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)
- Relatively battery friendly
Disadvantages:
- Not found in all kernels
- Performance varies between different devices (Some devices perform really well)
Recommended IO schedulers:
For everyday usage:
- SIO (My personal favourite)
- NOOP
- CFQ (Forth choice)
- Deadline
- ROW
- Tripndroid (Third choice)
- ZEN (Second choice)
For battery life:
- SIO (Third choice)
- FIOPS (Second choice)
- NOOP (First choice)
- Tripndroid
- ROW (Forth choice)
- FIFO
For gaming:
- Deadline
- CFQ
- SIO (First choice)
- Tripndroid (Second choice)
- ZEN (Third choice)
- BFQ
- ROW
- FIOPS
For performance(Benchmarking):
- NOOP
- Tripndroid (Third Choice)
- SIO
- Deadline (Second choice)
- FIOPS (First choice)
For multitasking:
- BFQ (First choice)
- Deadline (Second choice)
- CFQ (Second choice)

My man doing big things bro! Thank you so much we edge users desperately needed this.... :good::good::good:

Thanks bro...for all u fkin do for us

Nice, you managed to fix the ram issue? Ah I see you've added extra tcp, muh westwoods

EDGE USERS THANK YOU!!
Edge users....please make sure you thank this man for his help. He spent a lot of time getting this thing to work for us. He had to use testers since he doesn't have the edge to test on, and believe me, it was flash and pray.
He stuck with us when he didn't have to, so let's show some appreciation here since he's pretty much the only one working on kernels for our devices.
Sent from my SM-G925T using Tapatalk

You're awesome man! Gonna flash this as soon as I can, Thank you for your hard work for us Edge users!

Nice work bro.
That is dedication making a kernel for a device you don't even own.
Let's see some appreciation here people. This guy is making things happen!

Damn awesome of you to do this! I'll be hooking up on V2 hopefully tomorrow as well as this!

Glad everyone is happy. I'm currently building V2....
Sent from my SM-G920T using XDA-Developers mobile app

The Sickness said:
Glad everyone is happy. I'm currently building V2....
Left you a Double Thanks on the Edge Forum. Will be checking in here from now on. Thanks again
Click to expand...
Click to collapse

The Sickness said:
Glad everyone is happy. I'm currently building V2....
Sent from my SM-G920T using XDA-Developers mobile app
Click to expand...
Click to collapse
Hey bro what app do you use for xda?

slickrick54 said:
Hey bro what app do you use for xda?
Click to expand...
Click to collapse
XDA Premium
Sent from my SM-G920T using XDA-Developers mobile app

The Sickness said:
Glad everyone is happy. I'm currently building V2....
Sent from my SM-G920T using XDA-Developers mobile app
Click to expand...
Click to collapse
You are the man a lot of dedication for all u do for us users especially the edge users being u don't have the device and it was fast lol hope they appreciate it I'm gonna still say thanks bro Bro is this the same kernel in your rom ? @The Sickness

Wow. Just flashed on xtresto tmobile edge and am now permissive. Great s**t.

genuine55 said:
You are the man a lot of dedication for all u do for us users especially the edge users being u don't have the device and it was fast lol hope they appreciate it I'm gonna still say thanks bro Bro is this the same kernel in your rom ? @The Sickness
Click to expand...
Click to collapse
No...a little different. I changed some voltage tables that were causing reboots for some folks.
Sent from my SM-G920T using XDA-Developers mobile app

The Sickness said:
No...a little different. I changed some voltage tables that were causing reboots for some folks.
Click to expand...
Click to collapse
Cool thanks

This one is even more different...
Sent from my SM-G920T using XDA-Developers mobile app

The Sickness said:
This one is even more different...
Click to expand...
Click to collapse
Lol thanks for the tease i know it's loaded lol :highfive: