Database Develop

[APP]LGP880 Booster v1.5.1 (ROOT)

This application was tested on JB (Android 4.1.2) and requires "root" permissions.
None of the settings are permanent. Default values will be restored when you restart your phone.
Download link: http://www.tazetaze.com/?dl_id=8 (53 KB)
LG Optimus 4X decreases CPU frequency after battery temperature reaches 43 °C to cool the device.
If you play a game for a long time, battery temperature reaches 43 °C rapidly and the game starts to lag because of frequency decrease.
This application sets the Tegra3 "temp_throttle_skin", CPU governor and GPU frequency values according to your preferences when you switch "Boost" on.
So you can play games with higher frequencies and more CPU cores without being effected by the heat increase.
Boost Preferences
Temperature threshold (temp_throttle_skin) value can be set to 46, 48 or 50 °C.
CPU governor value can be set to interactive (default), ondemand or performance.
GPU frequency (3D and 2D) value can be set to 200 MHz (default value), 330 MHz, 380 MHz or 416 MHz.
Your device may feel hotter than before after you set "Boost" on and play a game for a long time.
Other Functions
It's possible to see the CPU usage and frequency by setting the "Show CPU Usage" switch on. This has the same effect as enabling "Show CPU Usage" setting from the hidden menu.
If you enable "Unlimited Temp. Charging", you can continue to fast charge even if slow charge is activated because of high temperature.
New function: If you set "Keep Brightness" switch to "On", LCD brightness will be kept at the level you specify at the "LCD Brightness" preference. Temperature rise will not lower the brightness.
"Keep Brightness" function does not work properly for high temperature conditions.
Although brightness seems to stay at the level you specify in the notification tray, it is actually decreased when temperature rises.
This side effect occurs only when you play games for a long time with high temperature levels.
Please follow the new versions of "Tegra Overclock" application for a proper way of avoiding LCD brightness cutter.
Click to expand...
Click to collapse
WARNING
Use at your own risk.
Turn "Boost" off after you play your game.
Battery will drain faster when CPU governor is set to "performance".
Overheating may damage your phone hardware.
The code to change CPU governor was taken from the "No-frills CPU" project. Thanks to Luca Santarelli for making his project open source.
Shell commands to change GPU frequencies was taken from the "Tegra Overclock" application.
{
"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"
}
Release Notes
v1.5.1
If the kernel supports GPU frequency higher than 416 MHz, this maximum frequency can be selected in the GPU Frequency preference.
v1.5.0
"Keep Brightness" switch was added. Now you can keep brightness at the level you want regardless of phone temperature.
Note: This function requires that "Brightness Service" keeps running. If you kill the service with a task killer application, brightness will not be kept.
v1.4.0
"ondemand" CPU governor option was added to preferences.
Current CPU temperature is displayed under "Temperatures" section.
Minor user interface changes.
v1.3.0
"Unlimited Temp. Charging" functionality was added.
v1.2.3
Minor bug fixes
416 MHz was added to GPU frequencies list
v1.2.1
"echo 'Y' > /sys/module/tegra3_clocks/parameters/detach_shared_bus" command was added to program startup to prevent crashes that happened when GPU frequency was set.
v1.2.0
GPU frequencies for Boost can be set from "Boost Preferences" section.
v1.1.0
Temperature threshold and CPU governor values for Boost can be set from "Boost Preferences" section.
v1.0.0
First release

FC on kholk's CM10.1, ups!

I think this is for stock kernel only.

just a small tip from me, use more than 48°C for skin temp. i'd suggest at least 50.
'cause the throttle will kick in even before the temp_throttle_skin value is reached.
also performance gov is not the very best choice IMO. it produces too much heat, 'cause it would be enough to run @ 800MHz (or another freq, just as an example)
But nice work anyways

laufersteppenwolf said:
just a small tip from me, use more than 48°C for skin temp. i'd suggest at least 50.
'cause the throttle will kick in even before the temp_throttle_skin value is reached.
also performance gov is not the very best choice IMO. it produces too much heat, 'cause it would be enough to run @ 800MHz (or another freq, just as an example)
But nice work anyways
Click to expand...
Click to collapse
Thanks for your precious comments.
So you recommend to set 50 °C for temp_throttle_skin, no change for CPU governor and 800 MHz for maximum CPU frequency.
Is that right?

