Related
Hi, just another cpu governor question:
Smartass VS Interactive, 122/710
Ive notice this behavior with these two via OS Monitor:
Interactive: This mod seems to adjust the cpu frequency based on current cpu usage, from 122 to 710 (and some steps between these two, again based on usage) - is my thinking correct?. Same should be for sleep, where is no cpu usage, therefore 122mhz or so.
Smartass - based on interactve, expected to be better: This one is also adjusting the cpu frequency when needed, but in ON mode its from 480 to 710 and when sleep its from 122 to 352.
When I know these two information (assuming they are correct) the interactive governor seems to be better for battery saving with same performance (idle system for few seconds - 480mhz vs 122mhz). Or is there any significant performance difference when interactive got such a huge scaling range? Did I miss something relevant when comparing these two?
Copy-Pasting a post from arco which explains Smartass:
"Smartass caps the frequency when screen on to 480 MHz to ensure responsiveness. This also helps with video playback being smooth, as it otherwise will begin to stutter when the frequency is lower than this."
The Interactive governor is designed to reach maximum speed with no lag, so there should not be any need to raise minimum speed just because the screen is on, but the smartass governor has been optimised for android so it must be a good choice.
Personally, I am testing the Conservative governor which should take about 2 seconds to get from min to max speed, and I am not seeing any difference from on-demand.
Standby battery life is improved by dropping min speed, you don`t NEED to change anything else.
I have been investigating this matter for 2 weeks now. Using SetCPU to set the governor and CPU Spy for monitoring, here's what I typically get on my Nexus S with Netarchy Kernel.
Ondemand
1000Mhz: 3%
800: 1%
400: 0%
200: 0%
100: 12%
Deep Sleep: 84%
Conservative
1000: 2%
800: 3%
400: 3%
200: 0%
100: 8%
Deep Sleep: 84%
Smartass
1000: 2%
800: 5%
600: 5%
400: 2%
200: 0%
100: 3%
Deep Sleep: 83%
Smartass looks more responsive but drains more battery. Surprisingly, ondemand should drain less battery than conservative.
What do you guys get?
Avoid the Conservative Governor - I am only using it for fun. It saves a small amount of power by picking up speed slowly, but wastes more by dropping speed even slower. I can improve that by messing with the source, but in standard form it is pretty hopeless.
SmartAss lets you drop speed in standby to ridiculously low levels without losing performance when the sceen is on. I couldn`t recommend anything else.
Ooops
There is a bug in the Conservative Governor : it is wasting power because it will not reduce CPU clock until CPU usage is below 10% (default).
Suggested fix:
--- /usr/src/ez/drivers/cpufreq/cpufreq_conservative.c 2011-04-25 01:51:20.000000000 +0100
+++ /usr/src/buzz35/drivers/cpufreq/cpufreq_conservative.c 2011-07-29 18:10:12.184895733 +0100
@@ -30,7 +30,7 @@
*/
#define DEF_FREQUENCY_UP_THRESHOLD (80)
-#define DEF_FREQUENCY_DOWN_THRESHOLD (20)
+#define DEF_FREQUENCY_DOWN_THRESHOLD (70)
/*
* The polling frequency of this governor depends on the capability of
@@ -524,9 +524,9 @@
/*
* The optimal frequency is the frequency that is the lowest that
* can support the current CPU usage without triggering the up
- * policy. To be safe, we focus 10 points under the threshold.
+ * policy. To be safe, we should focus 10 points under the threshold.
*/
- if (max_load < (dbs_tuners_ins.down_threshold - 10)) {
+ if (max_load < dbs_tuners_ins.down_threshold) {
freq_target = (dbs_tuners_ins.freq_step * policy->max) / 100;
this_dbs_info->requested_freq -= freq_target;
The conservative governor was designed to keep CPU usage between 20% and 80%, which seems fairly wasteful.
In early 2009 the code was changed to make it more like OnDemand, and the lower limit was (accidentally?) lowered to 10% (default). That "mistake" is still present in the 3.0 kernel so clearly no-one uses the conservative governor, but if they did I recommend setting the lower limit to 10% below the UPPER limit of 80% (or even 90%) to stand any chance of using less power than with on-demand.
* *
jr0324 said:
I have very aggressive undervolt settings that work great for franco kernel m4
Stable CPU:
1344 (untouched - 1380 mV(don't use))
1228 (1250 mV)
1036 (1125 mV)
729 (975 mV)
384 (850 mV)
192 (725 mV)
Default CORE & IVA
Battery life is strong with these for me. I can forget to charge before I go to sleep with and moderate use throughout the day, wake up to ~35%.
Screen off: 384 max
Min CPU: 192
Max CPU: 1228
Governor: ondemand
Click to expand...
Click to collapse
(。_。) slowly backs away from this thread.
* *
....
pointless.
oh and op, that's not an agressive uv..
Sent from my i9250
{
"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"
}
It looks like this thread is starting to be way more popular than i expected when I created it! I decided to add useful OP to it.
Here is a list of a few things to know about how I want this thread to be:
First of all, everybody is more than welcome to share settings, knowledge or any useful informations that could help someone. XDA is all about helping each other.
No Question is too stupid. Feel free to ask anything that is related to the kernel. I specified KT747 in the title because this is what I personally use but any adjustement made to governors, schedulers and undervolting will work with different kernels that allow you to adjust those settings. So even if you don't use KT747, you're welcome to post here.
Before posting in this thread, read the entire OP and second post with useful links and informations.
Finally, be respectful and have fun!
How to share settings:- Begin by telling what is your rom, the date or name of the release, jellybean or ics, AOSP or touchwiz, 4.1.2 or 4.2.1 and also specify which release of KT747 you are using or if you are using another kernel.
- Let us know your general settings: Min/Max frequencies, screen off profile(Mhz and/or governor) and vibration strength.
- Then share with us what governor and I/O scheduler you are using and if you made any adjustements to them.
- If you share adjustements you made on governors or schedulers, you can take screenshots or just write which tunables you change and what values you assigned to it.
- If you share undervolting settings, to avoid huge post with a lot of screenshots,we will do it differently: If you substracted the same amount of mV to every steps, just say how much. If you tweaked every steps separetly, you can type each voltages or you just make sure you have a backup of your settings, go into /sdcard/KTweaker/, copy the lines coresponding to the voltages and share it this way:
Voltage(from 2106 to 96 MHz):
1250 1225 1200 1175 1150 1125 1100 1085 1065 1045 1025 1005 985 965 945 925 905 890 875 860 845 830 815 800 790 780 770 760 750 745.
- To share your KTweaker backup file (/sdcard/KTweaker/). Specify if it is set on boot or not and if it has custom voltages. If you have custom undervoltage setting you better make a backup that is not set on boot or set on boot after 30 seconds. So if some device doesn't take your undervolt values they won't be stock in a bootloop.
Finally, Thanks to Ktoonsez for his amazing kernel that you can find here: http://forum.xda-developers.com/showthread.php?t=1756776
You can Donate to Ktoonsez here: http://forum.xda-developers.com/donatetome.php?u=4325945
Useful links and informations
Useful links and informations.
Informations about Governors:
The following infos were found here:
http://forum.xda-developers.com/showthread.php?t=1369817
http://forum.xda-developers.com/showthread.php?p=28647926
http://forum.xda-developers.com/showthread.php?t=1369817
Ondemand:
Default governor in almost all stock kernels. One main goal of the ondemand governor is to switch to max frequency as soon as there is a CPU activity detected to ensure the responsiveness of the system. Effectively, it uses the CPU busy time as the answer to "how critical is performance right now" question. So Ondemand jumps to maximum frequency when CPU is busy and decreases the frequency gradually when CPU is less loaded/apporaching idle. Even though many of us consider this a reliable governor, it falls short on battery saving and performance on default settings.
Conservative:
A slower Ondemand which scales up slowly to save battery. The conservative governor is based on the ondemand governor. It functions like the Ondemand governor by dynamically adjusting frequencies based on processor utilization. However, the conservative governor increases and decreases CPU speed more gradually. Simply put, this governor increases the frequency step by step on CPU load and jumps to lowest frequency on CPU idle. Conservative governor aims to dynamically adjust the CPU frequency to current utilization, without jumping to max frequency.
Interactive:
Can be considered a faster ondemand. So more snappier, less battery. Interactive is designed for latency-sensitive, interactive workloads. Instead of sampling at every interval like ondemand, it determines how to scale up when CPU comes out of idle. The governor has the following advantages: 1) More consistent ramping, because existing governors do their CPU load sampling in a workqueue context, but interactive governor does this in a timer context, which gives more consistent CPU load sampling. 2) Higher priority for CPU frequency increase, thus giving the remaining tasks the CPU performance benefit, unlike existing governors which schedule ramp-up work to occur after your performance starved tasks have completed. Interactive It's an intelligent Ondemand because of stability optimizations.
Intellidemand:
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.
Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly.
Userspace:
Instead of automatically determining frequencies, lets user set frequencies.
Powersave:
Locks max frequency to min frequency. Can not be used as a screen-on or even screen-off (if scaling min frequency is too low).
Performance:
Sets min frequency as max frequency. Use this while benchmarking!
Scary:
A new governor wrote based on conservative with some smartass features
Wheatley:
Building on the classic 'ondemand' governor is implemented Wheatley governor. The governor has two additional parameters:
target_residency - The minimum average residency in µs which is considered acceptable for a proper efficient usage of the C4 state. Default is 10000 = 10ms.
allowed_misses - The number sampling intervals in a row the average residency is allowed to be lower than target_residency before the governor reduces the frequency. This ensures that the governor is not too aggressive in scaling down the frequency and reduces it just because some background process was temporarily causing a larger number of wakeups.
Pegasusq:
The Pegasus-q / d is a multi-core based on the Ondemand governor and governor with integrated hot-plugging.
Ongoing processes in the queue, we know that multiple processes can run simultaneously on. These processes are active in an array, which is a field called "Run Queue" queue that is ongoing, with their priority values arranged.
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.
Abyssplug governor:
It is a modified 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.
SLP governor:
It is a mix of pegasusq and ondemand
Governor tunables explanations
OnDemand, Conservative, Ktoonservative, Adaptive, Intellidemand:
sampling_rate:Measured in uS , this is how often the kernel look at the CPU usage and make decisions on what to do about the frequency. Higher values means CPU polls less often. For lower frequencies, this could be considered an advantage since it might not jump to next frequency very often, but for higher frequencies, the scale-down time will be increased.
up_threshold: Measured in percentage 1-100, When CPU load reaches this point, governor will scale CPU up. Higher value means less responsiveness and lower values corresponds to more responsiveness at the cost of battery.
powersave_bias: Default value is 0. Setting a higher value will bias the governor towards lower frequency steps. Use this if you want CPU to spend less time on higher frequencies. A better alternative would be to underclock to a lower frequency than using powersave bias.
sampling_down_factor: In the simplest form, sampling_down_factor determines how often CPU should stay at higher frequencies when truly busy. Default behavior is fast switching to lower frequencies (1). Having sampling_down_factor set to 1 makes no changes from existing behavior (for the non-modified ondemand), but having sampling_down_factor set to a value greater than 1 causes it to act as a multiplier for the scheduling interval for re-evaluating the load when the CPU is at its highest clock frequency (which is scaling_max_freq) due to high load. This improves performance by reducing the overhead of load evaluation and helping the CPU stay at its highest clock frequency when it is truly busy, rather than shifting back and forth in speed. This tunable has no effect on behavior at lower frequencies/lower CPU loads.
down_differential: This factor indirectly calculate the 'down-threshold' of Ondemand. After completing sampling-down-factor*sampling-rate at max frequency because of high load, governor samples the load again to calculate an estimate of the new target frequency in a way that the lowest frequency will be chosen that would not trigger up_threshold in the next sample. Because triggering up-threshold will again cause CPU to scale up to max frequency. During this choice down_differential is taken into account as a breathing room value. Target frequency is calculated as max_load_freq / (up_threshold - down_differential). The obtained value might be a non-existent value in the freq_table and CPU driver will round it off to a value in freq_table. max_load_freq is the theoretical frequency at which CPU can handle 100% workload. It is usually a value below scaling_max_freq. See this post by AndereiLux for more info.
freq_step: Whenever up-scaling logic is triggered the governor instructs the CPU to raise its frequency by freq_step percentage of max allowed frequency. (max policy * (freq step / 100)). Ex: max policy is 1600 and freq step 21%, it will scale 1600 * 21% = 336. We have a 100MHz grained frequency table so it rounds up to the next 100MHz, hence 336 becomes 400. So say we're idling at 200MHz and the up-scaling logic gets triggered with the above settings, the next frequency will be 600MHz. Note that freq_step and smooth_scaling does pretty much the same thing.
SmartassV2 & AssWax
awake_ideal_freq: The frequency until which CPU is scaled up rapidly on screen-awake (from sleep). Thereafter, scaling up is less aggressive.
sleep_ideal_freq: The frequency until which CPU is scaled down rapidly when screen is turned off. Thereafter, scaling down is less aggressive.
up_rate_us: The minimum amount of time to spend at a frequency before we can ramp up. (Ignored below awake-ideal frequency since governor needs to rapidly scale up to awake_ideal_freq when below it)
down_rate_us: The minimum amount of time to spend at a frequency before we can ramp down. (Ignored above sleep-ideal frequency since governor needs to rapidly scale down to sleep_ideal_freq when above it)
max_cpu_load: Same as up_threshold in other governors.
min_cpu_load: Same as down_threshold in other governors.
ramp_down_step: Frequency delta when ramping down below the ideal frequency. Zero disables and will calculate ramp down according to load heuristic. When above the ideal frequency we always ramp down to the ideal freq.
ramp_up_step: Frequency when ramping up above the ideal frequency. Zero disables and causes to always jump straight to max frequency. When below the ideal frequency we always ramp up to the ideal freq.
sleep_wakeup_freq: The frequency to set when waking up from sleep. When sleep_ideal_freq=0 this will have no effect.
Interactive
hispeed_freq: Hi speed to bump to from lo speed when load burst. (Default value is scaling max freq)
go_hispeed_load: Go to hi speed when CPU load at or above this value. (Similar to Up-Threshold in other governors)
min_sample_time: The minimum amount of time to spend at a frequency before we can ramp down. (Sounds like Lazy governor?!)
timer_rate: The sample rate of the timer used to increase frequency.
PegasusQ:
cpu_up_rate: No of samples to evaluate load to scale CPU Up. After cpu_up_rate samples are finished for a frequency, CPU scale-Up logic is executed. In other words - before scaling Up, cpu_up_rate*sampling_rate micro seconds are spend at a frequency.
UNIT: Positive Integer
cpu_down_rate: No of samples to evaluate load to scale CPU Down. After CPU_down_rate samples are finished for a frequency, CPU scale-Down logic is executed. In other words - before scaling Down, cpu_down_rate*sampling_rate micro seconds are spend at a frequency.
UNIT: Positive Integer
hotplug_freq_1_1: Up threshold frequency to turn second core On, when some other conditions is also met. ie If (minimum frequency greater than or equal to hotplug_freq 1 1 and run queue length is greater than hotplug_rq_1_1) Hotplug IN Second Core. Higher value correpsonds to delay in turning on second core.
UNIT: Kilo Hertz
hotplug_freq_2_0: Down threshold frequency to turn second core Off, when some other conditions is also met. ie If (maximum frequency less than hotplug_freq 2 0 and run queue length is less than or equal to hotplug_rq_2_0) Hotplug OUT Second Core. Lower value correpsonds to delay in turning off second core.
UNIT: Kilo Hertz
hotplug_rq_1_1: Threshold run queue length for second core to turn on.
UNIT: Positive Integer
hotplug_rq_2_0: Threshold run queue length for second core to turn off.
UNIT: Positive Integer
freq_for_responsiveness: Until freq_for_responsiveness, Up Threshold considered for sampling load is up_threshold_at_min_freq. Also during the part where CPU is at maximum load frequency, governor need to find the optimal frequency as the next frequency - which should not trigger up_threshold in the next sampling. When such a frequency_next is found to be a) less than freq_for_responsiveness b) will not trigger down_threshold in the next sample, then the optimal frequency is set to freq_for_responsiveness.
up_threshold_at_min_freq: This threshold is used as up threshold while sampling at frequencies less than freq_for_responsiveness. Above that, normal up_threshold is used. This gives us an option to make scaling aggressive/relaxed until a frequency and normal for higher frequencies. Again, during calculation of optimal frequency which should not trigger up policy, down threshold to consider is difference between up_threshold_at_min_freq and down_differential
io_is_busy: Setting to 1 causes treating i/o wait time as CPU busy time. I/O busy is just an indication that CPU is performance critical, and system is not actually idle. IO wait time is excluded from the CPU idle time value is 1.
UNIT: Boolean 1 or 0
max_cpu_lock: If set to zero, hotplugs in and out second core when appropriate. Otherwise specifies no of cores to be considered for hotplugging. Leave it as default 0.
UNIT: Integer 0/1/2
hotplug_lock: Hotplugging second core is cancelled if it's value is greater than zero. The value should be greater than value of max_cpu_lock for a non-zero value. Leave it as 0.
UNIT: Integer 0/1/2
cpu_up_freq: Calculated as minimum of (its current value and maximum frequency), this tunable is actually not used by the governor.
UNIT: Kilo Hertz
cpu_down_freq: Calculated as maximum of ( its current value and minimum frequency), this tunable is actually not used by the governor.
UNIT: Kilo Hertz
up_nr_cpus: Calculated as minimum of (its current value and num of possible cpus), this tunable is used by the governor to indirectly make Hotplugging decisions, but may not be useful for a 2 core CPU.
UNIT: Integer 1/2
dvfs_debug: Set to 1 to enable governor logging. If you're an enthusiast, this may be useful to view the impact of the values for governor tunable set by inspecting the log.
UNIT: Boolean 1 or 0
pegasusq.html"]http://www.androidiani.com/forum/modding-huawei-ascend-p1/280978-governor-pegasusq.html
Informations about I/O Schedulers
Noop
Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.
Deadline
Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.
CFQ
Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.
BFQ
Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.
SIO
Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.
V(R)
Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.
FIFO
It is an acronym for First In, First Out, which is an abstraction related to ways of organizing and manipulation of data relative to time and prioritization. This expression describes the principle of a queue processing technique or servicing conflicting demands by ordering process by first-come, first-served (FCFS) behaviour. FCFS is also the jargon term for the FIFO operating system scheduling algorithm, which gives every process CPU time in the order they come. Disk controllers can use the FIFO as a disk scheduling algorithm to determine the order to service disk I/O requests.
Zen
The zen I/O scheduler is basically based off of no-op with some exceptions. It uses deadlines, prioritizes synchronous requests over asynchronous requests, and does no sorting or merging.
It's similar to SIO, but closer to no-op, whereas SIO is closer to deadline without sorting or merging (on SIO, writes can starve read requests/writes are prioritized over writes, it uses its own former/latter_request functions where zen just uses the elevator ones). I think dispatching is also slightly different on SIO, everything on zen is just back-inserted closer to FCFS (but still not pure FCFS like FIFO).(Thanks to the member Bbedward on rootzwiki.com http://rootzwiki.com/topic/35781-kernel-ada-4142-zenseries-vx-zenx-walking-tall/page__st__750)
Row
The ROW scheduling algorithm will be used in mobile devices as default block layer IO scheduling algorithm. 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.(Thanks to Tatyana Brokhman.http://comments.gmane.org/gmane.linux.ports.arm.msm/2911)
I/O Schedulers tunables explanations
Deadline, SIO and Zen :
fifo_batch: This determines the number of reads or writes to issue in a single batch. The default is 16. Setting this to a higher value may result in better throughput, but will also increase latency.
front_merges: You can set this tunable to 0 if you know your workload will never generate front merges. Unless you have measured the overhead of this check, it is advisable to leave it at its default setting (1).
read_expire: This tunable allows you to set the number of milliseconds in which a read request should be serviced. By default, this is set to 500 ms (half a second).
write_expire: This tunable allows you to set the number of milliseconds in which a write request should be serviced. By default, this is set to 5000 ms (five seconds).
writes_starved: This tunable controls how many read batches can be processed before processing a single write batch. The higher this is set, the more preference is given to reads.
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/ch06s04s02.html
CFQ
back_seek_max: Backward seeks are typically bad for performance, as they can incur greater delays in repositioning the heads than forward seeks do. However, CFQ will still perform them, if they are small enough. This tunable controls the maximum distance in KB the I/O scheduler will allow backward seeks. The default is 16 KB.
back_seek_penalty: Because of the inefficiency of backward seeks, a penalty is associated with each one. The penalty is a multiplier; for example, consider a disk head position at 1024KB. Assume there are two requests in the queue, one at 1008KB and another at 1040KB. The two requests are equidistant from the current head position. However, after applying the back seek penalty (default: 2), the request at the later position on disk is now twice as close as the earlier request. Thus, the head will move forward.
fifo_expire_async: This tunable controls how long an async (buffered write) request can go unserviced. After the expiration time (in milliseconds), a single starved async request will be moved to the dispatch list. The default is 250 ms.
fifo_expire_sync: This is the same as the fifo_expire_async tunable, for for synchronous (read and O_DIRECT write) requests. The default is 125 ms.
group_idle: When set, CFQ will idle on the last process issuing I/O in a cgroup. This should be set to 1 when using proportional weight I/O cgroups and setting slice_idle to 0 (typically done on fast storage).
group_isolation: If group isolation is enabled (set to 1), it provides a stronger isolation between groups at the expense of throughput. Generally speaking, if group isolation is disabled, fairness is provided for sequential workloads only. Enabling group isolation provides fairness for both sequential and random workloads. The default value is 0 (disabled). Refer to Documentation/cgroups/blkio-controller.txt for further information.
low_latency: When low latency is enabled (set to 1), CFQ attempts to provide a maximum wait time of 300 ms for each process issuing I/O on a device. This favors fairness over throughput. Disabling low latency (setting it to 0) ignores target latency, allowing each process in the system to get a full time slice. Low latency is enabled by default.
quantum: The quantum controls the number of I/Os that CFQ will send to the storage at a time, essentially limiting the device queue depth. By default, this is set to 8. The storage may support much deeper queue depths, but increasing quantum will also have a negative impact on latency, especially in the presence of large sequential write workloads.
slice_async: This tunable controls the time slice allotted to each process issuing asynchronous (buffered write) I/O. By default it is set to 40 ms.
slice_idle: This specifies how long CFQ should idle while waiting for further requests. The default value in Red Hat Enterprise Linux 6.1 and earlier is 8 ms. In Red Hat Enterprise Linux 6.2 and later, the default value is 0. The zero value improves the throughput of external RAID storage by removing all idling at the queue and service tree level. However, a zero value can degrade throughput on internal non-RAID storage, because it increases the overall number of seeks. For non-RAID storage, we recommend a slice_idle value that is greater than 0.
slice_sync: This tunable dictates the time slice allotted to a process issuing synchronous (read or direct write) I/O. The default is 100 ms.
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/ch06s04.html#id3044417
BFQ
timeout_sync, timeout_async: the maximum amount of disk time that can be given to a task once it has been selected for service, respectively for synchronous and asynchronous queues. It allows the user to specify a maximum slice length to put an upper bound to the latencies imposed by the scheduler.
max_budget: the maximum amount of service, measured in disk sectors, that can be provided to a queue once it is selected (of course within the limits of the above timeouts). According to what we said in the description of the algoritm, larger values increase the throughput for the single tasks and for the system, in proportion to the percentage of sequential requests issued. The price is increasing the maximum latency a request may incur in. The default value is 0, which enables auto-tuning: BFQ tries to estimate it as the maximum number of sectors that can be served during timeout_sync.
max_budget_async_rq: in addition to the max_budget, limit, async queues are served for a maximum number of requests, after that a new queue is selected.
low_latency: if equal to 1 (default value), interactive and soft real-time applications are privileged and experience a lower latency.
http://algo.ing.unimo.it/people/paolo/disk_sched/description.php
Row:
hp_read_quantum: dispatch quantum for the high priority READ queue
rp_read_quantum: dispatch quantum for the regular priority READ queue
hp_swrite_quantum: dispatch quantum for the high priority Synchronous WRITE queue
rp_swrite_quantum: dispatch quantum for the regular priority Synchronous WRITE queue
rp_write_quantum: dispatch quantum for the regular priority WRITE queue
lp_read_quantum: dispatch quantum for the low priority READ queue
lp_swrite_quantum: dispatch quantum for the low priority Synchronous WRITE queue
read_idle: how long to idle on read queue in Msec (in case idling is enabled on that queue).
read_idle_freq: frequency of inserting READ requests that will trigger idling. This is the time in Msec between inserting two READ requests
(http://lwn.net/Articles/509829/)
With 4G LTE running most of the day...
Ondemand/bfq
Oc 1674 min 384
Touch Boosters 1242 & 918
Screen Off 384
Voltages lowered 50 or 100 across the board
ARIEL 2.07 ICS rom
Sent from my SAMSUNG-SGH-I747 using Tapatalk 2
Have you tried ktoonservative?
Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, noop, ktoonservative, undervolted, 3150mAh battery.
Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!
How many minutes of asphalt 7?
Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, noop, ktoonservative, undervolted, 3150mAh battery.
Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!
liltitiz said:
Have you tried ktoonservative?
Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, noop, ktoonservative, undervolted, 3150mAh battery.
Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!
Click to expand...
Click to collapse
Yes, I tried ktoonservative and noop at first, but for some reason it was draining my battery pretty fast (probably 8hr battery life). That was the 9-5 build, maybe my phone just doesn't like those settings, I'm not sure.
liltitiz said:
How many minutes of asphalt 7?
Click to expand...
Click to collapse
About 20 mins of Asphalt 7
Do you guys really see a difference in battery life by setting your screen off profile to 384-486? That just means a longer time to idle and 1/5th the clock cycles at 800mv vs 1080mv?
I have my screen off at 810mhz, although I have 810mhz uv to 800mv so going any lower is a waste
Sent from my SGH-I747 using Tapatalk 2
quick questions geniouses....for someone who doesnt know much about this kernel tweaking and uses their device moderately for phone, texting, facebook and music, what is the best setting you guys would recommend?
thuglifesk said:
quick questions geniouses....for someone who doesnt know much about this kernel tweaking and uses their device moderately for phone, texting, facebook and music, what is the best setting you guys would recommend?
Click to expand...
Click to collapse
Sio schedulor with Pegasusq governor and try some under voting. Screen off profile around 486. Drop the vibration strength.
Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, noop, ktoonservative, undervolted, 3150mAh battery.
Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!
thuglifesk said:
quick questions geniouses....for someone who doesnt know much about this kernel tweaking and uses their device moderately for phone, texting, facebook and music, what is the best setting you guys would recommend?
Click to expand...
Click to collapse
I recommend not tweaking anything. The kernel alone provides better battery life and smooth experience. Although no harm in trying different governors and io schedulers. Try ktoonservative governor for better battery life.
liltitiz said:
Sio schedulor with Pegasusq governor and try some under voting. Screen off profile around 486. Drop the vibration strength.
Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, noop, ktoonservative, undervolted, 3150mAh battery.
Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!
Click to expand...
Click to collapse
Thanks will try these settings... whats the different between the different schedulors and governors? sorry for the general questions.
thuglifesk said:
Thanks will try these settings... whats the different between the different schedulors and governors? sorry for the general questions.
Click to expand...
Click to collapse
This should answer most of your questions on governors/schedulers:
http://forum.xda-developers.com/showthread.php?t=1687578
thuglifesk said:
Thanks will try these settings... whats the different between the different schedulors and governors? sorry for the general questions.
Click to expand...
Click to collapse
Read this
http://forum.xda-developers.com/showthread.php?t=1558153
http://forum.xda-developers.com/showthread.php?t=1496777
Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, noop, ktoonservative, undervolted, 3150mAh battery.
Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!
Hi liltitiz! I am really interested in trying your setup but when i applied your voltages my phone restarted and I ended up with all the defaults again
theraker007 said:
Hi liltitiz! I am really interested in trying your setup but when i applied your voltages my phone restarted and I ended up with all the defaults again
Click to expand...
Click to collapse
Your phone don't handle this under voltage try these:
MHz/stock mv/my mv/-mv amount
96/925/785/-140
144/925/790/-135
192/925/800/-125
384/925/825/-100
486/925/845/-80
540/950/865/-85
594/950/875/-75
648/975/890/-85
702/975/895/-80
756/1025/950/-75
810/1025/955/-70
864/1050/970/-80
918/1050/980/-70
972/1075/985/-90
1026/1075/990/-85
1080/1125/1015/-110
1134/1125/1025/-100
1188/1150/1040/-110
1242/1150/1055/-95
1296/1175/1065/-110
1350/1175/1080/-95
1404/1185/1095/-90
1458/1185/1110/-75
1512/1200/1120/-80
1674/1200/1125/-75
1728/1250/1145/-105
1809/1275/1185/-90
1890/1300/1215/-85
1998/1325/1240/-85
2106-1350-1300
For the steps 1809 to 2106 dont under volt too much. From these voltage test the limit of your phone
Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, noop, ktoonservative, undervolted, 3150mAh battery.
Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!
The new setting I'm trying right now looks badass. I'll post the results later tonight!
Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, noop, ktoonservative, undervolted, 3150mAh battery.
Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!
Running Parinoid Android v2.1 with Ktoonsez's KT747 9/13 Jelly Bean kernel
I/O Scheduler = noop
Governor = ktoonservative
Mhz ______ mV _____ Difference from stock
1512______1075_____-125
1458______1050_____-135
1404______1040_____-145
1350______1025_____-150
1296______1015_____-160
1242______1000_____-150
1188______0985_____-165
1134______0970_____-155
1080______0955_____-170
1026______0925_____-150
0972______0910_____-165
0918______0900_____-150
0864______0890_____-160
0810______0875_____-150
0756______0855_____-170
0702______0825_____-150
0648______0815_____-160
0594______0800_____-150
0540______0785_____-165
0486______0775_____-150
0384______0770_____-155
0192______0755_____-170
0144______0745_____-180
0096______0745_____-180
Sorry if I didn't post anything yet but my battery las longer than expected!
Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, noop, ktoonservative, undervolted, 3150mAh battery.
Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!
So here it is!
View attachment 1330080
View attachment 1330081
96Mhz-2106Mhz
Screen off profile: 486MHz
Scheduler: SIO
Governor: Pegasusq
Kernel: kt747 9/13
Rom: AOKP 9/13
pegasusQ settings:
cpu down rate:20
cpu up rate:10
down differential:10
dvfs debug:0
freq for responsiveness:500000
freq step:9
hotplug 1_1:500000
hotplug 2_0:200000
hotplug 2_1:500000
ignore nice load:0
io is busy:0
max cpu clock:0
min cpu lock:0
sampling down factor:4
sampling rate:10000
sampling rate min:10000
up nr cpus:1
up treshold:90
up treshold at min freq:70
Under voltage values:
2106MHz - 1250mv
1998MHz - 1190mv
1890MHz - 1165mv
1809MHz - 1135mv
1728 MHz - 1090mV
1674 MHz - 1075mV
1512 MHz - 1065mV
1458 MHz - 1050mV
1404 MHz - 1040mV
1350 MHz - 1025mV
1296 MHz - 1015mV
1242 MHz - 1000mV
1188 MHz - 990mV
1134 MHz - 970mV
1080 MHz - 950mV
1026 MHz - 930mV
972 MHz - 910mV
918 MHz - 890mV
864 MHz - 875mV
810 MHz - 860mV
756 MHz - 845mV
702 MHz - 830mV
648 MHz - 815mV
594 MHz - 800mV
540 MHz - 790mV
486 MHz - 780mV
384 MHz - 770mV
192 MHz - 760mV
144 MHz - 750mV
96 MHz - 740mV
Give these a try! Worth it
Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, sio, pegasusq, undervolted, 3150mAh battery.
Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!
This post was not written by me, but by droidphile. I am sharing this here so that it's easier to find since this is a must read for every android/kernel enthusiast. Excellent work by droidphile. Thanks!
Most of us are flash maniacs, and we do it a lot. But after a kernel flash, we wonder:
Q. "OK i have flashed this xyz kernel. What're all these governors? How do i know which one is the best for me? How do i tweak them to bias their characters towards Battery-life/Performance/Balance between the Two".
Hope this thread could give you answers for all these questions. We're covering governors, modules, i/o schedulers that comes with Siyah kernel, plus more. That should cover almost all the popular governors/modules/io schedulers! Many people seem to get lost in Kernel dev threads without getting answers about governors and such.
The info in this thread holds good for non-siyah kernel users too. You should find here, info on most of the governors/modules/io schedulers in your kernel if not all.
Thanks To
1) Gokhanmoral for his mighty sweet Siyah Kernel which inspired me to write this thread.
2) Moderators for squeezing in extra posts when i ran out of space to fit everything in only 3 reserved posts.
3) Users/Readers for your warm comments.
** Kernel Governors: **
These are the 19 governors we're talking about.
1) Ondemand
2) Ondemandx
3) Conservative
4) Interactive
5) Interactivex
6) Lulzactive
7) Lulzactiveq
8) Smartass
9) SmartassV2
10) Intellidemand
11) Lazy
12) Lagfree
13) Lionheart
14) LionheartX
15) Brazilianwax
16) SavagedZen
17) Userspacce
18) Powersave
19) Performance
NOTE: Info on Samsung's own multi-core aware governor - Pegasusq is here
1) Ondemand:
Default governor in almost all stock kernels. One main goal of the ondemand governor is to switch to max frequency as soon as there is a CPU activity detected to ensure the responsiveness of the system. (You can change this behavior using smooth scaling parameters, refer Siyah tweaks at the end of 3rd post.) Effectively, it uses the CPU busy time as the answer to "how critical is performance right now" question. So Ondemand jumps to maximum frequency when CPU is busy and decreases the frequency gradually when CPU is less loaded/apporaching idle. Even though many of us consider this a reliable governor, it falls short on battery saving and performance on default settings. One potential reason for ondemand governor being not very power efficient is that the governor decide the next target frequency by instant requirement during sampling interval. The instant requirement can response quickly to workload change, but it does not usually reflect workload real CPU usage requirement in a small longer time and it possibly causes frequently change between highest and lowest frequency.
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) Conservative:
A slower Ondemand which scales up slowly to save battery. The conservative governor is based on the ondemand governor. It functions like the Ondemand governor by dynamically adjusting frequencies based on processor utilization. However, the conservative governor increases and decreases CPU speed more gradually. Simply put, this governor increases the frequency step by step on CPU load and jumps to lowest frequency on CPU idle. Conservative governor aims to dynamically adjust the CPU frequency to current utilization, without jumping to max frequency. The sampling_down_factor value acts as a negative multiplier of sampling_rate to reduce the frequency that the scheduler samples the CPU utilization. For example, if sampling_rate equal to 20,000 and sampling_down_factor is 2, the governor samples the CPU utilization every 40,000 microseconds.
4) Interactive:
Can be considered a faster ondemand. So more snappier, less battery. Interactive is designed for latency-sensitive, interactive workloads. Instead of sampling at every interval like ondemand, it determines how to scale up when CPU comes out of idle. The governor has the following advantages: 1) More consistent ramping, because existing governors do their CPU load sampling in a workqueue context, but interactive governor does this in a timer context, which gives more consistent CPU load sampling. 2) Higher priority for CPU frequency increase, thus giving the remaining tasks the CPU performance benefit, unlike existing governors which schedule ramp-up work to occur after your performance starved tasks have completed. Interactive It's an intelligent Ondemand because of stability optimizations. Why??
Sampling the CPU load every X ms (like Ondemand) can lead to under-powering the CPU for X ms, leading to dropped frames, stuttering UI, etc. Instead of sampling the CPU at a specified rate, the interactive governor will check whether to scale the CPU frequency up soon after coming out of idle. When the CPU comes out of idle, a timer is configured to fire within 1-2 ticks. If the CPU is very busy between exiting idle and when the timer fires, then we assume the CPU is underpowered and ramp to max frequency.
5) Interactivex:
This is an Interactive governor with a wake profile. More battery friendly than interactive.
6) Lulzactive:
This new find from Tegrak is based on Interactive & Smartass governors and is one of the favorites.
Old Version: When workload is greater than or equal to 60%, the governor scales up CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step. When screen is off, frequency is locked to global scaling minimum frequency.
New Version: Three more user configurable parameters: inc_cpu_load, pump_up_step, pump_down_step. Unlike older version, this one gives more control for the user. We can set the threshold at which governor decides to scale up/down. We can also set number of frequency steps to be skipped while polling up and down.
When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. When workload is less than inc_cpu_load, governor scales CPU down pump_down_step steps down.
Example:
Consider
inc_cpu_load=70
pump_up_step=2
pump_down_step=1
If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800.
If current frequency =1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.
7) Lulzactiveq:
Lulzactiveq is a modified lulzactive governor authored by XDA member robertobsc and is adapted in Siyah kernel for GS2 and GS3. Lulzactiveq aims to optimize the second version of luzactive from Tegrak by a) providing an extra parameter (dec_cpu_load) to make scaling down more sensible, and b) incorporating hotplug logic to the governor. Luzactiveq is the first ever interactive based governor with hotplugging logic inbuilt (atleast the first of its kind for the exynos platform). When CPU comes out of idle loop and it's time to make a scaling decision, if load >= inc_cpu_load CPU is scaled up (like original luzactiveq) and if load <dec_cpu_load, CPU is scaled down. This possibly eliminates the strict single cut-off frequency for luzactiveq to make CPU scaling decisions. Also, stand hotplug logic runs as a separate thread with the governor so that external hotplugging logic is not required to control hotplug in and out (turn On and Off) CPU cores in multi core devices like GS2 or GS3. Only a multi core aware governor makes real sense on muti-core devices. Lulzactiveq and pegasusq aims to do that.
8) Smartass:
Result of Erasmux rewriting the complete code of interactive governor. Main goal is to optimize battery life without comprising performance. Still, not as battery friendly as smartassV2 since screen-on minimum frequency is greater than frequencies used during screen-off. Smartass would jump up to highest frequency too often as well.
9) 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.
10) 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.
11) 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.
12) 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.
13) Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source. Tweaks comes from 1) Knzo 2) Morfic. The original idea comes from Netarchy. See here. The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
To 'experience' Lionheart using conservative, try these tweaks:
sampling_rate:10000 or 20000 or 50000, whichever you feel is safer. (transition latency of the CPU is something below 10ms/10,000uS hence using 10,000 might not be safe).
up_threshold:60
down_threshold:30
freq_step:5
Lionheart goes well with deadline i/o scheduler. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand.
14) LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
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) Userspace:
Instead of automatically determining frequencies, lets user set frequencies.
18) Powersave:
Locks max frequency to min frequency. Can not be used as a screen-on or even screen-off (if scaling min frequency is too low).
19) Performance:
Sets min frequency as max frequency. Use this while benchmarking!
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.
** reserved **
Thanks teeshx....
Sent from my SGH-T889 using xda app-developers app
Thanks teshxx. This is great for a noob like myself.
Sent from my SAMSUNG-SGH-T889 using xda app-developers app
Where is pegasusq? I guess this governor is for note.
Sent from my SGH-T889 using xda premium
jay661972 said:
Where is pegasusq? I guess this governor is for note.
Sent from my SGH-T889 using xda premium
Click to expand...
Click to collapse
Read the thread CAREFULLY. It's there.
This should be stickied.
Sent from my GT-N7105 using xda app-developers app
THANK YOU... I have been confused about this forever, Never cared to look it up, just set to performance everytime. teshxx, you have saved my device several times. Thank you for your work. You will be recieving a beer or two from me soon. . Keep up the :good: work!
Thank you so mutch for the work, but i don't understand with is the best to save the battery than stock CM10.1:
Pegasusq, ondemand( i read no), userpace, or performance.
................................................................................
Enviado desde mi Tamagotchi usando Tapatalk™ ©
Pickpoket said:
THANK YOU... I have been confused about this forever, Never cared to look it up, just set to performance everytime. teshxx, you have saved my device several times. Thank you for your work. You will be recieving a beer or two from me soon. . Keep up the :good: work!
Click to expand...
Click to collapse
kylesinho21 said:
Thank you so mutch for the work, but i don't understand with is the best to save the battery than stock CM10.1:
Pegasusq, ondemand( i read no), userpace, or performance.
................................................................................
Enviado desde mi Tamagotchi usando Tapatalk™ ©
Click to expand...
Click to collapse
Welcome!! I am glad you guys found it useful.
I personally use pegasusq. For TW, I use Perseus kernel and for CM, I use bullet kernel (extracted it from PA lol)
teshxx said:
Welcome!! I am glad you guys found it useful.
I personally use pegasusq. For TW, I use Perseus kernel and for CM, I use bullet kernel (extracted it from PA lol)
Click to expand...
Click to collapse
Thanck you so much for your work and your answer, you are great!
................................................................................
Enviado desde mi Tamagotchi usando Tapatalk™ ©
Your description of interactive and ondemand off quite a bit...
Ondemand uses parameters like polling intervals (sampling rate), CPU load thresholds (percentage of max CPU loads), down thresholds and differentials, to figure out when to scale the CPU up and out of idle. It does not come out of idle and scale to max frequency right away.
Interactive uses a sampling time but works differently... rather than have down thresholds and down differentials, it polls CPU and determines whether or not a percentage of max load has been met. If it has, it jumps to max frequency for (x) milliseconds. Then scales down.
cobraboy85 said:
Your description of interactive and ondemand off quite a bit...
Ondemand uses parameters like polling intervals (sampling rate), CPU load thresholds (percentage of max CPU loads), down thresholds and differentials, to figure out when to scale the CPU up and out of idle. It does not come out of idle and scale to max frequency right away.
Interactive uses a sampling time but works differently... rather than have down thresholds and down differentials, it polls CPU and determines whether or not a percentage of max load has been met. If it has, it jumps to max frequency for (x) milliseconds. Then scales down.
Click to expand...
Click to collapse
Will take a look and compare. Thanks for the heads up.
Virtuous?
THX ... Very Informative :good:
I DID NOT CREATE THE ORIGINAL LIST OF 20 GOVERNORS BUT I DID ADD MORE AND I DID TAKE THE TIME TO DOUBLE CHECK EACH INDIVIDUAL GOVERNOR TO MAKE SURE THEY WERE CORRECT...I MADE THIS SOLELY SO PEOPLE DONT HAVE TO GO BACK TEN PAGES TO SEE IT...a big thanks to rEcEivEr for the original thread/post I found and all the other original OP's.
If you feel any are missing or if there are new ones I missed please let me know and we'll add them....hope this helps because I see plenty of people asking.
So let's get to it...
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: BadAss
23: Wheatley
24: Lulzactive
25: Pegasusq/Pegasusd
26: hotplugx
27: AbissPlug
28: MSM DCVS
29: Dyninteractive
30: Sakuractive (Thanks to Sandman-007)
31: Ktoonservative (Thanks to EniGmA1987)
32: Zen (Thanks to EniGmA1987)
1: OnDemand Governor:
This governor has a hair trigger for boosting clockspeed to the maximum speed set by the user. If the CPU load placed by the user abates, the OnDemand governor will slowly step back down through the kernel's frequency steppings until it settles at the lowest possible frequency, or the user executes another task to demand a ramp.
OnDemand has excellent interface fluidity because of its high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand is commonly chosen by smartphone manufacturers because it is well-tested, reliable, and virtually guarantees the smoothest possible performance for the phone. This is so because users are vastly more likely to ***** about performance than they are the few hours of extra battery life another governor could have granted them.
This final fact is important to know before you read about the Interactive governor: OnDemand scales its clockspeed in a work queue context. In other words, once the task that triggered the clockspeed ramp is finished, OnDemand will attempt to move the clockspeed back to minimum. If the user executes another task that triggers OnDemand's ramp, the clockspeed will bounce from minimum to maximum. This can happen especially frequently if the user is multi-tasking. This, too, has negative implications for battery life.
2: OndemandX:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
3: Performance Governor:
This locks the phone's CPU at maximum frequency. While this may sound like an ugly idea, there is growing evidence to suggest that running a phone at its maximum frequency at all times will allow a faster race-to-idle. Race-to-idle is the process by which a phone completes a given task, such as syncing email, and returns the CPU to the extremely efficient low-power state. This still requires extensive testing, and a kernel that properly implements a given CPU's C-states (low power states).
4: Powersave Governor:
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
5:Conservative Governor:
This biases the phone to prefer the lowest possible clockspeed as often as possible. In other words, a larger and more persistent load must be placed on the CPU before the conservative governor will be prompted to raise the CPU clockspeed. Depending on how the developer has implemented this governor, and the minimum clockspeed chosen by the user, the conservative governor can introduce choppy performance. On the other hand, it can be good for battery life.
The Conservative Governor is also frequently described as a "slow OnDemand," if that helps to give you a more complete picture of its functionality.
6: Userspace Governor:
This governor, exceptionally rare for the world of mobile devices, allows any program executed by the user to set the CPU's operating frequency. This governor is more common amongst servers or desktop PCs where an application (like a power profile app) needs privileges to set the CPU clockspeed.
7: Min Max
well this governor makes use of only min & maximum frequency based on workload... no intermediate frequencies are used.
8: Interactive Governor:
Much like the OnDemand governor, the Interactive governor dynamically scales CPU clockspeed in response to the workload placed on the CPU by the user. This is where the similarities end. Interactive is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Unlike OnDemand, which you'll recall scales clockspeed in the context of a work queue, Interactive scales the clockspeed over the course of a timer set arbitrarily by the kernel developer. In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. This can eliminate the frequency bouncing discussed in the OnDemand section. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. This is another pro-battery life benefit of Interactive.
However, because Interactive is permitted to spend more time at maximum frequency than OnDemand (for device performance reasons), the battery-saving benefits discussed above are effectively negated. Long story short, Interactive offers better performance than OnDemand (some say the best performance of any governor) and negligibly different battery life.
Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.
9: InteractiveX Governor:
Created by kernel developer "Imoseyon," the InteractiveX governor is based heavily on the Interactive governor, enhanced with tuned timer parameters to better balance battery vs. performance. The InteractiveX governor's defining feature, however, is that it locks the CPU frequency to the user's lowest defined speed when the screen is off.
10: Smartass
Is based on the concept of the interactive governor.
I have always agreed that in theory the way interactive works – by taking over the idle loop – is very attractive. I have never managed to tweak it so it would behave decently in real life. Smartass is a complete rewrite of the code plus more. I think its a success. Performance is on par with the “old” minmax and I think smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Smartass will also cap the max frequency when sleeping to 352Mhz (or if your min frequency is higher than 352 – why?! – it will cap it to your min frequency). Lets take for example the 528/176 kernel, it will sleep at 352/176. No need for sleep profiles any more!"
11: SmartassV2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery.
12: Scary
A new governor wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It will give the same performance as conservative right now, it will get tweaked over time.
13: Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.
14: Smoothass:
The same as the Smartass “governor” But MUCH more aggressive & across the board this one has a better battery life that is about a third better than stock KERNEL
15: Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery
16: SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
17: Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.
18: Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source.
The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
19: LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
20: Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors)
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
21: Hotplug Governor:
The Hotplug governor performs very similarly to the OnDemand governor, with the added benefit of being more precise about how it steps down through the kernel's frequency table as the governor measures the user's CPU load. However, the Hotplug governor's defining feature is its ability to turn unused CPU cores off during periods of low CPU utilization. This is known as "hotplugging."
22: BadAss Governor:
Badass removes all of this "fast peaking" to the max frequency. On a typical system the cpu won't go above 918Mhz and therefore stay cool and will use less power. To trigger a frequency increase, the system must run a bit @ 918Mhz with high load, then the frequency is bumped to 1188Mhz. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 1-2 seconds, depending on the load your system is experiencing)
Badass will also take the gpu load into consideration. If the gpu is moderately busy it will bypass the above check and clock the cpu with 1188Mhz. If the gpu is crushed under load, badass will lift the restrictions to the cpu.
23: Wheatley:
Building on the classic 'ondemand' governor is implemented Wheatley governor. The governor has two additional parameters:
target_residency - The minimum average residency in µs which is considered acceptable for a proper efficient usage of the C4 state. Default is 10000 = 10ms.
allowed_misses - The number sampling intervals in a row the average residency is allowed to be lower than target_residency before the governor reduces the frequency. This ensures that the governor is not too aggressive in scaling down the frequency and reduces it just because some background process was temporarily causing a larger number of wakeups. The default is 5.
Wheatley works as planned and does not hinder the proper C4 usage for task where the C4 can be used properly .
For internet browsing the time spend in C4 has increased by 10% points and the average residency has increased by about 1ms. I guess these differences are mostly due to the different browsing behaviour (I spend the last time more multi-tabbing). But at least we can say that Wheatley does not interfere with the proper use of the C4 state during 'light' tasks. For music playback with screen off the time spend in C4 is practically unchanged, however the average residency is reduced from around 30ms to around 18ms, but this is still more than acceptable.
So the results show that Wheatley works as intended and ensures that the C4 state is used whenever the task allows a proper efficient usage of the C4 state. For more demanding tasks which cause a large number of wakeups and prevent the efficient usage of the C4 state, the governor resorts to the next best power saving mechanism and scales down the frequency. So with the new highly-flexible Wheatley governor one can have the best of both worlds.
Obviously, this governor is only available on multi-core devices.
24: Lulzactive:
Lulzactive:
This new find from Tegrak is based on Interactive & Smartass governors and is one of the favorites.
Old Version: When workload is greater than or equal to 60%, the governor scales up CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step. When screen is off, frequency is locked to global scaling minimum frequency.
New Version: Three more user configurable parameters: inc_cpu_load, pump_up_step, pump_down_step. Unlike older version, this one gives more control for the user. We can set the threshold at which governor decides to scale up/down. We can also set number of frequency steps to be skipped while polling up and down.
When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. When workload is less than inc_cpu_load, governor scales CPU down pump_down_step steps down.
Example:
Consider
inc_cpu_load=70
pump_up_step=2
pump_down_step=1
If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800.
If current frequency =1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.
25: Pegasusq/Pegasusd
The Pegasus-q / d is a multi-core based on the Ondemand governor and governor with integrated hot-plugging.
Ongoing processes in the queue, we know that multiple processes can run simultaneously on. These processes are active in an array, which is a field called "Run Queue" queue that is ongoing, with their priority values arranged (priority will be used by the task scheduler, which then decides which process to run next).
To ensure that each process has its fair share of resources, each running for a certain period and will eventually stop and then again placed in the queue until it is your turn again. If a program is terminated, so that others can run the program with the highest priority in the current queue is executed.
26: hotplugx
It 'a Hotplug modified and optimized for the suspension in off-screen
27: AbissPlug
It 'a Governor derived hotplug, it works the same way, but with the changes in savings for a better battery.
28: MSM DCVS
a very efficient and wide range of Dynamic Clock and
Voltage Scaling (DCVS) which addresses usage models from
active standby to mid and high level processing requirements.
A Krait CPU can smoothly scale from low power, low
leakage mode to blazingly fast performance.
Believe it's a governor that is mfg'd by qualcomm to utilize new on chip features.
MSM is the prefix for the SOC (MSM8960) and DCVS is Dynamic Clock and Voltage Scaling. Makes sense, MSM-DCVS
29: Dyninterative
Similar to interactive in almost every way possible except it "dyn"amically adapts its own tunables and settings depending on system load
30: Sakuractive: This driver mimics the frequency scaling behavior in "on demand" but with several key differences. First is that frequency transitions use the CPUFreq table directly, instead of incrementing in a percentage of the maximum available frequency. Second "sakuractive" will offline auxillary CPUs when the system is idle, and online those CPUs once the system becomes busy again. This last feature is needed for architectures which transition to low power states when only the "master" CPU is online, or for thermally constrained devices
31: Ktoonservative
There is so much going on with this governor I'd rather have the makers explain it themselves....so here you go
http://forum.xda-developers.com/showthread.php?t=2032956
32: Zen
It's an FCFS (First come, first serve) based algorithm. It does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ones.
only few of them available on my gnex
ps000000 said:
only few of them available on my gnex
Click to expand...
Click to collapse
The available governors will depend on the kernel you are using.
cupfulloflol said:
The available governors will depend on the kernel you are using.
Click to expand...
Click to collapse
ps000000 said:
only few of them available on my gnex
Click to expand...
Click to collapse
Exactly what cupfulloflol said its going to depend on which kernel you are using
Re: Galaxy Nexus Governors Explained
You are missing a very popular governor: sakuractive
Toro | Atom v9 | AK Cylon 801
Sandman-007 said:
You are missing a very popular governor: sakuractive
Toro | Atom v9 | AK Cylon 801
Click to expand...
Click to collapse
Thanks I'll add it
Sandman-007 said:
You are missing a very popular governor: sakuractive
Toro | Atom v9 | AK Cylon 801
Click to expand...
Click to collapse
Updated.... thanks again Sandman
JamesPumaEnjoi said:
Updated.... thanks again Sandman
Click to expand...
Click to collapse
No prob bro. Thanks for the guide
Toro | Atom v9 | AK Cylon 801
Any chance you could do a list about io schedulers and tcp congestion profiles too?
eqjunkie829 said:
Any chance you could do a list about io schedulers and tcp congestion profiles too?
Click to expand...
Click to collapse
Absolutely... I'm actually off all next week from school I'll get started this weekend
Sandman-007 said:
No prob bro. Thanks for the guide
Toro | Atom v9 | AK Cylon 801
Click to expand...
Click to collapse
My pleasure man
Nice :thumbup:
Sent from my Galaxy using xda premium
ranalab said:
Nice :thumbup:
Sent from my Galaxy using xda premium
Click to expand...
Click to collapse
Thanks man I appreciate it
Thanks! This is a great guide and I have been looking for something like this especcialy with flashing new kernels all the time this will be a big help and a good reference.
the cronic dude said:
Thanks! This is a great guide and I have been looking for something like this especcialy with flashing new kernels all the time this will be a big help and a good reference.
Click to expand...
Click to collapse
Not a problem at all just happy its helping some people out
Great Thread :thumbup:
Inviato dal mio Galaxy Nexus con Tapatalk 2
good
good to know
SamueleCiprietti said:
Great Thread :thumbup:
Inviato dal mio Galaxy Nexus con Tapatalk 2
Click to expand...
Click to collapse
dizzy1k said:
good to know
Click to expand...
Click to collapse
Thanks guys glad it helped you
JamesPumaEnjoi said:
Absolutely... I'm actually off all next week from school I'll get started this weekend
Click to expand...
Click to collapse
Thank you so much for doing that , i cant find anything on TCP congestion that i can actually understand , this is the easiest guide to read about the different governors that I've come across . Great job man :thumbup:
Sent from my Galaxy Nexus using Xparent Cyan Tapatalk 2
bsmitty83 said:
Thank you so much for doing that , i cant find anything on TCP congestion that i can actually understand , this is the easiest guide to read about the different governors that I've come across . Great job man :thumbup:
Sent from my Galaxy Nexus using Xparent Cyan Tapatalk 2
Click to expand...
Click to collapse
Working on it....slowly but surely working on it . It'll be done soon