Related
What are the differences?
Which one is most power saving?
Had a look around, this guy here seems to explain it pretty well
http://forum.xda-developers.com/showthread.php?t=843406
Hope that helps.
Extracted from governors.txt from my mediafire site ...
CPUFreq governors in the Android Kernel
=======================================
+ performance
The CPUfreq governor "performance" sets the CPU statically to the highest frequency within the borders of scaling_min_freq and scaling_max_freq.
+ powersave
The CPUfreq governor "powersave" sets the CPU statically to the lowest frequency within the borders of scaling_min_freq and scaling_max_freq.
+ userspace
The CPUfreq governor "userspace" allows the user, or any userspace program running with UID "root", to set the CPU to a specific frequency by making a sysfs file "scaling_setspeed" available in the CPU-device directory.
+ ondemand
The CPUfreq governor "ondemand" sets the CPU depending on the current usage. To do this the CPU must have the capability to switch the frequency very quickly. There are a number of sysfs file accessible parameters: sampling_rate, show_sampling_rate_min, up_threshold, ignore_nice_load, sampling_down_factor.
+ conservative
The CPUfreq governor "conservative", much like the "ondemand" governor, sets the CPU depending on the current usage. It differs in behaviour in that it gracefully increases and decreases the CPU speed rather than jumping to max speed the moment there is any load on the CPU. This behaviour more suitable in a battery powered environment. The governor is tweaked in the same manner as the "ondemand" governor through sysfs with the addition of: freq_step & down_threshold
+ interactive
The CPUfreq governor "interactive" is designed for latency-sensitive, interactive workloads. This governor sets the CPU speed depending on usage, similar to "ondemand" and "conservative" governors. However, the governor is more aggressive about scaling the CPU speed up in response to CPU-intensive activity. The tuneable value for this governor are: min_sample_time & go_maxspeed_load
+ smartass (By [email protected])
The smartass governor is a complete rewrite of the interactive governor. CPU spends much more time at the lower frequencies for improved battery life. It gives the phone an automatic Screen Off profile, keeping speeds at a minimum when the phone is idle.
+ savagedzen (By [email protected])
SavagedZen is a governor based on the Smartass governor. With tweaks to paramaters which control how much and how fast cpu ramps up/down. Main difference versus Smartass is that cpu ramps down not in fixed steps, but based on cpu load heuristics, i.e. when cpu load falls below threshold (min_cpu_load), cpu immediately ramps down to a frequency derived from the measured load.
+ interactiveX (By [email protected])
Modified version of interactive with suspend code which locks at lowest clock speed when screen is off. Has a sleep+awake profile, meaning you don't need to set up manual profiles, it will lock at your minimum frequency during screen off
References:
- https://github.com/android/kernel_common/blob/android-2.6.39/Documentation/cpu-freq/governors.txt
- https://github.com/Savaged-Zen/Savaged-Zen/tree/master/drivers/cpufreq
- http://forum.xda-developers.com/showthread.php?p=12944012
- http://www.ziggy471.com/2010/11/07/smartass-governor-info
The OP question about the most power saving governor has been answered - 'powersave'. My question is - what about SavagedZen vs conservative?
Unfortunately I can not post to dev section, so hopefully stratos will see my post here:
I had stock JVR with semaphore 1.5 (not v) on ext4 and everything was excellent with this brilliant kernel apart from the well known phone fc.
OC/UV was ok: quadrant scores were approx 1900-2400 on conservative cpu gov and 2500-3000 on ondemand gov.
Now, I flashed the 1.6 beta and my system is noticeably slower on *conservative* cpu gov and quadrant scores dropped clearly below 1500. Ondemand cpu gov seems to work ok but as I was alwaus on conservative I can not be abs.sure
I don't know if it is important but using voltage control app to check cpu function I see that:
a) cpu freq is wildly/unpredictably fluctuating with 1.6beta while this was not happening in 1.5 under conservative cpu gov,
and
1b) reported default voltage is different: for example with sema1.5 1200mhz had default 1275, now in 1.6beta without oc module 1000mhz is 1275 but with oc module 1200mhz have 1300mv by default.
Stratos,
could it be that a) something is broken in the new conservative cpu gov? , b) have you changed the default cpu voltage between v1.5 and v1.6beta?
GrNick said:
Unfortunately I can not post to dev section, so hopefully stratos will see my post here:
I had stock JVR with semaphore 1.5 (not v) on ext4 and everything was excellent with this brilliant kernel apart from the well known phone fc.
OC/UV was ok: quadrant scores were approx 1900-2400 on conservative cpu gov and 2500-3000 on ondemand gov.
Now, I flashed the 1.6 beta and my system is noticeably slower on *conservative* cpu gov and quadrant scores dropped clearly below 1500. Ondemand cpu gov seems to work ok but as I was alwaus on conservative I can not be abs.sure
I don't know if it is important but using voltage control app to check cpu function I see that:
a) cpu freq is wildly/unpredictably fluctuating with 1.6beta while this was not happening in 1.5 under conservative cpu gov,
and
1b) reported default voltage is different: for example with sema1.5 1200mhz had default 1275, now in 1.6beta without oc module 1000mhz is 1275 but with oc module 1200mhz have 1300mv by default.
Stratos,
could it be that a) something is broken in the new conservative cpu gov? , b) have you changed the default cpu voltage between v1.5 and v1.6beta?
Click to expand...
Click to collapse
Unfortunately I can not confirm your results. I just load the conservative governor and tested with and without overclocking. No problems here.
During benchmarking due to high load the frequency it's difficult to drop below the max. So, governor should not make the difference.
The uv value was the same in 1.5.0 (1300mv) for 1.2Ghz but it was wrongly displayed as 1275.
Thanks for you feedback. I will let you know if someone else report problems about the conservative governor.
Hey stratos, thanks for the clarification about cpu voltage.
Re cpu gov, I just did a nandroid restore and confirmed that conservative cpu gov works much better in 1.5
Any ideas on how to explore it further? There is definetely something different here.
I mean, its not just quadrant scores, its memento database loading instantly vs seconds of delay under cons cpu gov in 1.5 vs 1.6beta.
I will reflash again l8r tonight.
Anyhow, this kernel rocks! And I love the tun/netfilter module design.
Sent from my GT-I9000 using Tapatalk
Current Release: 12/20/2012(JB)/10/03/2012(GB+ICS)
Important, Please read: There are now two kernel versions starting with 8/10/2012 release, one for GB+limited ICS(no HWA) support and another for the ICS branch with HWA. Changes will be loggged separately for each kernel type. If you see no changelogs specifically for that type, then there's no release made. For example, 8/10/12 for GB is a continuation of the 3/21 release with none of the post-3/21 kernel ICS changes made.
Update 9/21/12: As of 9/21/12, jellybean is officially supported with the JB specific kernels.
First of all, I started this thread to make commenting and tracking easier for the incredikernel releases following Chad's latest release (8/15/2011).
I also wanted to make a distinction between Chad's initial kernels and the ones I've updated since that release and this is one way to do it. Initially I didn't want to do that but now I regretted not splitting sooner.
If you want the changelog for anything prior to my first kernel please refer to:
Chad's Incredikernel thread
Changelog:
11/30/2013 JB 4.3
Android 4.3 support
synced with updates from Android 4.3 Evervolv kernel
04/25/2013 ICS Sense+JB 4.2
dynamic fsync control
WiFi driver updates
Interactive governor updates - see Tinykernel
Entropy Tweaks
Netfilter updates
New sysfs location for fast charge for broader app compatibility - still compatible with latest incredicontrol
FUSE filesystem support
12/20/2012 JB 4.2 ONLY
add back governors that were removed in 12/15
12/15/2012 JB 4.2 ONLY
enabled UHID support
updated msm_fb for 4.2
12/11/2012 JB ONLY
cpufreq: enable overclocking of 1.15Ghz and 1.19Ghz
numerous interactive and ondemand governor tweaks
cpufreq: send uevent when governor changes
ondemand: boost pulse for JB's powerHAL
10/11/2012 JB ONLY
defconfig: several config changes to fix data usage not working
10/06/2012 JB ONLY
defconfig: enable conservative governor by request
10/03/2012 ICS+JB+GB
defconfig: remove rarely used governors and set max frequency to preventing booting higher than 998mhz
lower default hispeed_freq to 614Mhz
cpufreq: interactive: always limit initial speed bump to hispeed_freq
09/21/2012 ICS+JB+GB
ALL: New Interactive governor
ALL: Built with GCC 4.6 toolchain from Google
GB: interactive governor tweaked for battery
ICS+JB: interactive governor tweaked for butter
JB: genlock patched for JB support
JB: new wifi driver for compatibility with JB ROMs
08/11/2012 ICS+GB
KSM wasn't enabled as it should have been in the last build - fixed that - also nothing needs to be done to enable it on GB as it's on by default
08/10/2012 ICS ONLY
fixed data usage features for ICS
added mamarley's fastcharge USB patch to enable fastcharge without needing to unplug the charger
enabled KSM (Kernel Samepage Merging) - still need to enable in CM settings
08/10/2012 ICS+GB
added mamarley's fastcharge USB patch to enable fastcharge without needing to unplug the charger
07/07/2012 ICS ONLY
Merged in multiple driver updates to support HWA (chad0989)
Updated adreno kernel drivers to latest
added xtqta_guid - for ICS' data usage feature, also seems to have resolved stability issues
Added lazy CPU governor
Added back intellidemand
03/21/2012 ICS+GB
Added lazy CPU governor
02/26/2012 ICS+GB
Smartassv2 default governor for sure - doesn't override ramdisk settings though
new governor lagfree - balance between ondemand and interactive
new I/O scheduler SIO
tweaked deadline for better performance
removed CFQ/BFQ schedulers and smartass, conservative, and interactive govenors (still have interactiveX and smartassv2)
01/03/2012 ICS+GB
Tweak intellidemand and interactiveX governors for battery life
Add ZRAM and swap support and add script to toggle ZRAM - see bottom of OP for more info
SmartassV2 default governor again
12/26/2011 ICS+GB
Added faux123's intellidemand governor (thanks faux123!)
Added imoseyon's interactiveX governor (thanks imoseyon!)
Works on GB and ICS currently
interactiveX may not play nicely with ICS so intellidemand is default
Conservative is disabled, let me know if you need it back
12/08/2011 (Chad) ICS+GB
Added ICS support (limited)
11/27/2011 GB
Use ondemand, performance, and conservative governors from the Android Linux 3.0 kernel
Set minimum voltage back to 800 as the voltages will not go below 800 anyway. Anything lower is placebo effect. This is a hardware limitation.
11/14/2011 GB
Update OJ driver
BT fix for newer CM nightlies
WIFI module updates
Update and re-add BFQ scheduler as well as disable deadline
Ondemand is back
Fixes/Tweaks to ondemand and interactive
10/08/2011 GB
Adjusted smartassV2 parameters for 1GHz processor (originally for 500Mhz device)
10/01/2011 GB
Set smartassv2 to default governor
09/30/2011 GB
Added SmartassV2 governor
Current CPU governors as of the latest release:
SmartassV2
Ondemand
Interactive
Lagfree
Lazy
Technical doc on CPU governors (most of the ones in this kernel anyway)
https://raw.github.com/tiny4579/android_kernel_common/android-2.6.38-incredikernel/Documentation/cpu-freq/governors.txt
Update: 11/30/13 - removed link to incredikernel.com as the site has no content - fully on goo.im now
http://goo.im/devs/tiny4579/inc/kernels
Kernel Source
https://github.com/tiny4579/android_kernel_common
Here are a couple notes if you want to build this kernel from source:
Jellybean kernel branch is android-2.6.38-incredikernel-jb.
ICS kernel branch is android-2.6.38-incredikernel-ics.
Gingerbread kernel branch is android-2.6.38-incredikernel.
The config for the kernel is in arch/arm/configs/incrediblec-incredikernel_defconfig. If you want to switch branches I recommend doing a make incrediblec-incredikernel_defconfig after checking out that branch.
I use the GCC 4.4.3 toolchain for this kernel due to GCC 4.6 causing build issues.
Frequently Asked Questions
Some key differences between smartass and smartassv2 so users can decide which they prefer and learn a bit more about the differences:
Smartass
1. Screen off profile built in maxed at 384mhz.
2. Wakeup frequency is 998mhz.
3. Min screen on is 245mhz.
4. Improved by Chad to run better on our devices.
5. Purely load based, no ideal value.
Smartassv2
1. This is the same exact governor in Erasmux's Nexus One kernel (github.com/erasmux/n1-kernel)
2. Ideal wake frequency is 768 (also default that can be changed).
3. Screen on min is actually 128mhz).
4. No screen off profile.
5. Ideal sleep frequency 245mhz.
6. Improved upon from erasmux's version, not Chad's.
Basically the smartassv2 ideal wake frequency allows the phone to favor a certain speed to attempt to save battery life. It can still go above ideal wake and below ideal sleep so there's no caps on max and min while awake or sleep.
Some tips/info on various governors:
Smartass/smartassv2/interactive:
Use 128 min so the governor can scale as it needs to. Max speed I'd recommend at least 768Mhz.
Ondemand:
Try 128 min and if it lags use 245 min. Max speed I'd recommend at least 768Mhz.
Performance:
Only recommended for benchmarks but speed will always run at max.
InteractiveX:
Same as interactive except it has an auto screen off set to the min. Ideal with 245 min in setcpu but try 128 for battery life but it you have wake lag then set to 245.
Intellidemand:
Based on ondemand with a built in screen off. Any speed settings should be fine.
Interactive:
Some new features with this one. Starting with 9/21/12 release I am using the interactive kernel from Google which features a new kernel option called input_boost.
It is off by default but can be enabled by writing a 1 to /sys/devices/system/cpu/cpufreq/interactive/input_boost. Also there is another parameter for interactive called hispeed_freq in the same location. The hispeed_freq is where the governor jumps to first. Hispeed_freq by default in 10/3/12 is 614400 to help save battery. In the older interactive governor there was a maxspeed freq which meant the governor was a bit jumpier to the max speed. This should be a good blend of performance and battery.
Lagfree:
Based on ondemand but with a softer CPU scaling which should help with battery life. It also seems to be very responsive (starting with 2/26)
Lazy:
Based on ondemand as well (Ezekeel is the developer of this governor). I cannot explain this too well but its apparent behavior seems to be to switch between low and high frequencies pretty evenly.
A note from Ezekeel on this governor:
"Thus I took the ondemand governor and implemented an additional parameter 'min_timeinstate' defining a minimum time the CPU will stay in a certain frequency state before it will be allowed to switch frequencies again. This way one can have a fine grained polling by setting the sampling_rate to a low value without running into problems with these fast frequency changes.
I did some extensive testing with a sampling_rate of 10000, min_timeinstate of 40000 and up_threshold of 90 and FLAC, mp3 and video playback all seem to work flawlessly. So it seems the root of the problem was indeed that the CPU does not handle fast frequency changes well.
I tested several apps and games and so far I have not found anything that this governor cannot handle. Thus I dare to say that it seems to be the superior choice over ondemand."
ZRAM, what is it and how to I add it? (starting officially with 12/31/11)
If you are familiar with swap space in linux or virtual memory in Windows it is a similar concept. Except instead of using the hard drive as swap space it compresses swap space in RAM for faster access times than conventional swap. This will also wear out our storage memory less than typical swapping.
Enable ZRAM is simple thanks to a script built by imoseyon which is provided in the kernel zip file. To enable, use adb shell or download a terminal app and run zram enable. This will persist across reboots (if init.d is setup in your ROM) so if you don't want it anymore run zram disable and it will remove the bootscript and deactivate it.
You need to have root privileges to enable/disable zram. Run the su command in terminal emulator to request root.
I was wondering when lazy was gonna make it's way to aosp...
Sent from my ADR6300 using xda premium
OMG_VTEC said:
I was wondering when lazy was gonna make it's way to aosp...
Sent from my ADR6300 using xda premium
Click to expand...
Click to collapse
The name of the new governor says it all....
You just answered your own question. I took my own sweet time releasing it. It was built like 2 weeks ago. I was being lazy.
tiny4579 said:
Scripts/Mods if I think of something...
Click to expand...
Click to collapse
Tiny, this new thread is great, as is the work you and Chad have done on these kernels. Keep up the great work. Thank you.
jlokos said:
Tiny, this new thread is great, as is the work you and Chad have done on these kernels. Keep up the great work. Thank you.
Click to expand...
Click to collapse
Yeah, the old way was sloppy. Tired of it. I think this thread is cleaner than the sense one and it took me less time to write it.
To help out users (and document the probable future deviation), how about adding a tag to each kernel stating whether it works with froyo (which I believe is none), GB, ICS, or a multiple (which is only the last couple or so, I think).
Great work, by the way.
PonsAsinorem said:
To help out users (and document the probable future deviation), how about adding a tag to each kernel stating whether it works with froyo (which I believe is none), GB, ICS, or a multiple (which is only the last couple or so, I think).
Great work, by the way.
Click to expand...
Click to collapse
Done. 10char
Nice.....great work to you and Chad. Thanks.
Sent from my ADR6300 using Tapatalk
Thanks for the thread tiny, I was wondering what the benefits of the lazy governor were
I'm running my CPU at 128/806 Mhz with Lazy and it's been nice and smooth all day. Battery life has been as good or better than SA2 for me.
It also seemed to drop my ping time and increase the throughput in SpeedTest. I was getting really discouraged with ICS and >400ms ping times but I'm attributing the Lazy governor with right around 100ms ping and smoother data rates. When I switch back to the SA2 governor that I've been running for months data gets choppy again. The system itself seems smooth enough with SA2 but data has been very choppy.
Thank you to all you great developers for all your time, effort, and hard work. We really do appreciate it.
azradiohead said:
I'm running my CPU at 128/806 Mhz with Lazy and it's been nice and smooth all day. Battery life has been as good or better than SA2 for me.
It also seemed to drop my ping time and increase the throughput in SpeedTest. I was getting really discouraged with ICS and >400ms ping times but I'm attributing the Lazy governor with right around 100ms ping and smoother data rates. When I switch back to the SA2 governor that I've been running for months data gets choppy again. The system itself seems smooth enough with SA2 but data has been very choppy.
Thank you to all you great developers for all your time, effort, and hard work. We really do appreciate it.
Click to expand...
Click to collapse
The ROM/kernel/governor have no impact on data signal or speed so what you're seeing is coincidental. Network speed varies on so many factors outside of the control of the ROM or kernel. I'm glad to hear you like the new kernel and the lazy governor. I'm a fan of the dev of the lazy governor's work and run his kernel on my nexus.
My concern is that others will assume it will improve network performance and be disappointed when it doesn't.
Thank you for your compliments!
I just want to make sure I clarified this matter.
chocolate8175 said:
Thanks for the thread tiny, I was wondering what the benefits of the lazy governor were
Click to expand...
Click to collapse
I was looking around for something good that would make sense but I couldn't find anything so far.
Basically I added this governor on a whim. So far it seems to like lower frequencies even more than smartassv2 without too much sacrifice on speed. It might have better battery life. It seems smooth on Nil's Business Sense 3.5 though.
Interesting post here on smartassv2 from the developer of the lazy governor:
User:
and smartassV2 too but let him fix find the cause of the reboots before
Dev:
I will not integrate any new stuff until I have the cause for reboot problems tracked down. I will look into lulzactive, but I definitely will not include smartass since it is an inefficient governor.
Not sure why he said it was inefficient but could see no post about it.
Needless to say, I like lazy and lagfree so far. Give lazy and lagfree a try for a week and see what you think.
azradiohead said:
I'm running my CPU at 128/806 Mhz with Lazy and it's been nice and smooth all day. Battery life has been as good or better than SA2 for me.
It also seemed to drop my ping time and increase the throughput in SpeedTest. I was getting really discouraged with ICS and >400ms ping times but I'm attributing the Lazy governor with right around 100ms ping and smoother data rates. When I switch back to the SA2 governor that I've been running for months data gets choppy again. The system itself seems smooth enough with SA2 but data has been very choppy.
Thank you to all you great developers for all your time, effort, and hard work. We really do appreciate it.
Click to expand...
Click to collapse
may be placibo effect but I have noticed this too and confirmed with speedtest.
Sent from my incredible incredible.
RebelShadow said:
may be placibo effect but I have noticed this too and confirmed with speedtest.
Sent from my incredible incredible.
Click to expand...
Click to collapse
How does it fare with ondemand or lagfree? I still think its placebo. I can't test on my phone as I don't have data on the incredible.
Sent from my Galaxy Nexus using Tapatalk
Running GB and just installed the new Incredikernel, I saw no appreciable difference with data usage on Lazy, Lagfree, SAV2, Ondemand. Depending on your wireless signal, just moving your body by even a few inches could have an impact on data speeds (high frequency shadowing of transmission waves). The ping, might have some more sway by the CPU of the device if the program doesn't get as much processor in when communicating with the server, but not in the order of milliseconds (would be my though).
tiny4579 said:
I was looking around for something good that would make sense but I couldn't find anything so far.
Basically I added this governor on a whim. So far it seems to like lower frequencies even more than smartassv2 without too much sacrifice on speed. It might have better battery life. It seems smooth on Nil's Business Sense 3.5 though.
Interesting post here on smartassv2 from the developer of the lazy governor:
User:
and smartassV2 too but let him fix find the cause of the reboots before
Dev:
I will not integrate any new stuff until I have the cause for reboot problems tracked down. I will look into lulzactive, but I definitely will not include smartass since it is an inefficient governor.
Not sure why he said it was inefficient but could see no post about it.
Needless to say, I like lazy and lagfree so far. Give lazy and lagfree a try for a week and see what you think.
Click to expand...
Click to collapse
I'm using your latest GB kernel with the lazy governor on Warm TwoPointThree 3.5 rom. It is very smooth with very good battery life (undervolted).
jlokos said:
I'm using your latest GB kernel with the lazy governor on Warm TwoPointThree 3.5 rom. It is very smooth with very good battery life (undervolted).
Click to expand...
Click to collapse
Better than SAV2? I can't really comment myself but I like it so far.
Also, try to keep Sense kernel talk in the sense thread and aosp kernel talk in the AOSP thread. It makes tracking easier. But I also brought up the comment in this thread so it makes sense why you posted here.
tiny4579 said:
Better than SAV2? I can't really comment myself but I like it so far.
Also, try to keep Sense kernel talk in the sense thread and aosp kernel talk in the AOSP thread. It makes tracking easier. But I also brought up the comment in this thread so it makes sense why you posted here.
Click to expand...
Click to collapse
I have used both the GB and AOSP versions of the lazy governor. The GB version appears to make the Sense 3.5 rom smoother. As far as battery life, I haven't been able to tell if its better than SA2 since I have a much longer history with SA2. In any event, thanks for adding this governor to both versions (as I switch between the new ICS roms and Sense 3.5); it's another great choice for us to experiment with.
Could you make lulzactive possible tiny?
Sent from my DROIDX using Tapatalk
Update 1/13/2013:
IO Scheduler, TCP Congestion Avoidance Algorithm
Please go to Post #27
Sources and credit go to:
http://forum.xda-developers.com/showthread.php?t=1792369
http://forum.xda-developers.com/showthread.php?t=1369817
Android CPU governors explained
1: OnDemand
2: OndemandX
3: Performance
4: Powersave
5: Conservative
6: Userspace
7: Min Max
8: Interactive
9: InteractiveX
10: Smartass
11: SmartassV2
12: Scary
13: Lagfree
14: Smoothass
15: Brazilianwax
16: SavagedZen
17: Lazy
18: Lionheart
19: LionheartX
20: Intellidemand
21: Hotplug
22: Wheatley
23: Lulzactive
24: AbyssPlug
25. BadAss
1: OnDemand Governor:
This governor has a hair trigger for boosting clockspeed to the maximum speed set by the user. If the CPU load placed by the user abates, the OnDemand governor will slowly step back down through the kernel's frequency steppings until it settles at the lowest possible frequency, or the user executes another task to demand a ramp.
OnDemand has excellent interface fluidity because of its high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand is commonly chosen by smartphone manufacturers because it is well-tested, reliable, and virtually guarantees the smoothest possible performance for the phone. This is so because users are vastly more likely to ***** about performance than they are the few hours of extra battery life another governor could have granted them.
This final fact is important to know before you read about the Interactive governor: OnDemand scales its clockspeed in a work queue context. In other words, once the task that triggered the clockspeed ramp is finished, OnDemand will attempt to move the clockspeed back to minimum. If the user executes another task that triggers OnDemand's ramp, the clockspeed will bounce from minimum to maximum. This can happen especially frequently if the user is multi-tasking. This, too, has negative implications for battery life.
2: OndemandX:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
3: Performance Governor:
This locks the phone's CPU at maximum frequency. While this may sound like an ugly idea, there is growing evidence to suggest that running a phone at its maximum frequency at all times will allow a faster race-to-idle. Race-to-idle is the process by which a phone completes a given task, such as syncing email, and returns the CPU to the extremely efficient low-power state. This still requires extensive testing, and a kernel that properly implements a given CPU's C-states (low power states).
4: Powersave Governor:
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
5:Conservative Governor:
This biases the phone to prefer the lowest possible clockspeed as often as possible. In other words, a larger and more persistent load must be placed on the CPU before the conservative governor will be prompted to raise the CPU clockspeed. Depending on how the developer has implemented this governor, and the minimum clockspeed chosen by the user, the conservative governor can introduce choppy performance. On the other hand, it can be good for battery life.
The Conservative Governor is also frequently described as a "slow OnDemand," if that helps to give you a more complete picture of its functionality.
6: Userspace Governor:
This governor, exceptionally rare for the world of mobile devices, allows any program executed by the user to set the CPU's operating frequency. This governor is more common amongst servers or desktop PCs where an application (like a power profile app) needs privileges to set the CPU clockspeed.
7: Min Max
well this governor makes use of only min & maximum frequency based on workload... no intermediate frequencies are used.
8: Interactive Governor:
Much like the OnDemand governor, the Interactive governor dynamically scales CPU clockspeed in response to the workload placed on the CPU by the user. This is where the similarities end. Interactive is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Unlike OnDemand, which you'll recall scales clockspeed in the context of a work queue, Interactive scales the clockspeed over the course of a timer set arbitrarily by the kernel developer. In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. This can eliminate the frequency bouncing discussed in the OnDemand section. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. This is another pro-battery life benefit of Interactive.
However, because Interactive is permitted to spend more time at maximum frequency than OnDemand (for device performance reasons), the battery-saving benefits discussed above are effectively negated. Long story short, Interactive offers better performance than OnDemand (some say the best performance of any governor) and negligibly different battery life.
Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.
9: InteractiveX Governor:
Created by kernel developer "Imoseyon," the InteractiveX governor is based heavily on the Interactive governor, enhanced with tuned timer parameters to better balance battery vs. performance. The InteractiveX governor's defining feature, however, is that it locks the CPU frequency to the user's lowest defined speed when the screen is off.
10: Smartass
Is based on the concept of the interactive governor.
I have always agreed that in theory the way interactive works – by taking over the idle loop – is very attractive. I have never managed to tweak it so it would behave decently in real life. Smartass is a complete rewrite of the code plus more. I think its a success. Performance is on par with the “old” minmax and I think smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Smartass will also cap the max frequency when sleeping to 352Mhz (or if your min frequency is higher than 352 – why?! – it will cap it to your min frequency). Lets take for example the 528/176 kernel, it will sleep at 352/176. No need for sleep profiles any more!"
11: SmartassV2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery.
12: Scary
A new governor wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It will give the same performance as conservative right now, it will get tweaked over time.
13: Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.
14: Smoothass:
The same as the Smartass “governor” But MUCH more aggressive & across the board this one has a better battery life that is about a third better than stock KERNEL
15: Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery
16: SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
17: Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.
18: Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source.
The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
19: LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
20: Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors)
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
21: Hotplug Governor:
The “hotplug” governor scales CPU frequency based on load, similar to “ondemand”. It scales up to the highest frequency when “up_threshold” is crossed and scales down one frequency at a time when “down_threshold” is crossed. Unlike those governors, target frequencies are determined by directly accessing the CPUfreq frequency table, instead of taking some percentage of maximum available frequency.
The key difference in the “hotplug” governor is that it will disable auxillary CPUs when the system is very idle, and enable them again once the system becomes busy. This is achieved by averaging load over multiple sampling periods; if CPUs were online or offlined based on a single sampling period then thrashing will occur.
Sysfs entries exist for “hotplug_in_sampling_periods” and for “hotplug_out_sampling_periods” which determine how many consecutive periods get averaged to determine if auxillery CPUs should be onlined or offlined. Defaults are 5 periods and 20 periods respectively. Otherwise the standard sysfs entries you might find for “ondemand” and “conservative” governors are there.
Obviously, this governor is only available on multi-core devices.
22: Wheatley
in short words this govenor is build on “ondemand” but increases the C4 state time of the CPU and doing so trying to save juice.
23: Basically interactive governor with added smartass bits and variable (as opposed to fixed amout) frequency scaling, based on currently occuring cpu loads. Has, like smartass, a sleep profile built-in. See link for details on exact scaling.
24: Abyssplug governor is a modified hotplug governor.
25. BadAss Governor:
Badass removes all of this "fast peaking" to the max frequency. On a typical system the cpu won't go above 918Mhz and therefore stay cool and will use less power. To trigger a frequency increase, the system must run a bit @ 918Mhz with high load, then the frequency is bumped to 1188Mhz. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 1-2 seconds, depending on the load your system is experiencing)
Badass will also take the gpu load into consideration. If the gpu is moderately busy it will bypass the above check and clock the cpu with 1188Mhz. If the gpu is crushed under load, badass will lift the restrictions to the cpu.
Thank you! Always helpful info to have, much appreciated
Really great Info
thanks for the tutorial.
Thank you for this. I was always confused by what the different governors meant!
So, Governors can be categorized into 3/4 on a high level:
1.a) Ondemand Based:
Works on "ramp-up on high load" principle. CPU busy-time is taken into consideration for scaling decisions. Members: Ondemand, OndemandX, Intellidemand, Lazy, Lagfree.
1.b) Conservative Based:
Members: Conservative, Lionheart, LionheartX
2) Interactive Based:
Works on "make scaling decision when CPU comes out of idle-loop" principle. Members: Interactive, InteractiveX, Lulzactive, Luzactiveq, Smartass, SmartassV2, Brazilianwax, SavagedZen.
3) Weird Category:
Members: Userspace, Powersave, Performance.
http://forum.xda-developers.com/showthread.php?t=1369817
Thanks a lot for this guide, and I mean it!
Thank You,long time searching a guide like this!!
Wow, that's a lot of thanks for a simple copy/paste. But at least you listed your source
jacklebott said:
Wow, that's a lot of thanks for a simple copy/paste. But at least you listed your source
Click to expand...
Click to collapse
Yes and you wonder why nobody cared to do it earlier, and nobody cared to Google and search themselves.
Sent from my Nexus 4 using XDA Premium HD app
Interesting article for sure. So how do we go ahead and flash these bad boys haha?
evaradar said:
Interesting article for sure. So how do we go ahead and flash these bad boys haha?
Click to expand...
Click to collapse
There governors are built into each kernel. The author of the kernel may choose to build in a different combinations of these governors.
So wait for custom kernels. Actually Faux and Franco and others released a few test builds in the Original Android Development Forum.
I've just added this guide to the Nexus 4 Complete Index
Sent from my GT-I9100 using xda premium
KidCarter93 said:
I've just added this guide to the Nexus 4 Complete Index
Sent from my GT-I9100 using xda premium
Click to expand...
Click to collapse
Thank you! :good:
richteralan said:
There governors are built into each kernel. The author of the kernel may choose to build in a different combinations of these governors.
So wait for custom kernels. Actually Faux and Franco and others released a few test builds in the Original Android Development Forum.
Click to expand...
Click to collapse
Gotcha!
You should put a disclaimer at the top saying that you didn't actually write the guide... Like that other guy did. Kinda misleading otherwise.
red12355 said:
You should put a disclaimer at the top saying that you didn't actually write the guide... Like that other guy did. Kinda misleading otherwise.
Click to expand...
Click to collapse
Why? I dont understand why people get mad or want to give hell and all he was doing is sharing great information and at the end giving credit where it's do.
He has done everything right in this post, (even naming convention) so cut the OP a darn break.
This was not misleading to me at all. He said it was a guide for kernels. I read it. Then he stated where he got his information. I think you should thank the OP for bringing this information to the forum rather than whine.
Sent from my HTC One S using xda premium
dsellers2 said:
Why? I dont understand why people get mad or want to give hell and all he was doing is sharing great information and at the end giving credit where it's do.
He has done everything right in this post, (even naming convention) so cut the OP a darn break.
This was not misleading to me at all. He said it was a guide for kernels. I read it. Then he stated where he got his information. I think you should thank the OP for bringing this information to the forum rather than whine.
Sent from my HTC One S using xda premium
Click to expand...
Click to collapse
Who's whining? Just gave a suggestion.
red12355 said:
Who's whining? Just gave a suggestion.
Click to expand...
Click to collapse
OK I'll move the source/credit link from bottom to the top and blow up the font. Or maybe add a tl;dr in front of the links.
How's that sound?
Thank you!
One question:
What do CFQ, DEADLINE, and NOOP mean?
(In regards to SetCPU App, you can choose a governor on the bottom left an then "cfq", "deadline" and "noop")
Thanks!
Hi,
I'm using Co-Core 8.2 and I want to test One Power Guard to improve my battery life.
But I don't have any idea about which CPU governor and I/O scheduler to choose.
Could someone tell me which combination provides the best balance between power-save and performance?
I'm on Jelly Bean 4.1.2
NB. Cocafe recommends PegasusQ as CPU governor and either SIO/ROW for I/O scheduler but I would like to get some feedback from people already using One Power Guard.
Thanks in advance
luisblop said:
Hi,
I'm using Co-Core 8.2 and I want to test One Power Guard to improve my battery life.
But I don't have any idea about which CPU governor and I/O scheduler to choose.
Could someone tell me which combination provides the best balance between power-save and performance?
I'm on Jelly Bean 4.1.2
NB. Cocafe recommends PegasusQ as CPU governor and either SIO/ROW for I/O scheduler but I would like to get some feedback from people already using One Power Guard.
Thanks in advance
Click to expand...
Click to collapse
Pegasus and sioplus
OR
Hotplug and sioplus
DaRkRhiNe said:
Pegasus and sioplus
OR
Hotplug and sioplus
Click to expand...
Click to collapse
Thanks for the answer. I will give a try with Pegasus
However I noticed that sioplus is not available on One Power Guard settings. Only row and sio.
Is sioplus available in Co-core 8.2?
These apps like this just drains your battery. If you want play with CPU, download a CPU controller app. (like SetCPU) and install CoCore 9.0 which is newest version.
When you don't use phone ; 600 MHz Max & HotPlug
When you don't use phone V2 ; 600 MHz Max & Ondemand & deeper sleep status
When you lock phone, don't decrease speed (too much) because it will use whole CPU if it needs ; 800 MHz Max & Ondemand Q/Lulzactive Q/Pegasus Q
When using ; 1000 MHz Max & Ondemand/Interactive/Lulzactive Q/Pegasus Q
When you get mad and crazy about performance, lock the min to max; 1000 MHz min and max & Ondemand & SmartAss (still exists or not I don't know)
If you increase minimum speed it will keep it. So I suggest always keep min to 200MHz. (if exists 0 MHz I don't remember it too)
Edit: and don't go deeper sleep if you use hot plugger governors like Hotplug, Pegasus, Lulzactive Q
FYI
http://forum.xda-developers.com/showthread.php?t=2312491
Powered by CM11
Thanks guys,
I will compare the battery draining with One Power Guard just to give it a try.
If I don't notice any improvement then I will tweak with SetCPU
King ov Hell said:
Edit: and don't go deeper sleep if you use hot plugger governors like Hotplug, Pegasus, Lulzactive Q
Click to expand...
Click to collapse
Hi again,
What exactly do you mean wit "deeper sleep"?
Is that an option or when the display is off after several minutes?
Sorry for my ignorance
luisblop said:
Hi again,
What exactly do you mean wit "deeper sleep"?
Is that an option or when the display is off after several minutes?
Sorry for my ignorance
Click to expand...
Click to collapse
Go to the CoCore's thread you'll see. It's deep sleep level which can increase your battery life when you don't use the device. It's not about using, it's about when it's stand-by.
Ok
After one day even if One Power Guard is a nice app I prefer to switch governor depending on the display status. So I was thinking about using tasker (instead setCPU) which is already running on my phone and this way not adding more background processes.
I set a couple of task using the CPU control from tasker. It is working fine switching governors but I noticed that the frequencies (min and max) don't change. I tried even with shell script and still I don't get to set the max frequency. Then I prefer to make you a couple of questiosn:
-In tasker when using the CPU control. If I change governor. Should it be set in both CPUs (0 and 1) or only in a single one? In my case i set the governor in both.
-I use the terminal to check the current governor and max frequency (for instance for the cpu0)
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governorcat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
As said above the governor is succesfully changed but that's not the case for the frequency. Then I tried to run a shell script to change the max frequency as follows:
echo #frequency > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
But it seems not working neither. So I wonder if I'm doing something wrong.
NB. By the way I'm happy using the governor hotplug while not using my phone (thanks for the advice). In normal use I set pegasusq with sio and seems working great.