postacik said:
Thanks for your precious comments.
So you recommend to set 50 °C for temp_throttle_skin, no change for CPU governor and 800 MHz for maximum CPU frequency.
Is that right?
Click to expand...
Click to collapse
He was more suggesting another governor - interactive is fine, in my opinion.

someth1ng said:
He was more suggesting another governor - interactive is fine, in my opinion.
Click to expand...
Click to collapse
Interactive is the default CPU governor and is fine on JB but it really helped to boost games on ICS.
Maybe I can make CPU governor change optional.

New version (v1.1.0) was released.
CPU governor and threshold temperature settings can be adjusted under the "Boost Preferences" section.

Thanks for your precious comments.
So you recommend to set 50 °C for temp_throttle_skin, no change for CPU governor and 800 MHz for maximum CPU frequency.
Is that right?
Click to expand...
Click to collapse
partly yes
- I'd use at least 50°C for temp_throttle_skin.
- CPU gov, maybe ondemand, it "likes" higher frequencies --> good for gaming
- and no, please do not cap the freq it was an example of what is bad at performance governor. (800MHz actually needed, but it is forced to keep @1.7/1.5GHz)
but you could increase the min freq during gaming to 500MHz or something. that way the quad core stays online and doesn't change to LP mode. this can slightly improve the performance a bit

Can you suggest if i should add gpu frequency change option for boosting as in the Tegra Overclock application?
I would be glad if you have an optimum gpu frequency to play notoriously lagging games without any problems.
Some of my friends suggest setting gpu frequency to 416 mhz to play need for speed and real racing. Is that the right frequency?
Sent from my LG-P880

Nice idea..
Great idea for our 4X! :good:
will test it soon..
But, i think this should be moved to themes and apps..

New version (v1.2.0) was released.
Now you can set GPU frequencies to use for Boost mode.

Can a moderator move this thread to "themes and apps" section if that's the right place for an application?

postacik said:
Can you suggest if i should add gpu frequency change option for boosting as in the Tegra Overclock application?
I would be glad if you have an optimum gpu frequency to play notoriously lagging games without any problems.
Some of my friends suggest setting gpu frequency to 416 mhz to play need for speed and real racing. Is that the right frequency?
Sent from my LG-P880
Click to expand...
Click to collapse
well, the N7 uses 416 by default. this should be a pretty good value, regarding performance AND battery.
if you want more battery life, i'd suggest 330 MHz.
for really, really hardcore gaming 520 (564/600) MHz. but this will cause heat, too...
postacik said:
Can a moderator move this thread to "themes and apps" section if that's the right place for an application?
Click to expand...
Click to collapse
i'm on it

New version (v1.2.1) was released.
A missing setting caused the phone to freeze in version 1.2.0.
This problem was solved in v1.2.1.
Please uninstall v1.2.0 and install v1.2.1 to avoid crashes.

force close on rooted ICS when opening.

Emmanuel2000 said:
force close on rooted ICS when opening.
Click to expand...
Click to collapse
Which version? Since I have stock JB installed I don't have a chance to test it on ICS.

postacik said:
Which version? Since I have stock JB installed I don't have a chance to test it on ICS.
Click to expand...
Click to collapse
United Emirates
ICS 4.0.3 V10E Open AME
rooted with stock rom.

Emmanuel2000 said:
United Emirates
ICS 4.0.3 V10E Open AME
rooted with stock rom.
Click to expand...
Click to collapse
Can you try again with the attached apk?

where can i get latest version??
---------- Post added at 06:39 PM ---------- Previous post was at 06:25 PM ----------
postacik said:
Please do not use version 1.2.0. It makes the phone freeze when Boost switch is clicked. Install v1.2.1 instead.
Release Notes
v1.2.1
"echo 'Y' > /sys/module/tegra3_clocks/parameters/detach_shared_bus" command was added to program startup to prevent crashes that happened when GPU frequency was set.
v1.2.0
GPU frequencies for Boost can be set from "Boost Preferences" section.
v1.1.0
Temperature threshold and CPU governor values for Boost can be set from "Boost Preferences" section.
v1.0.0
First release
Click to expand...
Click to collapse
Where can i get latest downloads??
the link given is downloading old ver......

Chaos Kernel users' thread—tips, experiences, and NXTweaks settings

Hello everyone.
A few people in the Chaos Kernel development thread suggested that there should be a thread in the general section devoted to the use as opposed to the development of this great kernel.
For those who don't know, Chaos is a CAF kernel developed by @neobuddy89 for use with Cyanogenmod. Rather than being a place for discussing Chaos's pros and cons with respect to all the other great custom kernels available, this thread is for sharing the NXTweaks settings that we have found work well for us, whether this is with a view to achieving great performance, great battery life, or some balance of the two.
My own settings are based roughly on @neobuddy89's own settings that he posted several pages back on the dev thread. I'm looking for a solid balance between performance and battery, and I find that these settings deliver both (at least vs stock CM kernel).
Every setting not mentioned is left at the default setting for the built-in 'balanced' profile.
CPU:
PE WQ: enabled
OC: 2.496GHz
Gov: Intelliactive
Sleep gov: Conservative
IO: FIOPS
Sleep IO: ROW
Hotplug: Intelli HotPlug (eco mode disabled)
Colour Profile: Piereligio TrueRGB V7
Fast Charge: Auto
Cron zipalign task enabled.
What do you guys and gals think? (As an aside, I used to be able to oc to 2.576GHz on Chaos 10.2 with earlier CM11 M builds, but since Chaos 11 with M4, 5 and 6, I get an instant kernel panic as soon as I enable this. I'm going to post on the dev thread with my last kmsg when I hit ten posts. I don't talk much!) Specifically, what's your experiences with FIOPS vs ROW?
I find that this gives me an utterly smooth UX across every app, combined with enough battery to get me from 0700 to late in the evening. Sorry I don't have screenshots or SO states (or benchmarks) but I prefer to use the entirely subjective criterion of whether my phone *feels* fast and long-lived.
Hope people like this thread. Also, I'm new here, so sorry if I've got any etiquette wrong.
Edit: I should've said, I'm running a D821 N5 with CM11 M6, and the latest Chaos 12 nightly. I was on CM nightlies but I got sick of it.

Kernel: 12.0 5/12
Rom: SOKP MS-1
Profile based: Balanced
CPU:
PE WQ: enabled
UC: 1.728 GHz
UV: -20 MHz
Sleep Freq: 1.497 GHz
Boost Freq: 1.267 GHz
Sync Freq: 1.574 GHz
Gov: Intelliactive
Sleep gov: Intelliactive
IO: FIOPS
Sleep IO: Row
GPU: 320 Mhz
Polling: 14 ms
Hotplug: Cyanogen
DT2W: Enabled
Power key toggle: Enabled
Sound: Custom
Headphone: 260
Speaker: 262
Attenuation: 39
Mic: 260
Camera: 258
Colour Profile: Piereligio TrueRGB V7 / Vivid
Gentle Fair Sleepers: Disabled
Dynamic Fsync: Enabled
Fast Charge: Auto
Cron: All enabled
GPS: North America
Thanks for creating the thread =]

Kernel: Always latest.
Rom: AICP RC-4.0
PE WQ: Enable
CPU Freq: All Default.
UV: -25mV (from Kernel Tweaker)
Gov: Intelliactive.
Sleep gov: Conservative
IO: FIOPS
Sleep IO: ROW
Hotplug: Intelli-Hotplug (Eco Mode Disable)
GPU: Default
KSM: All Disable
Sound: Quality
Color Profile: Piereligio TrueRGB V7
Color Tweak: Stock
Dynamic Fsync: Enable
Cron Jobs: All Enable except Update Ad-Block.
This is my favourite settings and it's running great

fluther said:
My own settings are based roughly on @neobuddy89's own settings that he posted several pages back on the dev thread. I'm looking for a solid balance between performance and battery, and I find that these settings deliver both (at least vs stock CM kernel).
Click to expand...
Click to collapse
I have changed back to default settings of default profile with KSM, ZRam (for testing), Quality Sound, TrueRGB Color profile. :fingers-crossed:

Trying to change color profile display with nxtweaks but I'm not able to apply it
Used Franco display control and seems to apply correction Piereligio_v7
CM 11 build 05/12 and chaos latest nightly
Anyone?
Inviato dal mio Nexus 5 utilizzando Tapatalk

NXtweaks:
max CPU freq: 1.574
max CPU susp freq: 1.190
min CPU susp freq: 300
boost duration: 0ms
input event boost duration: 0ms
input event boost freq: 1.190
sync threshold: 1.190
cpu governor: interactive
cpu sleep governor: conservative
io sched: fiops
io sleep sched: fiops
hotplug: MSM
boosted cpus: 1
max cpus online: 2
max gpu freq: 200
polling interval: 30ms
gpu governor: MSM
dirty ratio: 20
dirty background 5
set ZRAM to 200MB
swappiness: 80
freq throttle: 65
freq throttle suspend: 60
core throttle: 70
core throttle suspend: 70
TRICKSTER MOD (beta tester app version):
tcp congestion: westwood
read ahead buffer size: 384
GOVERNOR (interactive):
above: 20000
go_hispeed_load: 99
hispeed_freq: 652800
min_sample_time: 20000
sync_freq: 300000
target_loads: 90
timer_rate: 20000
timer_slack: 40000
up_threshold_any_cpu_freq: 960000
up_threshold_any_cpu_load: 90
multicore power saving: 2
gpu max freq: 200
UNDERVOLTS:
300: -65
422: -65
652: -65
729: -65
960: -65
1574: -65
all the other: -50

giajp said:
dirty ratio: 20
dirty background 5
set ZRAM to 200MB
swappiness: 80
Click to expand...
Click to collapse
80 swappiness?? Any diff?

neobuddy89 said:
80 swappiness?? Any diff?
Click to expand...
Click to collapse
I don't know, try it. I always use this recommended settings by Faux
Sent with my Google Nexus 5

It seems that some of you are underclocking and undervolting quite aggressively. How does this work out for you in terms of battery? And how much does performance suffer?
@neobuddy89 is there any particular reason why you use KSM and ZRAM, given that the N5 has 2gb of ram already? Also, what's your take on the various governors and schedulers?

With the chaos is the only one situation when the performance doesn't suffer so much (try and give me your opinions). Battery incredible
{
"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"
}
Half WiFi, half data
Edit: @fluther i think the ZRAM, on CM11 is indispensable. The memory leak is still too strong, unlike stock/aosp
Sent with my Google Nexus 5

giajp said:
With the chaos is the only one situation when the performance doesn't suffer so much (try and give me your opinions). Battery incredible
View attachment 2744321
Half WiFi, half data
Edit: @fluther i think the ZRAM, on CM11 is indispensable. The memory leak is still too strong, unlike stock/aosp
Sent with my Google Nexus 5
Click to expand...
Click to collapse
Not to offend.....seriously.....but that is OK battery life..... And with all that under clocking and volting..... You've basically shown it is unnecessary. You've gained little, if anything doing it....and I imagine your performance must be suffering.
I think realistically.... You can under volt or under clock the phone into the ground and at best gain only minutes of screen time....and an hour or 2 overall total life.
Just my experience with it. Never touch clock and volts now.....there's no significant change to battery, yet performance degrades the lower you go.
My 2 cents. ?

lezzi said:
Trying to change color profile display with nxtweaks but I'm not able to apply it
Used Franco display control and seems to apply correction Piereligio_v7
CM 11 build 05/12 and chaos latest nightly
Anyone?
Inviato dal mio Nexus 5 utilizzando Tapatalk
Click to expand...
Click to collapse
Yeah, I have the same problem. Not sure why. It used to work just fine when I first flashed the kernel. Let me know if you figure it out.

Hi everyone. I said in the OP that I'm not terribly interested in benchmarks, and while this holds true, I though I'd share this great antutu result. However, I've a question: why the poor integer performance? @neobuddy89 ?
Sent from my Nexus 5 using XDA Premium 4 mobile app

fluther said:
Hi everyone. I said in the OP that I'm not terribly interested in benchmarks, and while this holds true, I though I'd share this great antutu result. However, I've a question: why the poor integer performance? @neobuddy89 ?
Sent from my Nexus 5 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Maybe because we use our own hotplug engine? Someone with more Antutu test knowledge might able to help.

Sorry, I should've said this was using intelliactive and intellihotplug.
Sent from my Nexus 5 using XDA Premium 4 mobile app

guys, got really frustrated with DT2WAKE issue, it could work flawlessly all day long, and all of a sudden it fails to wake the device up.
if i wait about one minute without using the power button, dt2wake works again and keep working for some time - then it happens again.
it happens on freshly installed and wiped system with all the latest nightlies of Chaos kernel + pacman rom.
from DEFAULT SETTINGS i only lower CPU freqs to 1.7
PE WQ on
GPU 320, polling 30ms
MSMhotplug with 2 cores
DT2W enable
color profile TrueRGB
vibrator strength 0
what can POSSIBLY relate to WAKE issue, any apps/settings? maybe nxtweaks are being killed in background? really annoying, especially while driving.
suppose to wake and get to dialer without looking and with one simple action, look at the phone once to find contact and dial.
and its like: look at the phone to check if DT2wake worked, if not try again, then slide the phone in palm to use the power button etc. etc.
i rely on this function and really need it working all the time.

oo0 said:
guys, got really frustrated with DT2WAKE issue, it could work flawlessly all day long, and all of a sudden it fails to wake the device up.
if i wait about one minute without using the power button, dt2wake works again and keep working for some time - then it happens again.
it happens on freshly installed and wiped system with all the latest nightlies of Chaos kernel + pacman rom.
from DEFAULT SETTINGS i only lower CPU freqs to 1.7
PE WQ on
GPU 320, polling 30ms
MSMhotplug with 2 cores
DT2W enable
color profile TrueRGB
vibrator strength 0
what can POSSIBLY relate to WAKE issue, any apps/settings? maybe nxtweaks are being killed in background? really annoying, especially while driving.
suppose to wake and get to dialer without looking and with one simple action, look at the phone once to find contact and dial.
and its like: look at the phone to check if DT2wake worked, if not try again, then slide the phone in palm to use the power button etc. etc.
i rely on this function and really need it working all the time.
Click to expand...
Click to collapse
As I told over PM, will clean up that code next week which may help..
Sent from my Nexus 5 using XDA Free mobile app

@neobuddy89, thanks! it's an old post. also, i guess, no one else has that issue. good thing - i have no SODs like many people reported with any of your builds. tested Furnace kernel for a while, dt2wake works perfectly, but having better battery with Chaos.

Anyone have a high performance set up that can be used for daily use that they want to share?
Sent from my Nexus 5 using XDA Premium 4 mobile app

JLO155 said:
Anyone have a high performance set up that can be used for daily use that they want to share?
Click to expand...
Click to collapse
Interactive governer,
sleep governor conservative
CPU 300-2500mhz
Hotplug see picture
After 2 load circles the battery consumption and performance is amazing (latest AICP nightly) with a sot time of ~5 hours with auto brightness. Regards, Matt

[KERNEL] EOL Twisted-V7.1 {DOL1-COF8 Sources} [GRAPHITE,Ofast,Frandom] April 3, 2016

{
"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....

[KERNELS]{W8,T} Twisted V11.5 [6.0.1 MM] Synaspe*SaberMod 7.0*OC/UC* 12/14/16

{
"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:

Pure Nexus/Elementalx : CPU Throttling (Low Battery)

I am running the latest version of Pure Nexus, with the latesst version of the Elementalx Kernel. I have also installed the EX Kernel Manager. This is my first attempt at a custom kernel and it is working very well.
The only 'issue' I am having or the last hurtle I am trying to get over is the CPU throttling at low battery power. I haven't done extensive testing but in the small amount of testing I have done it seems that when the phone gets around 40%, the Max CPU speed reported in the EX Kernel Manager drops to 1958MHz, with all the cores still enabled. It will remain that way until I charge up the phone above approx 40%, and at that point it will go back to 28800MHz (max value).
I have tried this https://forum.xda-developers.com/nexus-6/development/mod-disable-throttling-battery-low-t3440814 but it doesn't seem to work for me.
Is there a way to achieve this through Elementalx itself. I believe if I change the CPU Gov. to Performance the CPU returns to its maximum value of 28800 MHz even under 40% but using the Elementalx Gov. yields such a good mix of performance and battery life I would rather keep it.
Any thoughts or suggestions welcome.
Thanks.

Just looking at it again...... I'm hitting a max CPU frequency of 1985 MHz earlier than expected. It has happened at 50% battery usage. I can also confirm that changing the Gov. to Performance will up the CPU to the expected, max, value of 2880MHz.

I have discovered a couple things..... First, throttling, from the posts I have read means ' Throttling is turning cores off at lower percentages and keeping frequencies down, not at regular.' So the issue that I am experiencing is not throttling entirely as I have all 4 cores working throughout the battery range. What I do have happening and want to resolve is the Max CPU value, in Ex Kernel Manager changing from 28800 MHz, which is the maximum CPU frequency I have set, to 1958 MHz when the device battery drops below approximately 45%. Second... Changing the CPU Gov., while the battery is under 40% (1958MHz), will increase the CPU frequency back to 28800MHz until the phone drops another battery percentage, which will trigger the underclock (1958Mhz).

EXKM - Tools- User Settings Navigate to file sys/devices/qcom,bcl.39/mode and set "disabled".
And, ofc, edit threshold (99) in thermal conf file.

nemanja066 said:
EXKM - Tools- User Settings Navigate to file sys/devices/qcom,bcl.39/mode and set "disabled".
And, ofc, edit threshold (99) in thermal conf file.
Click to expand...
Click to collapse
Phone was at 43% and running at an underclocked speed of 1958 MHz. Made the changes in EXKM to the Mode file and enabled the 'Apply on Reboot'. Rebooted the phone. Once booted took a look at EXKM and the CPU speed was still underclocked at 1958 MHz. Check the Temp and it was at 45. Checked EXKM and the CPU temp threshold is set for 60. Didn't change the ofc value. I don't want to disable the thermal as I don't want to damage the hardware accidentally. I also couldn't find the value. It isn't in the Mode file. Where could I find that? Is the ofc file required as well to allow this method to work?
I will continue to tinker.
Thanks for the reply and your help.

ofc= of course. [emoji12]
For me, work ok, only edited thermal conf file (cpufreq, hotplug, gpu threshold 100 threshold clear 99). Please wait some time to.phone cooling down (sleep phone 10-15 minutes) and open EX Manager and see again. Sometimes does not change max freq value at the begining. At least, i had this situation.
Sent from my Nexus 6 using Tapatalk

nemanja066 said:
ofc= of course. [emoji12]
Click to expand...
Click to collapse
Lol! Oops.....
For me, work ok, only edited thermal conf file (cpufreq, hotplug, gpu threshold 100 threshold clear 99). Please wait some time to.phone cooling down (sleep phone 10-15 minutes) and open EX Manager and see again. Sometimes does not change max freq value at the begining. At least, i had this situation.
Click to expand...
Click to collapse
Thanks for the reply. I'm getting closer. I am able to run at 28800 Mhz until 20% battery life and then it underclocks to 1958 MHz on all cores. This is definitely a step forward. Below are the three sections you referred to, CPUFreq, HotPlug, and GPU. This is the modified file. My understanding of what this configuration accomplishes is that at 5% battery power the CPU will throttle back (underclock) to conserve battery power. Unfortunately this isn't happening.... yet.
Any other ideas on why this isn't working as expected? Is there another part of the file that needs to be changed?
Also is there a resource that explains what each line in these files do? I couldn't locate one.
Thanks!
:good:
sampling 5000
[BAT-SOC-CPUFREQ]
algo_type monitor
sensor soc
sampling 5000
thresholds 95
thresholds_clr 94
actions cpu
action_info 2649000
[BAT-SOC-HOTPLUG]
algo_type monitor
sensor soc
sampling 5000
thresholds 90 92
thresholds_clr 89 91
actions hotplug_3 hotplug_2
action_info 1 1
[BAT-SOC-GPU]
algo_type monitor
sensor soc
sampling 5000
thresholds 88 90 95
thresholds_clr 89 89 94
actions gpu gpu gpu
action_info 600000000 389000000 300000000

@monteie2016
I find your shamu thermal conf file a bit strange. I have a pure nexus and elementalx and it's not like that. All you need to edit in this file (with text editor) is set the thresholds to 100 a thresholds_clr at 99.
Thresholds is the battery percentage at which the throttling occurs (at 0% (100-thresholds))
Thresholds_clr is the battery percentage at which the throttling clear (at 1% (100-threshold_clr)).
In practice, this will never happen because in that time your device is already dead.
I will upload a screenhoot of EXKM dashboard to see max freq in my case when battery was bellow 20%. It's stay on 2.6 Ghz.

Can you also post the CPU, GPU, and hotplug values. I would like to see how yours is configured.
Thanks
:good:

monteie2016 said:
Can you also post the CPU, GPU, and hotplug values. I would like to see how yours is configured.
Thanks
:good:
Click to expand...
Click to collapse
Also, I have an older version of the elementalX 4.23 as you can see on screenshot (with july security patches) , because the PureNexus rom does not have august and september kernel patches.
Here is SS thermal conf:
[emoji106] [emoji482]
{
"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"
}
Sent from my Nexus 6 using Tapatalk

Couple of things...... Above you are showing me a status from EXKM at 62% battery. I don't have and underclock issue anywhere between 100% and 20%. When the battery life drops below 20% is where I get the issue (Underclocks to 1958Mhz from 2880Mhz).
Here is what my file looks like
sampling 5000
[BAT-SOC-CPUFREQ]
algo_type monitor
sensor soc
sampling 5000
thresholds 100
thresholds_clr 99
actions cpu
action_info 2649000
[BAT-SOC-HOTPLUG]
algo_type monitor
sensor soc
sampling 5000
thresholds 100 100
thresholds_clr 99 99
actions hotplug_3 hotplug_2
action_info 1 1
[BAT-SOC-GPU]
algo_type monitor
sensor soc
sampling 5000
thresholds 100 100 100
thresholds_clr 99 99 99
actions gpu gpu gpu
action_info 600000000 389000000 300000000
I should also mention that I have disabled BCL, /sys/devicds/qcom,bcl.39/mode and changed the value to disabled.
I have attached two images. One is the battery at less than 20% and what I am seeing for CPspeed (underclock) and the other is above 20%.

Off topic thoughts @monteie2016
What you had asked for was posted in the previous post. The additional information was provided additionally. But you jumped on the extra info. And not one time in this thread have you "thanked" (thumbs up) the only person who had been trying to help you.

I did thank nemanja066 for his post on 20th September 2017, 04:51 PM (thanks button in thread) and my reply on September 23rd had a thanks and a thumbs up.
Also is there a resource that explains what each line in these files do? I couldn't locate one.
Thanks!
:good:
Click to expand...
Click to collapse

[emoji106] No throttling yet.
I will post SS for battery bellow 15%, too.
Sent from my Nexus 6 using Tapatalk

@monteie2016
Looks like a bug with the aroma installer. Try again with flashing kernel in recovery and then in aroma set max freq cpu to 3033MHz. After flashing, reduce the frequency to the desired one in EXKM. After that, it might be fine, and the freq can be reduced only due to the increase in temperature, which is quite OK. When the phone cools down, freq will go back to the old value. If all this fails, then I do not know what to do next.

nemanja066 said:
@monteie2016
Looks like a bug with the aroma installer. Try again with flashing kernel in recovery and then in aroma set max freq cpu to 3033MHz. After flashing, reduce the frequency to the desired one in EXKM. After that, it might be fine, and the freq can be reduced only due to the increase in temperature, which is quite OK. When the phone cools down, freq will go back to the old value. If all this fails, then I do not know what to do next.
Click to expand...
Click to collapse
Thanks for the information. I will take a look at it later. Got busy doing other things
:good:

nemanja066 said:
EXKM - Tools- User Settings Navigate to file sys/devices/qcom,bcl.39/mode and set "disabled".
And, ofc, edit threshold (99) in thermal conf file.
Click to expand...
Click to collapse
Hello, just curious if you can specify the file location of the thermal config file? Thank you for your help.

ozzmanj1 said:
Hello, just curious if you can specify the file location of the thermal config file? Thank you for your help.
Click to expand...
Click to collapse
/system/etc/thermal-engine-shamu.conf
Sent from my Nexus 6 using Tapatalk