Develop Bugs

[Q] SETCPU GOvernOrs

okay i have a huge question about this... PLease Share YOUR Thoughts and experiences TOoOO!
we are using custom kernels right? but sometimes the developer/creator of the kernel doesnt mention on what recommended usage of the main profile and profile..
so i decided to put some description about this governs that i have gathered around in XDA FORUM so we can share our knowledge on this GOverns.
okay first.. i found this..
smartass governor - 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.
ondemand
Available in most kernels, and the default governor in most kernels. When the CPU load reaches a certain point (see "up threshold" in Advanced Settings), ondemand will rapidly scale the CPU up to meet demand, then gradually scale the CPU down when it isn't needed. - SetCPU website
conservative
Available in some kernels. It is similar to the ondemand governor, but will scale the CPU up more gradually to better fit demand. Conservative provides a less responsive experience than ondemand, but can save battery. - SetCPU website
performance
Available in most kernels. It will keep the CPU running at the "max" set value at all times. This is a bit more efficient than simply setting "max" and "min" to the same value and using ondemand because the system will not waste resources scanning for the CPU load. This governor is recommended for stable benchmarking. - SetCPU website
powersave
Available in some kernels. It will keep the CPU running at the "min" set value at all times. - SetCPU website
userspace
A method for controlling the CPU speed that isn't currently used by SetCPU. For best results, do not use the userspace governor. - SetCPU website
interactive
Advantages:
+ significantly more responsive to ramp cpu up when required (UI interaction)
+ more consistent ramping, existing governors do their cpu load sampling in a workqueue context, the 'interactive' governor does this in a timer context, which gives more consistent cpu load sampling.
+ higher priority for cpu frequency increase, rt_workqueue is used for scaling up, giving the remaining tasks the cpu performance benefit, unlike existing governors which schedule rampup work to occur after your performance starved tasks have completed.
SOURCES:
http://forum.xda-developers.com/showthread.php?t=969477
https://github.com/CyanogenMod/cm-kernel/commit/255f13bf41f368aa51638a854ed69cfc60f39120

Nice thread. I am new to this stuff (I learned just yesterday what governors are) and all this will be very usefull for people like me. Thanx.

In the SetCPU app, if you press About and then click the link you can get all this info there too

So Guys,
Im using Buzz 1.3.5 kernel at 1.2 Ghz (1.6 Ghz max), with ARHD rom.
What the best processor type to battery life \ performance ?
Any kind of values to screen of and temp > 50º or 40º ?
Thank you , lets share our configurations and post results !

so how do we get smartass? Im currently trying out interactive.

So guys, no one can put here some configurations?
Like, screen off values, > 50º temp, and others ?
Come on, share pls..

[Q] [CyanogenMod7 RC4] Overclock and Performance Settings

Hi,
I've just noticed the Performance settings menu under the CyanogenMod Settings menu and I wanted to give overclock and other features a try...safely.
I'm looking for increasing my Wildfire's performance in a remarkable way but without harming or causing any trouble to the phone. So I'd like to start in a quite conservative way.
What governor should I choose? (default: smartass)
What max and min CPU frequency? (default 518 and 352 Mhz)
What about the VM heap size? (default 24m)
What do you guys use as your settings?
Thanks a lot!

Governor : Smartass
CPU Speeds : 264 Min, 652 Max
VM Heap Size : 32 M
Remember, don't expect miracles by OC'ing your CPU. You'll probably be disappointed.

Thanks for answering!
In the meanwhile I set up 264 as min and 691 as max...is that too much and potentially dangerous?
No miracles indeed but the phone felt a bit more snappy when playing games for example.
Do you know where I can find some info about the different governors?
Also, what is exactly the VM heap size?
Thank you!

No, wont harm it. Only if you experience instability, reduce it to the next (Or rather, Previous) level.
CPU Governors:
* ondemand – Available in most kernels, and the default governor in most kernels. When the CPU load reaches a certain point (see “up threshold” in Advanced Settings), ondemand will rapidly scale the CPU up to meet demand, then gradually scale the CPU down when it isn't needed.
* conservative – Available in some kernels. It is similar to the ondemand governor, but will scale the CPU up more gradually to better fit demand. Conservative provides a less responsive experience than ondemand, but can save battery.
* performance – Available in most kernels. It will keep the CPU running at the “max” set value at all times. This is a bit more efficient than simply setting “max” and “min” to the same value and using ondemand because the system will not waste resources scanning for CPU load.
* powersave – Available in some kernels. It will keep the CPU running at the “min” set value at all times.
* userspace – A method for controlling the CPU speed that isn't currently used by SetCPU. For best results, do not use the userspace governor.
(The above wall of text is lifted from SetCPU's site)
In addition to that , Smartass is really the smart one. When your screen is on, the minimum frequency will automatically be set to 518 MHz, making your phone seem it is flying, and, when the screen is off, then, it reverts back to the minimum set value, and saves battery - Best of both worlds!
As for VM Heap Size, it is the maximum amount of heap space (i.e. memory) a single instance of the Dalvik VM (application) can obtain. Technical concept, but, you can read it up more if you like.

Thanks a lot for the insigthful reply, everything's clearer now!

i put everything on max. but thats just me. phone works fine though :L

Hi,
What's the best setting for my battery? It drains so fast.
Mine is as following:
Min.: 245 Mhz
Max.: 537 Mhz
INTERACTIVE
I have to charge the Phone every evening, thats a bit annoying.
Thank you in advance

When using the cyanogenmod settings for the cpu speed,setcpu isn't required anymore right?
Sent from my HTC Wildfire using XDA App

FrydaeXIII said:
When using the cyanogenmod settings for the cpu speed,setcpu isn't required anymore right?
Sent from my HTC Wildfire using XDA App
Click to expand...
Click to collapse
Yes, you are right. Conflicting apps are never recommended.

thanks for the tip...

Governors explained

Found this in EVO 4G section, thought I would share.
CPU Governors explained
Thanks to deedii for posting this in another forum:
http://forum.xda-developers.com/show...65&postcount=2
Android CPU governors explained
What is a governor?
A governor is a driver for the regulation of CPUFreq - CPU frequency. As the name suggests, we, the Governor of the decision, when at full capacity, the MaxFreq - will be achieved or how fast the minFreq - - maximum frequency is reached minimum frequency or center frequency. He decides when, how and how long the CPU and still responds battery saving is still soft and still works.
There are many types of governors. Some are for single-core processors and some designed for dual-core processors. In stock kernel, there are five governors and quasar kernel, there are a lot more.
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
26. Ktoonservative
27. AssWax
28. Sleepy
29. Hyper
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.
26, Ktonnservative
Ondemand scales to the highest frequency as soon as a load occurs. Conservative scales upward based on the frequency step variable which means for the most part will scale through every frequency to achieve the target load thresholds. What this practically means is ondemand is prone to wasting power on unneeded clock cycles. Ondemand also features something called a down differential, this variable determines how long the governor will remain at the given frequency before scaling down. Conservative does not have this, but instead relies on having a down threshold which insures that as soon as the load drops below a given variable it scales down as fast as the sampling rate allows. The result to this is a governor which attempts to keep the load level tolerable and save you battery! Now ! Ktoonservative Is that but in addition contains a hotpluging variable which determines when the second core comes online. The governor shuts the core off when it returns to the second lowest frequency thus giving us a handle on the second performance factor in our CPUs behavior. While by default conservative is a poor performer it can be made to perform comparably to even performance governor. Here are some settings to discuss and start with. They are slightly less battery friendly under a load but very very well performing.
27. AssWax
So far, all I have found about this Governor is that it belongs in the interactive family. I'll update this when I find more
28. Sleepy
The Sleepy (formerly known as Solo) is an attempt to strike a balance between performance and battery power to create. It is based on the getweakten Ondemand of Arighi and is optimized for the SGS2. It may include imoseyon's Ondemandx with some tweaks Down_sampling and other features that set by the user through the sysfs of "echo" call. Sleepy is the behavior of Ondemandx when he is in action, very similar.
29. Hyper
The Hyper (formerly known as kenobi) is an aggressive smart and smooth, optimized for SGS2 getweakt and, based on the Ondemand, which was getweakt of Arighi and was equipped with several features of Ondemandx suspend imoseyon. (Added by sysfs, the settings suspend_freq and suspend Imoseyon's code) is the behavior of the hyper Ondemand if he is in action, very similar. He also has the Arighi's fast_start deep_sleep and detection features. In addition, the maximum frequency is in suspend mode 500Mhz.
Credits goes to:
http://icrontic.com/discussion/95140...m-tuner-tegrak
http://forum.xda-developers.com/show....php?t=1369817
What is a scheduler?
In a multitasking operating system, there must be an instance, the processes that want to run, CPU time and allocates it "goes to sleep" after the allotted time (timeslice) again. This instance is called the scheduler, such as opening and closing applications. that is, how fast they are open and how long they are kept in RAM.
I / O scheduler can have many purposes like:
To minimize time searching on the hard disk
Set priorities for specific process requests
To regulate a particular portion of the bandwidth of the data carrier to each running process
To guarantee certain process requests within a certain time
Which scheduler are available?
CFQ
Deadline
VR
Simple
Noop
Anticipatory
BFQ
Sio
Anticipatory:
Two important things here are indicative of that event:
- Looking on the flash drive is very slow from Equip
- Write operations while at any time are processed, however, be read operations preferred, ie, this scheduler returns the read operations a higher priority than the write operations.
Benefits:
- Requests of read accesses are never treated secondarily, that has equally good reading performance on flash drives like the noop
Disadvantages:
- Requests from process operations are not always available
- Reduced write performance on high-performance hard drives
CFQ:
The CFQ - Completely Fair Queuing - similar to the Dead Line maintains a scalable continuous Prozess-I/O-Warteschlange, ie the available I / O bandwidth tried fairly and evenly to all I / O requests to distribute. He created a statistics between blocks and processes. With these statistics it can "guess" when the next block is requested by what process, ie each process queue contains requests of synchronous processes, which in turn is dependent upon the priority of the original process. There is a V2 and the CFQ has some fixes, such as were the I / O request, hunger, and some small search backward integrated to improve the responsiveness.
Benefits:
- Has the goal of a balanced I / O performance to deliver
- The easiest way to set
- Excellent on multiprocessor systems
- Best performance of the database after the deadline
Disadvantages:
- Some reported user that the media scanning would take this very very long time and this by the very fair and even distribution of bandwidth on the I / O operations during the boot process is conditioned with the media scanning is not necessarily the highest should have priority
- Jitter (worst case delay) can sometimes be very high because the number of competing with each other process tasks
Deadline:
This scheduler has the goal of reducing I / O wait time of a process of inquiry. This is done using the block numbers of the data on the drive. This also blocks an outlying block numbers are processed, each request receives a maximum delivery time. This is in addition to the Governor BFQ very popular and in many well known kernels, such as the Nexus S Netarchy. He was indeed better than the BFQ, but compared to the VR he will be weaker.
Benefits:
- Is nearly a real-time scheduler.
- Characterized by reducing the waiting time of each process from - best scheduler for database access and queries.
- Bandwidth requirements of a process, eg what percentage does a CPU is easy to calculate.
- As the Governor-noop ideal for flash drives
Disadvantages:
- If the system is overloaded, can go a lost set of processes, and is not as easy to predict
SIO:
It aims to achieve with minimal effort at a low latency I / O requests. Not a priority to put in queue, instead simply merge the requests. This scheduler is a mix between the noop and deadline. With him there is no conversion or sorting of requests.
Benefits:
- It is simple and stable. - Minimized Starvations (starvation) for inquiries
Disadvantages:
- Slow random write speeds on flash drives as opposed to other schedulers. - Sequential read speeds on flash drives, not as good
Noop:
The noop scheduler is the simplest of them. He is best suited for storage devices that are not subject to mechanical movements, such as our flash drives in our SGSII's to use to access the data. The advantage is that flash drives do not require rearrangement of the I / O requests, unlike normal hard drives. ie the data that come first are written first. He's basically not a real scheduler, as it leaves the scheduling of the hardware.
Benefits:
- Adds all incoming I / O requests in a first-come-who-first-served queue and implements requests with the fewest number of CPU cycles, so also battery friendly
- Is suitable for flash drives because there is no search errors
- Good data throughput on db systems
Disadvantages:
- Reducing the number of CPU cycles corresponds to a simultaneous decline in performance einhergehendem
VR:
Unlike other scheduling software, synchronous and asynchronous requests are not handled separately, but it will impose a fair and balanced within this deadline requests, that the next request to be served is a function of distance from the last request. The VR is a very good scheduler with elements of the deadline scheduler. He will probably be the best for MTD Android devices. He is the one who can make the most of the benchmark points, but he is also an unstable schedulers, because his performance falter. Sometimes they fluctuate below the average, sometimes it fluctuates above the average, but if above, then he is the best.
Benefits:
- Is the best scheduler for benchmarks
Disadvantages:
- Performance variability can lead to different results
- Very often unstable or unzverlässig
Simple:
As the name suggests, it is more of a simple or simple scheduler. Especially suitable for EMMC devices. He is reliable, maybe not as good as the VR, when this time has a good day, but he is despite all this very performance-based and does his best. At the moment it is the default scheduler in quasar kernel.
Advantages: - not known
Cons: - not known
BFQ:
Instead requests divided into time segments as the CFQ has, on the BFQ budget. The flash drive will be granted an active process until it has exhausted its budget (number of sectors on the flash drive). The awards BFQ high budget does not read tasks.
Benefits:
- Has a very good USB data transfer rate.
- Be the best scheduler for playback of HD video recording and video streaming (due to less jitter than CFQ Scheduler, and others)
- Regarded as a very precise working Scheduler
- Delivers 30% more throughput than CFQ
Disadvantages:
- Not the best scheduler for benchmarks - higher budgets that were allocated to a process that can affect the interactivity and bring with it increased latency.
How can I change the governor and scheduler?
There are two ways to change the governor and schedulers, as well as the settings for the Governorn. Either manually, in which you use a file manager like Root Explorer and then knows how to / sys / devices / system and then change the files to his wishes, provided you what you're doing, or via a graphical interface or by phone as SetCPU Voltage Control. These are the most prominent apps when it comes to adjusting the governor and / or scheduler.
- SetCPU are, besides the possibility of the clock speed of the CPU, setting profiles in certain situations, only to change the way the governor. The scheduler can not change it.
- Voltage control can alter both the governor and the scheduler, but has no way to adjust behavior profiles. While you can set various overclocking, Governor and scheduler profiles manually, but nothing more. Nevertheless, I prefer the VC, since it is simple and gives me the opportunity to change the scheduler.
Credit goes to Tinzdroid

Good find. I found that a few months ago when i had a few governor questions.

That's a lot of governors. Too many honestly. How's it go? "Too much of a good thing is bad" I'd say 29 +1 (pegasusq isn't listed) is just overkill given that a few are just custom rehashes of others that can be done via apps or scripts but I do understand the point. Seems we're getting to a point where we'll need to narrow it down to the gems though. For multi-core phones that list is small unless you do some editing and/or scripts as only a few (hotplug and pegasusq mostly, abyssplug too I think) are naturally multi-core aware. The rest will only use core0.
Good find though. Normally you only find ones with about 1/2 of them listed.
Sent from my SPH-D710 using xda app-developers app

How about a governor named "fantasy"? Have this on my tablet set as default one by manufacturer.

Aessaya said:
How about a governor named "fantasy"? Have this on my tablet set as default one by manufacturer.
Click to expand...
Click to collapse
Did a simple google search, found the following info at http://tabletrepublic.com/forum/novo-7-elf/cpu-running-1008mhz-696.html
Antutu cpu works better for me. and so far, i set my cpu speed at 912 max 60 min, fantasy governor. Because this tablet has high resolution and require cpu power, it is better not to set the cpu max speed too low.
And
http://www.slatedroid.com/topic/30592-apps-for-cpu-speed-mod-recommendation/
'fantasy' - This driver adds a dynamic cpu freq policy governor.
The governor does a periodic polling and changes frequency based on the CPU utilization.
The support for this governor depends on CPU capability to do fast frequency switching (i.e, very low latency frequency transitions).

lulzactiveq is my personal choice, but you need to tweak the values.

Thank you for the post!

Thank you for the write up, I've seen all of them, but didn't know until now how the user created ones worked over presets. This should be stickied for every device, applies to every android device I have.

[REF] [GUIDE][How to][TUTORIAL] - KT747 - KTweaker New User Guide & Settings

INTRODUCTION -
This guide is intended to help those who are coming to the Kernel KT747 by @ktoonsez. This thread and the subsequent Posts are intended to be as a Guide for users that are new to this Kernel and its Tweaker. Complete credit for the development of the Kernel goes to @ktoonsez. You can find his Kernel thread bellow.
KT747 - SGH-T999 Touchwiz & AOSP - Thread by Ktoonsez
Older Builds of the Kernel - Thread by @LuigiBull23
{
"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"
}
​INTRODUCTION -
There are quiet a few times when users have asked for the choice, usage as well as definition of various parameters of the Governers and Schedulers. Hence I decided to write this guide as a way to help the users understand the various basic terms and parameters. I am perfectly aware that there are quiet a few excellent guides on the different ICS & JB Governers. As a matter of fact, I have linked to some of them. So eventhough I have given basic information on Governers in this kernel, it is not my primary purpose to serve this as the ultimate guide on that subject.
This is a living guide and given vastness of the subject, I will continue to modify the OP as well as subsequent posts.
Disclaimer:
I am not responsible if you end up with expensive brick. Read the guide as much as you want and ask questions before proceeding with overclocking.
Overclocking and undervolting is highly debatable, some say its good and some say its bad... so its upto you to proceed further. While on the word of Caution – I have personally managed to Smoke (I mean literally physically cause smoke) from a Tablet by testing SetCPU Overclocking on it.
Here’s another nice detail on why Friends don't let Friends do extreme Overclock or Undervolt! post by @dorimanx, the developer of the other excellent kernel.
PURPOSE / INTENT -
The intent of this thread is to help new users learn, and act as reference for more knowledgeable users, on the Governers & Schedulers incorporated into this Kernel. Another Purpose is to help those who are new to Overclocking & undervolting in general.
There are quite a few good guides on this forum regarding Overclocking. So Rather than writing one myself, I am going to refer to one by @bala_gamer, who has written a pretty comprehensive guide for the International version of Galaxy SIII. Even though the hardware is different between that phone and this one, the guide is good enough for those who are starting down this path and want to get basic understanding.
Another intentional purpose of this thread is to provide a platform to discuss Overclocking and undervolting settings for SGH-T999 specific version. Given that I wish offer to the experts a platform to discuss, in interest of New users and their phone, I have been careful enough to include warnings and footnotes where possible.
WHAT DO I GET BY OVERCLOCKING/UNDERVOLTING -
In short, modern Microprocessors, to a certain degree have a range of Operational frequency steps. Also especially for multiprocessor devices, it is possible to control when a processor comes into play and when it does not. Now, the main question that comes to mind is, why would you want to turn off processors? Well, consider this. It’s Kind of an analogy like a car engine. On a 6 Cylinder engine, the fuel consumption is a lot more. But if you were to turn off 2 out of the 6 cylinders, then there is still power to drive and fuel consumption is lower. Similarly, with one of the processor turned off, battery drain is reduced not to mention heat generation.
For a given processor, by design the higher the frequency it operates, the more raw power you have available to run applications. Typically on some of the previous generation single processor phones, its not possible to run Angry Birds or other games unless you run the processor consistently at its maximum operating frequency. So users may choose to Overclock the phone in order to run such Apps.
On the flip side, if you are a light user, then it will benefit if you turned off the other processor(s). This saves the battery. Given there are multitudes of Frequency steps, if the processor operates at lower frequency, there is less heat generated and less battery used. Before I proceed further, I am respectfully Quoting Castle_Bravo from here. He has summarized perfectly what I’d have said otherwise.
castle_bravo said:
In the pc world we have things like clock speeds, latency, read speed, bus speeds and things of this nature. Right now im going to talk about over clocking a processor, whether it's a gpu I or a cpu. When we over clock these devices, meaning make them go faster than originally rated by the manufacturer using software of any kind, these devices will also work harder. The faster the clock speed the hotter the component gets and the shorter it's life span is due to thermal stresses. Hence our manufacturer rating of speeds.
There are two ways to combat heat; heat is the main enemy in any high powered system (do a YouTube search of running a cpu with no heart sink). Add more cooling via more hardware and lower voltages applied to the component. Adding more cooling hardware is the preferred method. This is the best way because now that the component is working faster at the same temperatures it was at before on stock clock speeds it is, in terms of math, working LESS. This applies to ram, video card, cpu's and the like.
Typically, as you raise clock speeds you also have to RAISE voltages in order to keep it stable. There are exceptions like in a VERY minor over clock you can actually lower voltages. The trade off here is that with the larger cooling equipment and the faster clock speeds the processor will spend less time at peak load and return to idle faster. If set up correctly you can actually draw less cumulative power using higher voltages. This is assuming temperatures are the same for both scenarios of stock clock and over clock. BUT, more power applied equals more heat. Now, as we raise clock speeds and raise our voltage, we try to be on the edge of not enough. Because what does more power mean? More heat. And what does more heat mean? Less component life. Not only that but the components have a "healthy" voltage band due to tolerances in its manufacture so we don't want to exceed that.
We undervolt mainly to protect the equipment. Secondary is battery savings. We do not have the option of installing more hardware to cool our devices so all we can do is lower voltages. Lowering voltages will help keep the component cool because it is pulling less electrons. More power = more heat. the cpu will become unstable and make it work harder, which is counter productive and will have a reverse effect. So take that voltage too far down and now the component doesn't have enough power to perform its job properly or efficiently, making it work HARDER. What happens when a component works harder? It heats up. So we can actually have a reverse effect from our intended power savings.
Click to expand...
Click to collapse
Last But Not Least, here’s a nice Q&A by XDA User @droidphile for further reading. Although it is written for the Galaxy S2, quite a few parts do apply as this device too has dual core. Since that’s another SoC, apply the settings with caution if you at all wish to apply from that post.

Implementation of Overclocking & Undervolting by using KTweaker -
Given that Ktoonsez has an excellent app for this kernel; my intention is to provide a way for you to make the best usage of the same.
​ By default, when the kernel is freshly installed and you open the app for the first time, there should not be any error messages of any kind. The App settings are not permanent. So every time you re-boot the phone, you are restored to original Defaults. This is a great way to test out various settings to see if they work out or turn the phone into slowpoke.
As you can see in the screen shot, there are 7 major options.
GENERAL – This is the main setting area. This is where you control the phone’s operation and other settings around how it behaves. We will go into great details later on.
VOLTAGES – This allows you to control the CPU operating voltage at a given Frequency step. It plays a significant role when you are undervolting or Overclocking.
EXTRAS – Unlike the name, this section contains quite a few important settings that modify the phone’s behavior. Specifically how the phone reacts when the screen is turned off or when you are Navigating or charging the phone.
SET OPTIONS ON BOOT – As the name suggests, you get to choose if the settings you have changed are applied after you restart or not. Also if you choose to, you can also specify a time duration after Restart before your settings get applied.
BACKUP PREFS TO SDCARD – This simply allows you to make a backup of your settings to the internal SD Card. The path is /SDCARD/KTWEAKER/. You can also name the settings optionally.
RESTORE PREFS FROM SDCARD – As the name suggests, you can re-load your backed up settings. Comes in handy if you have one set of settings that really work and you want to experiment further.
LOAD DEFAULTS – This option simply sets all the settings to the value KTOONSEZ has set up in the kernel as initial values.

GENERAL SECTION -
​ This is perhaps the main section of the Kernel Controls. In this section you can choose wide variety of options that directly determine the performance of the phone as well as Battery life as a result.
There are several sub-menus as follows. As you can see in the screen-shot, there is a small comment on what the section does.
1. ENABLE OC STEPS
2. LOCK FREQUENCIES – There’s a little sub-section to choose minimum and maximum operating frequencies.
3. I/O SCHEDULERS
4. I/O SCHEDULER ADJUSTMENTS
5. CPU GOVERNORS
6. CPU GOVERNOR ADJUSTMENTS
7. AUTO HOTPLUG
1. ENABLE OC STEPS -
This is a simple Check box to enable Overclocking. Select this only if you are going to overclock. By doing so, you get higher range of frequencies to choose for the Minimum and Maximum frequencies. Do note, just because it lets you specify higher frequencies, does not mean you can set to the highest value. Permanently operating at Overclocked frequency may cause physical damage to your phone. Remember Qualcomm has set 1500 MHZ as the normal operating frequency for this CPU.
2. LOCK FREQUENCIES -
This is again a Check box that effectively pegs the operating frequencies to within the Range as specified by the Minimum Frequency and Maximum Frequency sliders.
The two sliders that are part of this section need to be set after very careful consideration. If you set the minimum frequency too low, then you run the risk of a sluggish and unresponsive phone when there are no apps running. For the maximum frequency, remember higher the frequency, more heat will be produced. Also the battery will drain faster. So give it some thought before setting the limits. Choose the values based on whether you are looking to save battery or get high performance and responsiveness.
Note – A side note on this, the CPU is actually located in the back, bellow the battery compartment. So you will notice the heat in that section. If you happen to have a bumper case on the phone, you won't notice actual temperature unless the phone is really hot.
7. AUTO HOTPLUG
This is a simple Checkbox that enables Hot-Plugging support. Hotpluging is a concept borrowed from Server Linux and is applicable to Android in the same manner. In short, it allows for CPUs being removed from Service or added to service on the fly, without needing OS level Restart. Effectively this, gives the kernel a choice to Take CPU Cores offline or bring them online. Some of the Governors we discussed above already support hotplugging. This checkbox ensures support for the remaining Governors.

3. I/O SCHEDULER –
Scheduler Guide Link
This menu offers a choice of all the android Schedulers available in this kernel.​
Given that there are so many excellent guides on the individual Schedulers, I do not wish to provide the same information again. (Besides this is indeed a vast topic by itself.) So without going to specific details, I am going to summarize what it means from a layman's point of view. For those with more technical inclination, I have provided a link to read further on each scheduler.
Think of an I/O Scheduler like an executive assistant to the Disc or storage of the phone. Just like the assistants, it effectively manages the disc reads or writing to it for all the processes. In particular, it determines what process gets prioritized and/or bandwidth. You have to understand; that each app you run has its own process as well as child processes it triggers. In addition, the OS too has its own processes that monitor various aspects of the phone. Effectively these are all the processes competing for the reading or writing. Based on that knowledge, you can choose whatever works best for your usage pattern. Later on I will be providing some sample settings to get you started.
Noop:
The noop scheduler is the simplest of them. It is best suited for Cell phone storage since it is flash media. As the flash drives do not require rearrangement of the I/O requests, the data that come first is written first (First in First Out). It's basically not a real scheduler, as it leaves out the scheduling of the hardware.
Benefits:
- Adds all incoming I / O requests in a first-come-who-first-served queue and implements requests with the fewest number of CPU cycles, so also battery friendly
- Is suitable for flash drives because there is no search errors
- Good data throughput on db systems
- Is nearly a real-time scheduler.
- Characterized by reducing the waiting time of each process from - best scheduler for database access and queries.
- Bandwidth requirements of a process, eg what percentage CPU is used is easy to calculate.
Disadvantages:
- If the system is overloaded, it may lose a set of processes, and is not as easy to predict
- Reducing the number of CPU cycles corresponds to a simultaneous decline in performance.
Deadline:
This scheduler has the goal of reducing I/O wait time of a process. This is done using the block numbers of the data on the drive. This also controls how outlying block numbers are processed, each request receives a maximum delivery time. This is in very popular like BFQ and Deadline:
Benefits:
- Is nearly a real-time scheduler.
- Characterized by reducing the waiting time of each process from - best scheduler for database access and queries.
- Bandwidth requirements of a process, eg what percentage does a CPU is easy to calculate.
- noop is ideal for flash drives
Disadvantages:
- If the system is overloaded, can go a lost set of processes, and is not as easy to predict. It is indeed better than the BFQ, but VR is even better.
ROW:
Reference - http://lwn.net/Articles/509829/
Read Over Write Scheduler. This scheduler ignores or backpedals the disc write operations, giving higher priority to the Read Operations.
Mobile devices prefer user experience; hence, the READ IO requests get as much priority as possible. The main idea is, if there are READ requests in pipe - dispatch them but don't delay the WRITE requests too much.
All the incoming requests are kept in multiple queues according to their priority. The dispatching of requests is done in a Merry-Go-Round fashion with a different slice of time for each queue.
Presently there are 6 types of queues the requests are parked in
[FONT=&quot]- [/FONT]High priority READ queue
[FONT=&quot]- [/FONT]High priority Synchronous WRITE queue
[FONT=&quot]- [/FONT]Regular priority READ queue
[FONT=&quot]- [/FONT]Regular priority Synchronous WRITE queue
[FONT=&quot]- [/FONT]Regular priority WRITE queue
[FONT=&quot]- [/FONT]Low priority READ queue
If in a certain dispatch cycle one of the queues was empty and didn't use its time, that queue will be marked as "un-served". For Ex. While in the middle of executing requests of Queue Y, a request comes to queue X (X having more priority over Y), and was un-served in the previous cycle. Then queue X will be preempted over queue Y. This won't restart the cycle. Once queue Y is done with its request, scheduler will go back to X, and allow it to finish it's request, before proceeding with resto fo the queues in the cycle.
For READ request queues idling is allowed to give the application(s) a chance to add more requests. The idling is enabled if the application is making requests in rapid succession.
ROW scheduler will support special services for memory cards that
support High Priority Requests. In addition it will support rescheduling of interrupted requests. For example, while working on a long write request, a sudden high priority read request comes in, the scheduler will inform the device and the device can stop the write request to serve the high priority read request. In such a case the device may send back the interrupted write request so that the scheduler will send it later according to the scheduler policy.
CFQ:
CFQ (Completely Fair Queuing) is similar to the Deadline. It maintains a scalable continuous Process-I/O The available I/ O bandwidth is used fairly and evenly to all I/O requests to distribute. It creates a statistics of blocks and processes. This is then used to guess when the next block is requested by what process, ie each process queue contains requests of synchronous processes, which in turn is dependent upon the priority of the original process. There is a second version with some fixes, such as allowing the request to starve, and some small search backward integrated to improve the responsiveness.
Benefits:
- It has the goal of a balanced I/O performance to deliver
- The easiest way one set
- Excellent on multiprocessor systems
- Best performance of the database after the deadline
Disadvantages:
- Some reported user that the media scanning would take very long time
- The fair and even distribution of bandwidth can cause delays in the boot process.
- Jitter (worst case delay) can be caused sometimes because of the number of competing with each other process tasks
BFQ:
Requests divided into time segments as the CFQ, but on a budget. The flash drive will be granted an active process until it has exhausted its budget (number of sectors on the flash drive).
Benefits:
- Has a very good USB data transfer rate.
- Be the best scheduler for playback of HD video recording and video streaming (due to less jitter than CFQ Scheduler, and others)
- Regarded as a very precise working Scheduler
- Delivers 30% more throughput than CFQ
FIOPS:
Fair, Efficient Flash I/O Scheduler is geared for the modern Flash based storage media well. I haven’t been able to find a lot of documentation for this. Will keep looking.
SIO:
It aims to achieve with minimal effort at a low latency I / O requests. Not a priority to put in queue, instead simply merge the requests. This scheduler is a mix between the noop and deadline. There is no conversion or sorting of requests.
Benefits:
- It is simple and stable. - Minimized Starvation for inquiries
Disadvantages:
- Slow random write speeds on flash drives as opposed to other schedulers. - Sequential read speeds on flash drives, not as good
V(R):
Unlike other scheduling software, synchronous and asynchronous requests are not handled separately, but it will impose a fair and balanced within this deadline requests, that the next request to be served is a function of distance from the last request. It is a very good scheduler with elements of the deadline scheduler. He will probably be the best for MTD Android devices. It also makes the most out of the benchmark points, but is also unstable scheduler, because its performance can fluctuates below or above average.
Benefits:
- Is the best scheduler for benchmarks
Disadvantages:
- Performance variability can lead to different results
- Very often unstable
ZEN:
This Scheduler is actually based on a combination of NOOP, SIO & VR Schedulers. This scheduler combines Synchronous & Asynchronous requests with same priority. It uses a deadline in order to derive or determine priority of a process.
FIFO:
First in First Out Scheduler. As the name says, it implements a simple priority method based on processing the requests as they come in.

4. I/O SCHEDULER ADJUSTMENTS
Ref -
https://www.kernel.org/doc/Documentation/block/
http://www.linux-mag.com/id/7572/
http://algo.ing.unimo.it/people/paolo/disk_sched/description.php
The Scheduler Adjustments are parameters that determine how the selected Scheduler behaves. Needless to say the list of parameters in this menu will change depending on which Scheduler you chose in the previous step. The screenshot depicts parameters for the ROW Scheduler. Even though there are quite a few Schedulers available in this kernel, parameters of some of them tend to be similar in effect. Hence I have combined the Schedulers whose parameters are similar.
​[FONT=&quot] Deadline, SIO and Zen: [/FONT][FONT=&quot]
fifo_batch: This parameter controls the maximum number of requests per batch.[/FONT][FONT=&quot]It tunes the balance between per-request latency and aggregate throughput. When low latency is the primary concern, smaller is better (where a value of 1 yields first-come first-served behavior). Increasing fifo_batch generally improves throughput, at the cost of latency variation. [/FONT]The default is 16.[FONT=&quot]
front_merges: A request that enters the scheduler is possibly contiguous to a request that is already on the queue. Either it fits in the back of that request, or it fits at the front. Hence it’s called either a back merge candidate or a front merge candidate. Typically back merges are much more common than front merges. You can set this tunable to 0 if you know your workload will never generate front merges. Otherwise leave it at its default value 1.
[/FONT][FONT=&quot]read_expire: In all 3 schedulers, there is some form of deadline to service each Read Request. The focus is read latencies. When a read request first enters the io scheduler, it is assigned a deadline that is the current time + the read_expire value in units of milliseconds. The default value is 500 ms.
write_expire: Similar to Read_Expire, this applies only to the Write Requests. The default value is 5000 ms.[/FONT][FONT=&quot]
writes_starved: Typically more attention is given to the Read requests over write requests. But this can’t go on forever. So after the expiry of this value, some of the pending write requests get the same priority as the Reads. Default value is 1.
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.
CFQ
back_seek_max: The scheduler tries to guess that the next request for access requires going backwards from current position on the Disc. Given that such going back can be time consuming. So in anticipation, may move back on the disc prior to the next request. This setting, given in Kb, determines the max distance to go back. Default value is set to 16 Kb.
Do note that in a cellphone or tablet, the storage is actually Flash Memory technology. There is Disk head to be re-positioned. As such this is not that effective as backward reads are not that bad.
[/FONT][FONT=&quot]back_seek_penalty: This parameter is used to compute the cost of backward seeking. If the backward distance of a request is just 1 from a front request, then the seeking cost of the two requests is considered equivalent and the scheduler will not bias toward one or the other. This parameter defaults to 2 so if the distance is only 1/2 of the forward distance, CFQ will consider the backward request to be close enough to the current head location to be “close”. Therefore it will consider it as a forward request.
fifo_expire_async & fifo_expire_sync : This particular parameter is used to set the timeout of asynchronous requests. CFQ maintains a fifo (first-in, first-out) list to manage timeout requests. The default value is 250 ms. A smaller value means the timeout is considered much more quickly than a larger value. Similarly, fifo_expire_sync applies to the Synchronous requests. The default is 125 ms.
[/FONT][FONT=&quot]group_idle: If this is set, CFQ will idle before executing the last process issuing I/O in a cgroup. This should be set to 1 along with using proportional weight I/O cgroups and setting slice_idle to 0 as Flash memory is a fast storage mechanism.
group_isolation: If set (to 1), there is a stronger isolation between groups at the expense of throughput. If disabled, Scheduler is biased towards sequential requests. When enabled group isolation provides balance for both sequential and random workloads. The default value is 0 (disabled). [/FONT][FONT=&quot]
low_latency: When set (to 1), CFQ attempts to build a backlog of write requests. It will give a maximum wait time of 300 ms for each process issuing I/O on a device. This offers fairness over throughput. When disabled (set to 0), it will ignore target latency, allowing each process in the system to get a full time slice. This is enabled by default.
[/FONT][FONT=&quot]Quantum: This option controls the maximum number of requests being processed at a time. The default value is 8. Increasing the value can improve performance; the latency of some I/O may be increased due to more requests being buffered inside the storage.
[/FONT][FONT=&quot]slice_async: This parameter controls Maximum number of asynchronous requests at a time. The default value is set to 40 ms.[/FONT][FONT=&quot]
slice_idle: When a task has no more requests to submit in its time slice, the scheduler waits for a while before scheduling the next thread to improve locality. The default value is 0 indicating no idling. However, a zero value increases the overall number of seeks. Hence a Non-zero number may be beneficial.
slice_sync: This setting determines the time slice allotted to a process I/O. The default is 100 ms.
BFQ
timeout_sync & timeout_async: These parameters determine maximum disk time given to a task, respectively for synchronous and asynchronous queues. It allows the user to control the latencies imposed by the scheduler.
[/FONT][FONT=&quot]max_budget: This determines, how much of the queue request is serviced based on number of sectors on disc. A larger value increases the throughput for the single tasks and for the system, in proportion to the percentage of sequential requests issued. Consequence is increasing the maximum latency a request may incur in. The default value is 0, which enables auto-tuning
[/FONT][FONT=&quot]max_budget_async_rq: This setting determines number of async queues served for a maximum number of requests, before selecting a new queue.[/FONT][FONT=&quot]
low_latency: When this is set to 1 (default is 1), interactive and soft real-time applications experience a lower latency.
Row:
[/FONT][FONT=&quot]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: Determines length of idle on read queue in Msec (in case idling is enabled on that queue).
read_idle_freq: Determines the frequency of inserting READ requests that will trigger idling. This is the time in Msec between inserting two READ requests[/FONT]

5. CPU GOVERNORS –
THIS SECTION IS STILL IN PROGRESS. I WILL KEEP UPDATING.KINDLY BEAR WITH ME.
References -
http://androidforums.com/xperia-mini-all-things-root/513426-android-cpu-governors-explained.html
http://forum.xda-developers.com/showpost.php?p=28647926&postcount=1
http://pic.dhe.ibm.com/infocenter/l...ic=/liaai.cpufreq/TheConservativeGovernor.htm
http://lists.linaro.org/pipermail/linaro-kernel/2012-February/001120.html
A Governor performs a similar function for the CPU time management as the Scheduler. Originally, there were a set of Governors coming from the Linux kernel. Over the period, newer governors were introduced for Android architecture. Several developers added their own governors by modifying or tweaking existing governors.
​ To fully utilize the governors, you need to disable a file called mpdecision. It's located under /system/bin. It interferes with the governors operation and won't allow you to take full advantage of it's settings. Typically you can do this by renaming the file name using ES File Explorer and rebooting the phone. ​ Note that if you use the Touchwiz JELLYBEAN version, you should rename /system/bin/qosmgr to /system/bin/qosmgr.bak .
Essentially with either file, governor’s instructions for the second CPU are overridden. By renaming them, they are not loaded at Boot. So governor’s authority is restored.
ONDEMAND -
Reference - http://pic.dhe.ibm.com/infocenter/l...ic=/liaai.cpufreq/TheConservativeGovernor.htm
The ondemand governor dynamically changes CPU frequency in response to CPU utilization. It will automatically select the highest available processor frequency when the processor load rises above value set by up_threshold. If CPU utilization rises above the up_threshold parameter, the ondemand governor increases the CPU frequency to scaling_max_freq. When CPU utilization falls below this threshold, the governor decreases the frequency in steps to run at the next lowest frequency until it reaches scaling_min_freq. After each sampling_rate milliseconds, the current CPU utilization is reexamined and the process is repeated dynamically to adjust the CPU frequency per process load. Since the governor needs time to respond, performance might be reduced if the usage changes frequently.
CONSERVATIVE –
Reference- http://pic.dhe.ibm.com/infocenter/lnxinfo/v3r0m0/topic/liaai.cpufreq/TheConservativeGovernor.htm
This governer prefers the lowest possible clock speed as often as possible. Only upon a larger persistent load on the CPU will the conservative governor raise the CPU clockspeed.
This will tend to try and keep the CPU running at lower speeds and consequently lower voltage. This inherently will conserve the battery.
Like the Ondemand governor, it steps the CPU through the operating frequencies by dynamically adjusting frequencies based on processor utilization. However, the conservative governor increases and decreases CPU speed more gradually as against the hair trigger response of OnDemand governer. This governor increases the frequency step by step upon CPU load but jumps to lowest frequency when the CPU load is removed. Thus it aims to dynamically adjust the CPU frequency to current utilization, without jumping to max frequency. If CPU utilization is above up_threshold, this governor will step up the frequency to the next highest frequency below or equal to scaling_max_freq. If CPU utilization is below down_threshold, this governor will step down the frequency to the next lowest frequency until it reaches scaling_min_freq. After each sampling_rate milliseconds, the current CPU utilization will be reexamined and the same algorithm will be applied to dynamically adjust the CPU frequency to current utilization.
Note - Depending on how the developer has implemented this governor, and the minimum clockspeed chosen by the user, you may experience some choppiness or random freeze. So you need to choose its settings more judiciously.
KTOONSERVATIVE –
As I said earlier, Ktoonservative is a Hotplug derivative of the traditional Conservative Governor. Hot plugging allows the governor to turn off second core of the processor dynamically. This maintains a healthy balance of Performance and Battery life.
I wish to respectfully quote @freecharlesmanson.
Ondemand scales to the highest frequency as soon as a load occurs. Conservative scales upward based on the frequency step variable which means for the most part will scale through every frequency to achieve the target load thresholds. What this practically means is ondemand is prone to wasting power on unneeded clock cycles. Ondemand also features something called a down differential, this variable determines how long the governor will remain at the given frequency before scaling down. Conservative does not have this, but instead relies on having a down threshold which insures that as soon as the load drops below a given variable it scales down as fast as the sampling rate allows. The result to this is a governor which attempts to keep the load level tolerable and save you battery! Now ! Ktoonservative Is that but in addition contains a hotpluging variable which determines when the second core comes online. The governor shuts the core off when it drops below the hotplug down threshold thus giving us a handle on the second performance factor in our CPUs behavior. While by default conservative is a poor performer it can be made to perform comparably to even performance governor. Here are some settings to discuss and start with. They are slightly less battery friendly under a load but very very well performing.
Click to expand...
Click to collapse
SMARTASSH3 –
This is a balanced governor that tries to balance between Performance and Battery life. This governor is based on the SmartassV2 Governor. Since it was tweaked by H3ROS, the name is modified. The V2 in turn is a derivative of the original SmartAss governor. It tries to attain an Ideal frequency by ramping up to that frequency quickly. Once reached, further ramping is done very slowly. This Ideal value is user defined in the Governor settings.
The governor also has different frequencies for Screen ON and Screen OFF states along with Sleep state.
NIGHTMARE -
This is one of the newer Performance oriented governor. It tries to reach the top frequency by scaling rapidly. Once reached, it tries to maintain the frequency as much as possible. It is based on the PegasusQ governor.
It is multi-core version of the Ondemand governor with integrated hot-plugging. Ongoing processes in the queue can run simultaneously . These processes are in a “Run Queue" queue that is ongoing. The processes are arranged according to their priority values. To ensure that each process has its fair share of resources, each is run for a certain period and then stops and placed in the queue for next turn. This continues until the processes are terminated.
DANCEDANCE –
This governor is based on the Conservative Governor. It was created by Snuzzo by modifying Ramp up rate to be higher as well as Sleep routines.
WHEATLEY –
This one took some digging as Wheatley is not a Linux Governer brought to Android. XDA Developer @phone_user implented this governer for his Samsung Galaxy Nexus Kernel.
In essence, this governer takes on a novel approach to power saving. As you may deduced so far, making the CPU operate at lowest needed frequency (like conservative does), can potentially backfire with CPU taking more time (and more consumption over time) to finish the task. So Wheatley actually targets the CPU Frequencies and its Deep Sleep State (AKA C4 State). In this state, the CPU voltage is reduced to avoid unnecessary power consumption.
So respectfully quoting him for the details.
phone_user said:
The previous benchmarks of the usage of the C4 state for different activities have shown that for 'light' tasks like browsing the internet, reading (for example emails or eBooks) and the average app the device spends about 40% of the time in C4 with acceptable average residencies of around 11ms. For more demanding tasks like games and video playback the C4 state is still being used however the efficiency is reduced due to the low average residencies of below 5ms (considering that the wakeup latency is 1.3ms).
I have run a few tests and as it turns out, for demanding tasks the efficiency of the C4 state is significantly reduced due to these low residency times (= large number of wakeups) to a point that the good old frequency scaling is indeed more efficient with larger battery savings. So unfortunately, relying on the C4 state alone for power savings for all tasks is not a good option.
However, unfortunately we also cannot simply use one the available standard governors since always try the minimize the frequency without taking account that this behaviour diminishes the efficiency of the C4 state since it hinders a proper race-to-idle. So taking advantage of this knowledge what a good governor should do, is using the maximum frequency whenever the C4 state is properly used with acceptable average residencies and only scale down when the average residencies get too low (or the C4 is not used at all, of course).
Building on the classic 'ondemand' governor I implemented this idea in my new Wheatley governor. 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.
Click to expand...
Click to collapse
ABYSSPLUG –
This is a Modifed version of the Hot Plug Governer. It is similar to the On Demand governor, but is more accurate steps through CPU frequencies depending on CPU load. Like the Hotplug governor, it turns off unused CPU cores upon low CPU utilization.
BADASS –
ASSWAX –
SlP –
PEGASUSQ –
ADAPTIVE –
INTERACTIVE –
This governor is designed for latency-sensitive workloads, such as interactive user apps. The interactive governor aims to be significantly more responsive to ramp CPU quickly up when CPU-intensive activity begins.
Existing governors sample CPU load at a particular rate, typically every X ms. This can lead to lag from the time user begins interacting with a previously-idle system until the next sample period.
The Interactive governor, instead of sampling the CPU Load, it will check whether to scale up CPU frequency immediately after CPU becomes active. This is done with a timer, that triggers within 1-2 ticks. If the CPU is very busy after becoming active, then the governer assumes the CPU to be underpowered and will ramp to MAX speed. If the CPU was not sufficiently busy to immediately ramp to MAX speed.
After this, the governor evaluates CPU load, choosing the highest value between longer-term load or the short-term load since idle exit to determine the CPU speed to ramp to.
A realtime thread is used for scaling up, giving the remaining tasks the CPU performance benefit. This is unlike existing governors which are more likely to schedule other tasks to occur after your performance starved tasks have completed.
USERSPACE -
This governer allows for more granular control over Power policy for the device. It allows any user apps to set the processor frequency. It does not dynamically change the CPU frequency or react to processor load, rather it only provides a mechanism to set the frequency through the use of the scaling_speed parameter. However, KT747, does not implement any tunable parameters for the user.
POWERSAVE -
As the name says, the only priority for this governer is to provide power saving with no regard for apps being slowed down. This can be counter intuitive since slowed down apps will take even longer time and thus drain battery further.
It sets the CPU to the value of the scaling_min_freq parameter. (Default value is the lowest available processor frequency). However, KT747 does not offer this parameter as a tunable within the KTweaker application.
PERFORMANCE -
As the name says, this governor exclusively focuses on providing consistent minimum latency. This governor sets the CPU speed to the highest available frequency. The CPU speed is always set to the frequency defined in scaling_max_freq parameter. (Default is the highest available processor frequency). However KT747 does not expose this setting via the KTweaker application.

6. CPU GOVERNOR ADJUSTMENTS
Governor Adjustments are typically parameters for a given governor that you can further tweak. There are certain Performance Scripts out there that may set some of these parameters as well. One such example is System Performance Mod Thunderbolt! By @pikachu01​
Given below are some of the parameters of commonly used Governors. There are quite a lot of parameters for each governor. Having to list each one will be pretty intensive. I may choose to add these in future as time permits AND if there is a demand for it. In addition, I am adding Hide tags for each governor in order to tidy up the post.
ONDEMAND GOVERNER-
Ignore_nice_load - You can use the ignore_nice_load option to ignore all processes, that run with a positive nice value. These will not be counted toward the overall CPU utilization. Set this parameter to 1 if you do not care how long it takes for such processes to complete.
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.
The powersave_bias parameter modifies the behavior of the ondemand governor to save more power by reducing the target frequency by a specified percentage. By default, the it selects the minimum processor frequency that can still complete a workload with minimal idle time. Doing so should result in the highest performance to power efficiency ratio. In some cases, you might prefer a greater emphasis on power efficiency than performance. In this case, set the powersave_bias parameter to a value between 1 and 1000 to reduce the target frequency by one-thousandth of that value. Say if you set powersave_bias to 100 it will cause a one-tenth reduction in target frequency. If the Max frequency of the device is 2 GHz, the governor instead will request 1.8GHz – a one-tenth reduction. If 1.8 GHz is an exact match with an available hardware frequency (listed in the scaling_available_freq parameter), the processor is set to this frequency. If 1.8 GHz is not available, the processor fluctuates between the closest available upper and lower frequencies for an average frequency of 1.8 GHz. The default value is 0.
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 GOVERNER –
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.
KTOONSERVATIVE & CONSERVATIVE GOVERNER-
Boost_2nd_Core_On_Button -
This configuration option when set, allows you to turn the second Core ON with Back+Home+Menu button combo.
Boost_CPU - @KToonsez hasn't documented much on this setting. But based on my experiments, I feel that this, specifies the frequency to which the second Core is set when turned on by the button combo above.
Boost_GPU - Similar to Boost_CPU, this will set the frequency of operation of the GPU when the second core is turned on.
Boost_Hold_Cycles -
This setting specifies the duration for which the Core 2 will be kept on. A value of 22 translates as 1 second.
Boost_Turn_on_2nd_Core -
When set, this setting will make second core turn on immediately on touch.
CPU_Down_Block_Cycles -
This setting is used to counteract the effects of hot plugging. It specifies duration for which the CPU Cycles are throttled before hot plugging the second core out.
Disable_Hotplug_BT -
As the name suggests, when set. this setting will stop the second core from being turned off when Bluetooth connection is active.
Disable_Hotplugging -
When set the entire process of hot plugging is turned off.
freq_step - Defines how much (as a percentage of the maximum CPU speed) the conservative governor will increase the CPU speed by each time the CPU load reaches the Up Threshold.
sampling_down_factor & sampling_rate- 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 you set sampling_rate to 10,000 and sampling_down_factor to 2, the scheduler samples the CPU utilization every 20,000 microseconds.
freq_step - The freq_step parameter changes the size of the frequency step that the governor uses to change CPU frequency in either direction. By default this setting is 5, which means the governor will change the CPU frequency by five percent of the maximum or minimum frequency each time it changes frequencies. If you set this value to 100, the governor will behave exactly like the ondemand governor and immediately increase to the highest speed.
ignore_nice_load - You can set the ignore_nice_load option to ignore all processes that run with a positive nice value will not be counted toward the overall CPU utilization. Hence will not cause the CPU frequency to increase and might take longer to complete. When set to 0 (the default), all processes are counted toward the CPU utilization value. When set to 1, niced processes are ignored.
No_2nd_CPU_Screen_Off -
As the name says, setting this to 1 (default value), will turn off second core on your device. For those with more than 2 cores, there will be corresponding settings for 3rd and 4th core.
Sampling_Down_Factor - This parameter controls the rate at which the
kernel makes a decision on when to decrease the frequency while running
at top speed. When set to 1, decisions to re-evaluate the CPU load, are made at the same interval regardless of current clock speed. But when set to greater than 1 (e.g. 2 Default value) it acts as a multiplier for the scheduling interval for reevaluating load when the CPU is at its top speed due to high load.
This improves performance by reducing the overhead of load evaluation and helping the CPU stay at its top speed when truly busy, rather than shifting back and forth in speed. This tunable has no effect on behavior at lower speeds/lower CPU loads.
Sampling_Rate - This is measured in uS (10^-6 seconds). That is how often the kernel will poll the CPU usage and make decisions on what to do about the frequency. It's default value is 25000.
Sampling_Rate_Min - As the name states, this value provides a minimum limit on the Sampling_Rate. This is based on the Hardware Latency and Kernel variables. Default value is 10000.
Sampling_Rate_Screen_Off - As the name suggests, this is the value of Sampling_Rate when the screen is turned off. Default Value 40000.
Up_Threshold - It specifies what the average CPU usage between the samplings of 'sampling_rate' needs to be for the kernel to determine if it should increase the frequency. For example when it is set to '70', between the checking intervals the CPU needs to be average more than 70% in order to determine that the CPU frequency needs to be increased.
Up_threashold_Hotplug - As the name suggests, this value determines when to bring the second Core Online. It is done when the CPU load reached this %.
INTERACTIVE GOVERNER-
hispeed_freq - An intermediate "hi speed" at which to initially ramp when CPU load hits the value specified in go_hispeed_load. If load stays high for the amount of time specified in above_hispeed_delay, then speed may be bumped higher. Default is maximum speed.
Above_hispeed_delay - Once speed is set to hispeed_freq, wait for this long before bumping speed higher in response to continued high load. Default is 20000 uS.
go_hispeed_load - Go to hi speed when CPU load at or above this value. (Similar to Up-Threshold in other governors). The CPU load at which to ramp to the intermediate "hi speed". Default is 85%.
min_sample_time - The minimum amount of time to spend at the current frequency before ramping down. This is to ensure that the governor has seen enough historic cpu load data to determine the appropriate workload. Default is 80000 uS.
timer_rate - The sample rate of the timer used to increase frequency. It reevaluates cpu load when the system is not idle. Default is 20000 uS.
input_boost: If non-zero, boost speed of all CPUs to hispeed_freq on touchscreen activity. Default is 0.
boost: If non-zero, immediately boost speed of all CPUs to at least hispeed_freq until zero is written to this attribute. If zero, allow CPU speeds to drop below hispeed_freq according to load as usual.
boostpulse: Immediately boost speed of all CPUs to hispeed_freq for min_sample_time, after which speeds are allowed to drop below hispeed_freq according to load as usual.
WHEATLEY GOVERNER -
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.

VOLTAGES SECTION –
This Section lists all the possible Operating Frequencies of the Processor of the phone. The Mili Volt (MV) define the operating power in Volts of the Processor at that frequency. Some basic facts for you to understand. The Frequencies determine how fast the Processor will be operating. The voltages determine Juice provided to the processor. As a processor consumes higher voltage, it will generate more heat. So this section is very important and critical to everyone who wishes to either Overclock or Undervolt. ​Overclocking is a term used to determine how the operating Frequencies are controlled in order to obtain maximum performance and fastest response time. As we saw in the General Section, the Enable Overclock checkbox allows you to push the boundaries of the operating frequencies. So the processor will offer better performance, but will also generate more heat due to higher operating voltages. So in this section you will need to cool down the processor by applying lower operating voltage. This however should not be confused with undervolting.
Undervolting is a concept that is used to obtain highest amount of Battery life. As the operating voltage is the major consumer of the battery, lowering operating voltages in steps of 25 will allow the processor to operate at that frequency with a possible Lag. Weather you do notice the lag or not is dependent on how much the voltage is lowered. It is also dependent on the Max & Min Operating frequencies you chose in the General Section.
Having said that, on this screen, you can press the menu button to get a new menu. This menu will allow you to modify voltages set at each frequency step.
The option to Load Stock table allows you to reset to Default voltage values in case you wish to revert. Rest of the options to add or Subtract will let you change all steps in bulk. So for ex. the option to add 5 Volts to all steps will add 5 mv to current voltage for that step. The settings option does not seem to do anything.
[FONT=&quot]NOTE – Even though the options are in VOLTS, they should read Milli Volts.[/FONT]​

EXTRAS -
Eventhough this is called EXTRA, it actually has quite a few important options. Chief among these, is the ability to set different Governors under certain circumstances as well as setting a different upper limit on frequency.
SCREEN OFF PROFILE Mhz –
As the name says, this determines the upper limit on Operating Frequency when the Screen is Off. Thus it will override what you set on General screen. This is good to have if you want the frequency further throttled when you are not using or just have different frequency for background apps when not using.
NOTE – If you set screen turn off time too low, and the screen turns off when you are reading something; you will have unexpected consequences. Not to mention battery or smoothness hit.
DISABLE SCREEN OFF Mhz CALL –
This is a further addition to the Screen off Profile discussed above. When set, this option will apply the Screen Off Profile when you are on a call. Thus applying the frequency you set in the previous option. So you need to do this carefully in order not to get your phone unresponsive or FC’d in the middle of a call.
SCREEN OFF PROFILE GOV. –
As the name says, you get to set a different governer when screen is off. This will override what you chose in the governer choice. Pretty nifty arrangement so that you can flip from a performance governer when on screen and a power save governer when screen is off. Keep in mind the time out screen off when you are reading without interacting.
SCREEN OFF PROFILE SCHED –
Similar to the Governer, this will let you choose a different Scheduler for when the screen is off. This will override (when screen is off) what you set previously.
GPS PROFILE GOV –
Similar to Screen off, this will set a Governer choice that comes into play when you are navigating or have the GPS on. If, some of you tend to keep the GPS on permanently then keep in mind that your main choice of governer will be permanently overridden.
GPS PROFILE SCHED –
Similar to the Governer, you get to choose which Scheduler comes into play when you are navigating. Keep in mind that, during navigation, the phone will keep reading from the Google Map Cache or any other Navigation product you may be using. So choose Scheduler appropriately.
BLUETOOTH PROFILE MHZ –
This setting determines the MINIMUM operating frequency when the phone is paired over Bluetooth to another device. This is unlike the Screen off option where the Max frequency is determined.
FAST CHARGING –
One of the coolest feature of the Kernel. When set, the phone will charge off of the PC USB ports as if it is connected to wall outlet. This does turn off your access to the phone internal memory and SD card. If you want to access the internal storage on PC then you have to turn this off.
NOTE – Weather to turn on or off, has to be done before connecting to PC. Changing this after connecting has no effect.
VIBRATION STRENGTH –
This Kernel parameter is actually a multiplier. It actually determines the intensity of vibration when the phone is in vibrate mode or ring Plus Vibrate Mode. It also determines vibrations of the notifications you receive. (It is possible it also determines In-App or In-Game vibrations. I did not test). It’s a good thing to control as some of the roms have very low vibration intensity out of box. Do note that vibrations do chew up your battery. So don’t set it too high. Based on my experiments, the out of box setting at 120 seems good enough.
SWIPE 2 WAKE –
This is an Interesting concept. If this is set, then you get to short circuit the process of waking the phone. What you need to do is slide through the capacitive buttons on your phone as if you are sliding the screen to unlock. This bypasses the step where you press power or home button to wake to lock screen and then actually unlock the phone.
Given that my phone SGH-T999 does not have all Capacitive buttons, it does not seem to work. Besides I have secured pin on my lock screen so it won’t unlock by this method either. (I don’t find it that useful either.)
INTERNAL READ AHEAD, EXTERNAL READ AHEAD –
Both of these parameters control the size of the buffer. Internal refers to your Internal SD Card & External refers to the MicroSD card. Do note, the buffer resides in RAM. So if you set it too high then you won’t have free RAM to play with. Also This must be used with a judicious choice of the Scheduler.
GPU GOVERNER –
This is probably of interest only to the gamers or Graphic intensive app users. Similar to the previous governer choices for CPU, this option allows you to further tweak the Governer choice for your GPU. It only affects the Graphics displayed. So unless you have graphic intensive app running, you won’t notice the difference. By default it will use the Governer set for the CPU.
TRINITY COLORS –
This of this, like the Gamma control on your TV or a monitor. This determines the basic color pallet on your phone. Think of it as if you applied a color filter to the screen. Based on what value you set here, effect will be immediate.
CONGESTION CONTROL –
First of the TCP/IP network performance parameter. TCP Congestion Control determines which algorithm is applied for the network congestion avoidance. You have two choices. Cubic & Reno. Cubic is less aggressive and Reno is more aggressive. Suffice it to say that pretty much every one will have their own performance. So there is no recommendation. For the more geeky minded, here’s the Wikipedia link.
TIME WAIT RECYCLE –
Second of the TCP/IP network performance parameter. This parameter determines, how long will the system wait before it will recycle a connection in wait state. It will benefit those on Wireless or high speed data plans. Default is Enabled. So if you have perennial bad performance on high speed connection, you can turn it off.
TIME WAIT REUSE –
Third of the TCP/IP network performance parameter. Similar to Recycle above, this too controls the time before the system reuses a connection. This too is set to Enable. Turn it off if you have connectivity issues.
SHOW TOAST MESSAGES –
This controls weather Kernel response messages are displayed on screen. These are either for the automated actions or response to changes you made. Default is enabled.
ENABLE KTWIDGET TIMER –
To be honest, I have no idea what this does. If someone is willing to share, I will be more than happy to add.
BATTERY MHZ CONTROL –
This actually has its own sub menu. Effectively it allows you to throttle down the CPU frequency if the battery is too low or is high. You also get to define what is the low level and what is the high level. Lastly, you can turn it off while charging.
NOTE – This has a direct conflict with what frequencies you have set on the main screen. So use judiciously.
KTHERMAL CONTROL –
This too has its own sub menu with several options. Effectively it allows you to throttle down the CPU and GPU in case the phone has heated, as the warning correctly says on the submenu, if you don’t set it correctly, you will damage the processor.
The options are pretty much self explanatory. Just to keep the noobs from killing their phones, I am not explaining each option. If there is high demand, I will add individual description here.
GET LAST_KMSG, GENERATE A DMESG, GENERATE A LOGCAT –
[FONT=&quot]All three of these are KTOONSEZ’s way of grabbing error messages in case stuff happens. These are saved as text files on your internal sd card. You will only need these options if you are trying to identify a possible kernel issue.[/FONT]

SET OPTIONS ON BOOT -
This option allows you to choose when to apply the settings you have provided here. You may apply them immediately after booting or wait for some time before applying. If you are testing some exotic setting, choose to apply with delay so that you have time to revert to stock.
BACKUP PREFS TO SDCARD –
Pretty much self explanatory. It exports the settings to internal SD Card under the path you specify.
RESTORE PREFS FROM SDCARD –
Same as above, allows you to restore settings previously exported.
LOAD DEFAULTS –
Allows you to set default values of the kernel. These are the values, KTOONSEZ has set for the kernel. Safe spot to run to if you managed to mess up the settings.
That pretty much concludes all the options on the KTweaker app.

RECOMMENDED SETTINGS -
This section is intended to provide basic stable profiles that have been tested repeatedly. These profiles would help beginners to get started in the direction they wish to go. Of course they may not be the best in that class. But then no two phones are same so what works for one may not work for others.
Note-
For those who wish to further Battery life, you may do well to visit this thread on Eliminating Google Services Wakelock.
The general process for using these files is as follows.
1. Download the file(s) to your phone. In case of .BIN files, optionally rename as .TXT
2. Copy the file(s) to /SDCARD/KTweaker folder with file Manager of your choice.
3. Open Ktweaker app, click on Import Settings.
4. The file you just copied should be listed there.Choose the one you want to apply.
5. After applying, make sure Set Options on Boot Setting on main Menu of the KTweaker app has a little green text bellow confirming that the settings will be applied upon reboot.
6. Profit !
If you are hungry for more or wish to tinker further, head over to the Team Kernerlizer Threads. Links are given bellow. (Hidden in order to tidy up the thread.)[/COLOR]
Team Kernalizer Galaxy SIII threads by Carrier -
Team Kernalizer Thread for T Mobile Galaxy SIII / D2TMO - Thread Link
Team Kernalizer Thread for Sprint Galaxy SIII / D2SPR - Thread Link
Team Kernalizer Thread for AT&T Galaxy SIII / D2ATT - Thread Link
Team Kernalizer Thread for Verizon Galaxy SIII / D2VZW - Thread Link
Given bellow are some of the tried and tested profiles.
1. Conservative Battery Saver Profile -
Conservative Balanced Settings by @LuigiBull23
Settings File is for AOSP version of the Kernel. Attached to this post - ROW-Balanced_Bull_v2.txt
The battery life for him with these settings can be seen bellow.
I on the other hand had a little bit better luck with my light to moderate use. (Hidden to tidy up the thread).
NOTE - I had accidentally connected the phone to Laptop for a minute or 2 when Battery was at 12 % (Fast Charge was ON).
Do Please note, there is an additional experimental profile called Bless the Child V3 by @LuigiBull23 that Ihave attached bellow. Try if you wish. I will post the results of my test after next Charge Cycle.
LuigiBull23 said:
ROW Balanced Bull v3​
***Reported to have resolved issues with battery drain, overheating, and random reboots!***​
General
Locked Frequencies
CPU (MIN): 135Mhz
CPU (MAX): 1404Mhz
Scheduler: ROW
Scheduler Adjustments:
> hp_swrite_quantum = 3
> low_starv_limit = 8000
> rd_idle_data = 5
> rd_idle_data_freq = 15
> reg_starv_limit = 4000
> rp_swrite_quantum = 2
> rp_write_quantum = 2
Governor: Ktoonservative
Governor Adjustments:
> boost_cpu = 1026
> boost_hold_cycles = 18
> boost_turn_on_2nd_core = 0
> down_threshold = 58
> down_threshold_hotplug = 65
> freq_step = 2
> sampling_down_factor = 2
> sampling_rate = 25000
> sampling_rate_screen_off = 40000
> up_threshold = 70
> up_threshold_hotplug = 80
Voltages
CPU: -30mV across the board
GPU: -50mV across the board
Extras
Screen Off Profile Mhz: 378
Screen Off Profile Gov: Same as selected governor
Screen Off Profile Sched: Same as selected scheduler
Miscellaneous Section:
> Vibration Strength: 60
SD Card Section:
> Internal Read Ahead = 2048
> External Read Ahead = 2048
Battery Mhz Control:
> Battery Level Low: 20
> CPU Mhz for Low Level Battery: 1080Mhz
[/CODE]
Click to expand...
Click to collapse
2. Extreme UNDERVOLTING PROFILE -
Extreme Undervolting without Lag by @iamikon
iamikon said:
Forget that try this! SIO-NoCleverName-AOSP
http://db.tt/3dcMQCz0
Click to expand...
Click to collapse
NOTE - You may need to up voltage by 50 mV if you continue to experience lag or Freeze.
Settings File for AOSP Version of the Kernel is attached - sionoclevernameaosp.txt
3. Gamer (Or Game intensive) PROFILE -
Thanks to @RErick, here's a good stable setup for those who wish to play Graphic Intensive (Shadowgun DeadZone ) games on their phones.
Obviously, you won't be expecting outstanding battery life with intense gaming. (Can I get Prius Gas Mileage from a Corvette ?) But if you do, @RErick has graced us with this Profile. Do note this second profile may potentially lag under heavy Graphics.
But

@Perseus71
http://lwn.net/Articles/509829/
Info on ROW scheduler

castle_bravo said:
@Perseus71
http://lwn.net/Articles/509829/
Info on ROW scheduler
Click to expand...
Click to collapse
Thanks Castle. Appreciate the link.

It's about damn time!! lol I've been waiting for a guide like this that works in correlation to the Ktweaker app.. It will definitely benefit to newcomers as well as current users of this kernel.
Great guide! Thanks buddy :good:

Great guide, excellent work! Subscribed!

Great work my friend will be adding this to all the tk threads if you ever need anything just give a buzz we would glad to help anyway possible and again great write up amd guilde very informative
http://pbr1202.photobucket.com/albums/bb374/TexasEpic/Requested Banners/SPH-L720v3_zps61b75aad.png

Look good friend. Keep up the good work. I will link in my threads too

Hi nice work there, but is there any latest settings for tw version ? Or have i missed it ?

Rayfucious said:
Hi nice work there, but is there any latest settings for tw version ? Or have i missed it ?
Click to expand...
Click to collapse
I personally use AOSP Roms. So I can't translate them to Touchwiz. However, I have given the individual setting Values for the Balanced Profile. You can enter these values into KTweaker to get the file.

Perseus71 said:
I personally use AOSP Roms. So I can't translate them to Touchwiz. However, I have given the individual setting Values for the Balanced Profile. You can enter these values into KTweaker to get the file.
Click to expand...
Click to collapse
So i can enter the above values into TW version and compatible ? cause i thought aosp kernel settings and tw would be different.
Can't find this 2 settings in ktweaker for tw version though.
up_threshold_hotplug = 80
down_threshold_hotplug = 62
The rest are fine though. Will be trying out and see how it goes.

[REF][TWEAKS] Kernel Governors, Modules, I/O Schedulers, CPU Tweaks, AIO App Configs

@moderator
Since i have been on xda for quite some time,i realised that many people here dont know much about governers,i/o schedulers etc. . So i decided to give them a guide which will help them learn the basics of these things.Please remove this thread only if u find this is a waste of time.
Click to expand...
Click to collapse
First of all ,i did not make this guide.It was made by "droidphile" ,a recognised contributor of xda forums.the original thread link is here-
http://forum.xda-developers.com/showthread.php?t=1369817
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.
4)droidphile for his excellent guide
Most of us are flash maniacs, and we do it a lot. But after a kernel flash, we wonder:
Q1. "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".
Q2. "What's the fuzz about these modules that comes with the kernel. How do i use them. Are they any good. Is it OK to neglect them?"
Q3. "What roles does an i/o scheduler play? How to choose a reliable i/o scheduler?"
Q4. "Can i have more control on CPU? More info and tweaks on dual core CPU, bus frequency, etc?"
Q5. "Better understanding on impact of different values for basic/advanced parameters in the Kernel Config App, so that i can tweak the settings according to my taste?"
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.
INDEX--
POST 1: KERNEL GOVERNORS
POST 2: GOVERNOR TWEAKS
POST 3: LOADABLE KERNEL MODULES
POST 4: I/O SCHEDULERS
POST 5: DUAL CORE CPU Q&A AND TWEAKS

GOVERNERS
GOVERNERS
Click to expand...
Click to collapse
I) MANUAL:
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-http://forum.xda-developers.com/showpost.php?p=24233103&postcount=3&nocache=1&z=3535953573882580
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
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
II) QUESTION TIME:
Q. "Ok. Enough of explanations. Tell me which governor is for performance and which one is for battery life."
A. Tough question! lulzactive and smartassV2 for a balance between performance and battery. For light weight tasks, lulzactive should be better for battery. And for heavy weight tasks, lulzactive should be better for performance also. To get maximum performance, use a tweaked ondemand or conservative, but never complain about battery. NOTE: It's not so easy to tame luzactive. If you don't know how exactly to do it, stay away from it or you will end up complaining about battery drain!
Q. "Hey, almost forgot. How do i change governors?"
A. Best way is to use an init.d script if your kernel supports it. (echo "governor-name" > /sys/devices/system/cpu/cpu0/cpufreq /scaling_governor) Else use Voltage Control/SetCpu/No Frills/Antuntu CPU Master, etc. Voltage Control has the interfaces for gpu oc/uc/uv and charge-current change if your kernel supports them. Like we guessed, these apps will tell us the active governor too.
Q. "How do i know which governor is best for me?"
A. It depends on what you need and your daily usage pattern. Performance or battery. Better choose a governor that's balanced for battery/performance. Or tweak a governor to give performance an upper-hand as compared to battery. We can always re-charge the phone: In car when off to work, or overnight. But we can not recharge performance! After all, we bought GS2 to enjoy it's sheer power.
Q. "Well i have set my favorite governor as screen-on governor and another one as screen-off governor. Why the hell is the phone not waking up after deep sleep. I need to force-restart the phone by pressing power button for about 10 secs. Is it a sleep-of-death?"
A. Yes it is. Do not use two governors as screen-on & screen-off govs, if they both have an upper frequency limit for screen-off state.
Didn't get it? Examples for Wrong combinations: (screen-on:screen-off):-
ondemandX:smartassV2
Examples for right combinations:-
ondemand:smartassV2, lulzactive:smartassV2
Q. "I can feel slight lags here and there with a governor. For ex: while scrolling through app drawer/vertically scrolling browser, etc. I really love this governor and don't tell me to use another governor. Can i diminish this lag?"
A. Hmm well, you can. Basically what we have to do is make the governor "poll" less often to scale-down cpu. Increase down-sampling-time of your governor (whichever parameter that corresponds to), so that the cpu will stay longer on a frequency before scaling down. This should eliminate the lag.
Q. "Even though i don't have too much uv/oc, once in a while; may be once in two weeks, i experience a freeze/lock/reboot. I'm using governor X. How do i solve this?"
A. Well, a random reboot/freeze once in a while signifies that we're android/galaxy SII enthusiast. If everything go smooth as silk, what's the fun? We could use stock rom/kernel/governor and be happy. A rare reboot or freeze is nothing to worry about. Just restart the phone.
Q. "OK. I want to tweak these governors according to my usage pattern, because i'm not happy with the default behavior of these governors".
A. You can tweak the governors using an init.d script to echo suitable values into:
/sys/devices/system/cpu/cpufreq/name-of-active-governor/name-of-the-paramater-to-tweak
Example:
echo "20000" /sys/devices/system/cpu/cpufreq/lulzactive/up_sample_time
Q. "I'm going to set scaling min freq as 100 mhz because my kernel supports it. Hope there's nothing wrong in doing that."
A. Wait! You may want to stay away from using 100mhz during screen-off or screen-on states for three reasons 1) It seems 100 mhz uses more power than 200 mhz. According to tests, 100 mhz accounted to 1 W / GHz and 200 mhz to 0.7 W / GHz, when both the cores were online. 2) 200 mhz can finish same task faster compared 100 mhz and thus hit deep idle soon. 3) 200 mhz is the 'sweet spot' of frequency in SGS II. ie, the frequency used in the calculations based on the optimal energy to run (Ex: In Milestone it's 550 MHz). So , 'energetically efficient' frequency for our CPU is 200 mhz.
Q. "I want to know is there's anything more i can do to improve battery life. I have already tweaked my governor settings but..."
A. Take my word. Best way is to limit scaling max freq to 800 or 1000 mhz. Sgs2 can do majority of the task with 1000 or 800 as the max. OCing to 1600mhz draws considerably more power than stock 1200mhz or even 1400mhz. Try scaling between 200 and 1000 mhz for a day and feel the difference.
Q. "How to make my device more snappier. I don't care much about batt....err...I do care about battery life, but only in terms of avoiding unwanted power consumption. Device should instantly dance to my tunes."
A. Scale 500 to 1200 during screen-on and 200-500 during screen-off. Use performance tweaked conservative/ondemand(x). No excess power consumption because 1400 and 1600 is out the league. Response will be sweet. And don't worry, minimum of 500 during screen-on will not drain too much battery like you think!
GOVERNER TWEAKS IN NEXT POST

Governer tweaks
GOVERNER TWEAKS
Click to expand...
Click to collapse
III) PARAMETERS & TWEAKS:
[Only Ondemand, Conservative, SmartassV2, Lulzactive and Interactive; being the most preferred governors.]
Different governors has different parameters. But it's easy to understand a governor. Ideally, a governor will have:-
1) Sampling Interval/Rate measured in uS by which the polling function determines how often to poll and decide if frequency should be scaled-down or scaled-up. [Some governors will have different sampling time for scaling-up and scaling-down]
2) Thresholds measured in percentage. When CPU load reaches this point, governor scales up or scales down the CPU. [Most of the governors will have down-threshold and up-threshold, for which CPU is scaled down or up respectively.
There are various other parameters/factors too, but all are in someway related to these two parameters.
1.ONDEMAND
[ PARAMETERS ]
i) 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.
ii) 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.
iii) 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.
iv) 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.
v) 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.
vi) 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.
[ SAMPLE TWEAKS ]
i) For battery:-
To bias ondemand towards battery saving, set high up-thresholds and higher sampling-rate. This way, governor polls less often and scales up less often.
Code:
echo "95" /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo "120000" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
echo "1" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
echo "5" > /sys/devices/system/cpu/cpufreq/ondemand/down_differential
echo "10" > /sys/devices/system/cpu/cpufreq/ondemand/freq_step
ii) For performance:-
To bias ondemand towards performance, set low up-thresholds and lower sampling-rate. This way, governor polls more often and scales up quite often.
Code:
echo "70" > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo "50000" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
echo "2" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
echo "15" > /sys/devices/system/cpu/cpufreq/ondemand/down_differential
echo "50" > /sys/devices/system/cpu/cpufreq/ondemand/freq_step
2.LULZACTIVE
1. Initial Version:-
[ PARAMETERS ]
i) down_sampling_time - Sampling time to scale cpu down.
ii) up_sampling_time - Sampling time to scale cpu up.
[ SAMPLE TWEAKS ]
Unfortunately, the initial version of lulzactive doesn't give user much control on it's behavior. We can only control how often cpu should scale up and scale down. Use higher down_sampling_time if you experience lag while scrolling through browser, app drawer, etc. Better keep the default up_sampling time (24000) unchanged. And make down_sampling proportional to up_sampling. Like 2x24000=48,000 or 3x24000=72000.
2. Second Version:-
[ PARAMETERS ]
i) inc_cpu_load - In previous version, this was 'hard-coded' to 60. Now it's user-configurable. The frequency at which governor scales CPU up/down. Load < inc_cpu_load: cpu scaled down. Load >= inc_cpu_load: cpu scaled up
ii) pump_up_step - No of scale up steps when load >= inc_cpu_load
iii) pump_down_step - No of scale down steps when load < inc_cpu_load
iv) screen_off_min_step - Steps in frequency table to be used when screen-off. Example: If available freqs are 1600 1400 1200 1000 800 500 200 100 (L0 to L7) and screen_off_min_step=5 then 100,200 and 500 (L5 to L7) will be used during screen-off depending on the demand.
v) up_sample_time - same as initial version. (Allowed values 10,000 to 50,000)
vi) down_sample_time - same as older version. (Allowed values 10,000 to 100,000)
[ SAMPLE TWEAKS ]
i) For battery:-
Code:
echo "90" > /sys/devices/system/cpu/cpufreq/lulzactive/inc_cpu_load
echo "1" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_up_step
echo "2" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_down_step
echo "50000" > /sys/devices/system/cpu/cpufreq/lulzactive/up_sample_time
echo "40000" > /sys/devices/system/cpu/cpufreq/lulzactive/down_sample_time
echo "5" > /sys/devices/system/cpu/cpufreq/lulzactive/screen_off_min_step
This tweak cause lulzactive gradually scale up CPU and rapidly scale down on low load.
ii) For performance:-
Code:
echo "60" > /sys/devices/system/cpu/cpufreq/lulzactive/inc_cpu_load
echo "4" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_up_step
echo "1" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_down_step
echo "10000" > /sys/devices/system/cpu/cpufreq/lulzactive/up_sample_time
echo "70000" > /sys/devices/system/cpu/cpufreq/lulzactive/down_sample_time
echo "5" > /sys/devices/system/cpu/cpufreq/lulzactive/screen_off_min_step
This tweak cause lulzactive scale up CPU rapidly, polling often and scale down gradually.
iii) For balanced-performance:-
Code:
echo "90" > /sys/devices/system/cpu/cpufreq/lulzactive/inc_cpu_load
echo "4" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_up_step
echo "1" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_down_step
echo "10000" > /sys/devices/system/cpu/cpufreq/lulzactive/up_sample_time
echo "40000" > /sys/devices/system/cpu/cpufreq/lulzactive/down_sample_time
echo "5" > /sys/devices/system/cpu/cpufreq/lulzactive/screen_off_min_step
This tweak cause lulzactive to poll more often and scale up 4 steps above current frequency, but only at 90% load. CPU is scaled down normally.
note: If you're lazy to use a script, use lulzactive app from market to tweak the governor.
3.SMARTASSV2
[ PARAMETERS ]
i) awake_ideal_freq - The frequency until which CPU is scaled up rapidly on screen-awake (from sleep). Thereafter, scaling up is less aggressive.
ii) sleep_ideal_freq - The frequency until which CPU is scaled down rapidly when screen is turned off. Thereafter, scaling down is less
aggressive.
iii) 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)
iv) 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)
v) max_cpu_load - Same as up_threshold in other governors.
vi) min_cpu_load - Same as down_threshold in other governors.
vii) 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.
viii) 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.
ix) sleep_wakeup_freq - The frequency to set when waking up from sleep. When sleep_ideal_freq=0 this will have no effect.
[ SAMPLE TWEAKS ]
i) For battery:-
Code:
echo "500000" > /sys/devices/system/cpu/cpufreq/smartass/awake_ideal_freq;
echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_ideal_freq;
echo "500000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_wakeup_freq
echo "85" > /sys/devices/system/cpu/cpufreq/smartass/max_cpu_load;
echo "70" > /sys/devices/system/cpu/cpufreq/smartass/min_cpu_load;
echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/ramp_up_step;
echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/ramp_down_step;
echo "48000" > /sys/devices/system/cpu/cpufreq/smartass/up_rate_us
echo "49000" > /sys/devices/system/cpu/cpufreq/smartass/down_rate_us
ii) For performance:-
Code:
echo "800000" > /sys/devices/system/cpu/cpufreq/smartass/awake_ideal_freq;
echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_ideal_freq;
echo "800000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_wakeup_freq
echo "75" > /sys/devices/system/cpu/cpufreq/smartass/max_cpu_load;
echo "45" > /sys/devices/system/cpu/cpufreq/smartass/min_cpu_load;
echo "0" > /sys/devices/system/cpu/cpufreq/smartass/ramp_up_step;
echo "0" > /sys/devices/system/cpu/cpufreq/smartass/ramp_down_step;
echo "24000" > /sys/devices/system/cpu/cpufreq/smartass/up_rate_us
echo "99000" > /sys/devices/system/cpu/cpufreq/smartass/down_rate_us
4.CONSERVATIVE
[ PARAMETERS ]
i) down_threshold,
ii) up_threshold,
iii) sampling_down_factor,
iv) sampling_rate - Refer above governors.
v) freq_step - Defines how much (as a percentage of the maximum CPU speed) the conservative governor will increase the CPU speed by each time the CPU load reaches the Up Threshold.
[ SAMPLE TWEAKS ]
i) For battery:- [Set freq_step to lower value to make conservative governor conserve more battery]
Code:
echo "95" > /sys/devices/system/cpu/cpufreq/conservative/up_threshold
echo "120000" > /sys/devices/system/cpu/cpufreq/conservative/sampling_rate
echo "1" > /sys/devices/system/cpu/cpufreq/conservative/sampling_down_factor
echo "40" > /sys/devices/system/cpu/cpufreq/conservative/down_threshold
echo "10" > /sys/devices/system/cpu/cpufreq/conservative/freq_step
ii) For performance:- [Isn't it ironical that we are tuning Conservative to achieve blazing performance!]
Code:
echo "60" > /sys/devices/system/cpu/cpufreq/conservative/up_threshold
echo "40000" > /sys/devices/system/cpu/cpufreq/conservative/sampling_rate
echo "5" > /sys/devices/system/cpu/cpufreq/conservative/sampling_down_factor
echo "20" > /sys/devices/system/cpu/cpufreq/conservative/down_threshold
echo "25" > /sys/devices/system/cpu/cpufreq/conservative/freq_step
5.INTERACTIVE
[ PARAMETERS ]
i) hispeed_freq - Hi speed to bump to from lo speed when load burst. (Default value is scaling max freq)
ii) go_hispeed_load - Go to hi speed when CPU load at or above this value. (Similar to Up-Threshold in other governors)
iii) min_sample_time - The minimum amount of time to spend at a frequency before we can ramp down. (Sounds like Lazy governor?!)
iv) timer_rate - The sample rate of the timer used to increase frequency.
[ SAMPLE TWEAKS ]
i) For battery:- [Interactive and battery?!! I'm capping the highspeed_freq in the hope of saving battery]
Code:
echo "95" > /sys/devices/system/cpu/cpufreq/interactive/go_hispeed_load
echo "1000000" > /sys/devices/system/cpu/cpufreq/interactive/hispeed_freq
echo "10000" > /sys/devices/system/cpu/cpufreq/interactive/min_sample_time
echo "40000" > /sys/devices/system/cpu/cpufreq/interactive/timer_rate
ii) For performance:- [Assuming your scaling_max_freq is equal to or above 1400 mhz)
Code:
echo "80" > /sys/devices/system/cpu/cpufreq/interactive/go_hispeed_load
echo "1400000" > /sys/devices/system/cpu/cpufreq/interactive/hispeed_freq
echo "40000" > /sys/devices/system/cpu/cpufreq/interactive/min_sample_time
echo "20000" > /sys/devices/system/cpu/cpufreq/interactive/timer_rate
IV) GUIDE TO INIT.D SCRIPTS
When I'm writing tweaks all over the thread, it's unfair if i don't cover a small guide to scripts since there are people who does not have any experience or knowledge on init.d scripts. So here are the "WHATs" and "HOWs".
If you're already familiar with init.d scripts, please skip this part.
Android boot-up process can be divided into three parts on a high-level.
1) First stage bootloader runs.
2) Kernel boots and it loads various drivers, prepares hardware and so on.
3) User space programs are invoked. It is in this stage where init.d scripts are executed. (Also various apps and daemons are started to prepare the rom)
Most of the custom kernels supports init.d scripts. Some developers choose to run init.d scripts whose names starts with an "S". Others choose to execute all the scripts inside init.d directory.
Init.d script are to be placed inside /system/etc/init.d directory (or /etc/init.d which is a symbolic link to /system/etc/init.d)
Order of executing init.d scripts are in the increasing order of ASCII values that corresponds to their names. For ex: among two scripts named, "Ascript1" and "Bscript2", "Ascript1" will be executed first. If there is a particular reason that we need one script to be executed before another, make sure you name it properly.
GUIDE:
First line of any script should invoke a compatible shell/interpreter which is responsible for executing the rest of the script. The compatible shell may be the default shell "sh" or "busybox".
So first line of any script should look like this:
#!/sbin/busybox sh or #!/system/xbin/busybox sh [The location of busybox may vary with roms/devices. So please check with root explorer, busybox location and change the path accordingly]
OR
#!/system/bin/sh
From next line, the actual script starts.
ex: echo "200000" > /sys/devices/system/cpu/spu0cpufreq/scaling_max_freq
Make sure there are no syntax errors first, (also check for logical errors)
Most common error is to use a windows-based editor which leaves an extra space at the end of each line or leaves an invisible invalid character when you press carriage return (ENTER key).
So do not use editors such as notepad or wordpad to create scripts. Use Notepad++, a free GNU editor.
After finishing the script, check for extra spaces at the beginning and end of each line in the script. If found, remove them.
Save the script without any extensions (Yes, not even .sh extension).
Use adb or rootexplorer to push the script into /etc/init.d and set permissions.
Read this beautiful guide on how to install SDK and setup ADB without any hassle on your PC.
Using root explorer, copy the script to /etc/init.d and set permissions:
owner : rwx
group : r_x
others : r_x
Download script manager from market, use it to run the script as root by checking the skull symbol. This is only to check the script for any errors. If exit code= 0, script executed successfully. From now on, your script will be automatically executed on every reboot. But if script manager shows errors, again edit the script (using notepad++ in your PC or using script manager editor itself from your phone), fix the errors and execute again. Repeat this until script is error-free. Remember once again: "A single extra space at the end of a line is a syntax error and script will fail to execute the rest of the lines."
To add comments you can use "#"

MODULES
MODULES
A loadable kernel module is an object that contains some code to extend your kernel. Modules serves various type of purposes like support for new hardwares, filesystems, and system calls. It is probable that once a new module is inserted, it might cause minor fragmentation in kernel resulting in a minor performance penalty. Mostly, not noticeable.
We might ask "ok, if kernel modules are so amazing, why not add them all into the kernel code instead of asking us to load them". Well, the advantage to LKMs is that you can minimize the memory footprint for a kernel, loading only those elements that are needed.
You can find all the modules in /lib/modules. (With extension .ko = Kernel Object).
To avail a module, you need to install/insert it by:
Code:
insmod /lib/modules/module-name.ko
Put the line in an init.d script to load the module(s) on every boot.
To view the list of modules that are loaded by default, use:
Code:
lsmod
To unload/remove a module (that has been loaded):
Code:
rmmod "modulename"
LIST OF MODULES
1) bthid.ko* - BlueTooth Human Interface Device
Signifies: Bluetooth
Bthid is one of the bluetooth profiles. The module provides support for devices such as bluetooth mice, joysticks,keyboards,etc. It uses a low latency link with low power requirement to achieve the above mentioned.
2) cifs.ko - Common Internet File System
Signifies: Network Share
Successor to the SMB (Server Message Block) protocol, this protocol is supported by windows servers, samba, etc. The module is responsible for managing your network shares. It is used to mount/unmount network file resources on to your device. If special characters are not properly read/displayed, download and use nls_utf8.ko module for UTF-8 character support.
3) fuse.ko* - File System in Userspace
Signifies: File System
The module let the users create own filesystems without editing kernel code. Fuse module act as a bridge between filesystem code running in the userspace and kernel interface. The module is often used in our devices to support ntfs/ntfs-3g filesystem for mounting ntfs formatted hard drives and pen drives.
4) cuse.ko - Character Devices in User Space
Signifies: Audio Proxying
CUSE is an extension of FUSE allowing character devices to be implemented in userspace. One of the prime motivation for developing cuse is to provide a better support for Open Sound System or OSS. Except for initialization sequence and creation of character device instead of a mount, CUSE isn't very different from FUSE. CUSE is used for tasks like proxying OSS audio from OSS apps to an audio system.
5) dhd.ko - Dongle Host Driver
Signifies: Wifi
This module (from broadcom) is the wifi kernel module/wireless driver, and is responsible for wifi tethering, and such.
6) ftdi_sio.ko - Future Technology Devices International - Serial I/O
Signifies: USB Serial Devices
The module is required to connect an embedded device to our device using FTDI USB-serial converter. The embedded device will be an ftdi chipset based device. Devices like an USB-RFID reader could be connected.
7) usbserial.ko - USB Serial
Signifies: USB Serial Modems
This module is often used along with ftdi_sio module. It is the usbserial-generic interface for linux platform. The module is used to detect and use devices such as usb serial modems.
8) gspca_main.ko - GSPCA Main Driver
Signifies: Webcams
This module is used to install gspca based web camera in our device. The module is the driver that's responsible for detecting and functioning of gspca based webcams.
9) hfs.ko - Hierarchical File System
Signifies: Mac Filesystem
This module is the driver to support HFS aka Mac OS Standard file system. Try mount -t hfs "/source" "/destination" to mount. Also give USB Mass Storage Watcher App from market a try, to skip commands and mount via GUI.
10) hfsplus.ko - Hierarchical File System Plus
Signifies: Mac Filesystem
This module acts as the driver for HFS+ aka Mac OS Extended file system. HFS+ is one of the formats found in iPods. Use mount -t hfsplus "/source" "/destination" for mounting drives.
11) j4fs.ko* - Jong Jang Jintae Jongmin File System
Signifies: File System
J4fs is a filesystem based on LFS (Linear File Store). The bootlogo and some misc files in our device, mounted in /mnt/.lfs is formatted as j4fs filesystem by default.
Please do not mess with .lfs folder!
12) ld9040_voodoo.ko* - LD9040 AMOLED Driver
Signifies: Voodoo Color
Module/driver for voodoo color/screen tuning support for our device. Let's wait patiently until supercurio comes out with a legendary app to have full control on our amoled display.
13) scsi_wait_scan.ko - Small Computer System Interface Wait Scan
Signifies: Waiting During Booting
scsi_scan_wait is responsible to wait until all the asynchronous scans are complete. It will wait after all root SCSI drivers have finished scanning their busses. Note that use of this module can increase your bootup time.
14) Si4709_driver.ko* - Si4709 FM Radio Driver
Signifies: FM Radio
Si4709 is the fm radio receiver driver. Module is loaded by default by Siyah. If there are issues with fm radio in aosp roms, try inserting this module.
15) vibrator.ko* - Vibrate Sensation on Touchsense
Signifies: Haptic feedback
This module from immersion corporation is responsible for haptic feedback. It senses touch as a request and sends back vibration as response. Try inserting this module if haptic feedback not working on aosp roms.
16) logger.ko - Logger for Android
Signifies: Logging/Debugging
Loggers are used to log records to a variety of destinations such as log files or the console. Install this module to enable logging, if logging is disabled in your kernel by default. Logging is used to generate logcats (for debugging purpose), dmesgs (message buffer of the kernel), for proper functioning of app protectors, etc.
17) mc1n2_voodoo.ko - mc1n2 Voodoo Sound Driver
Signifies: Voodoo Sound
Module/driver for Exynos Yamaha audio hardware tweaks. Provides sysfs interface for HP gain and Aout. This driver provides support for supercurio's Voodoo Louder app.
18-25) cpufreq_ brazilianwax.ko, cpufreq_ interactive.ko, cpufreq_ interactivex.ko, cpufreq_ lazy.ko, ondemandX.ko, cpufreq_ powersave.ko, cpufreq_ savagedzen.ko, cpufreq_ userspace.ko
Insert these module(s) to avail your favorite governor which are not loaded by default.
*Modules preloaded in Siyah by default.
Q&A
Q. "I can not find a module that i need to use with the current release of my kernel. Can i use the module downloaded from internet?"
A. Module should be binary compatible with the kernel version. So even if the module was one that came with an older version of the kernel, it's probable that the compatibility is lost.
Q. "I feel there could be some advantage if i remove modules which is no use for me, but they're loaded by kernel during boot-up. What can i do?"
A. Put "rmmod name-of-module" in one of your init.d script, so that it's uninstalled on every boot-up. After booting if you need to use the module, you can insmod it. Ex: rmmod Si4709_driver.ko. (If you don't use FM radio)

I/o schedulers
I/O SCHEDULERS
Q. "What purposes does an i/o scheduler serve?"
A.
Minimize hard disk seek latency.
Prioritize I/O requests from processes.
Allocate disk bandwidth for running processes.
Guarantee that certain requests will be served before a deadline.
So in the simplest of simplest form: Kernel controls the disk access using I/O Scheduler.
Q. "What goals every I/O scheduler tries to balance?"
A.
Fairness (let every process have its share of the access to disk)
Performance (try to serve requests close to current disk head position first, because seeking there is fastest)
Real-time (guarantee that a request is serviced in a given time)
Q. "Description, advantages, disadvantages of each I/O Scheduler?"
A.
1) 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.
Advantages:
Serves I/O requests with least number of cpu cycles. (Battery friendly?)
Best for flash drives since there is no seeking penalty.
Good throughput on db systems.
Disadvantages:
Reduction in number of cpu cycles used is proportional to drop in performance.
2) 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.
Advantages:
Nearly a real time scheduler.
Excels in reducing latency of any given single I/O.
Best scheduler for database access and queries.
Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.
Like noop, a good scheduler for solid state/flash drives.
Disadvantages:
When system is overloaded, set of processes that may miss deadline is largely unpredictable.
3) 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.
Advantages:
Considered to deliver a balanced i/o performance.
Easiest to tune.
Excels on multiprocessor systems.
Best database system performance after deadline.
Disadvantages:
Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.
4) 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.
Advantages:
Believed to be very good for usb data transfer rate.
Believed to be the best scheduler for HD video recording and video streaming. (because of less jitter as compared to CFQ and others)
Considered an accurate i/o scheduler.
Achieves about 30% more throughput than CFQ on most workloads.
Disadvantages:
Not the best scheduler for benchmarking.
Higher budget assigned to a process can affect interactivity and increased latency.
5) 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.
Advantages:
Simple, so reliable.
Minimized starvation of requests.
Disadvantages:
Slow random-read speeds on flash drives, compared to other schedulers.
Sequential-read speeds on flash drives also not so good.
6) 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.
Advantages:
May be best for benchmarking because at the peak of it's 'form' VR performs best.
I/O Schedulers
Disadvantages:
Performance fluctuation results in below-average performance at times.
Least reliable/most unstable.
7) Anticipatory
Based on two facts
i) Disk seeks are really slow.
ii) Write operations can happen whenever, but there is always some process waiting for read operation.
So anticipatory prioritize read operations over write. It anticipates synchronous read operations.
Advantages:
Read requests from processes are never starved.
As good as noop for read-performance on flash drives.
Disadvantages:
'Guess works' might not be always reliable.
Reduced write-performance on high performance disks.
Q. "Best I/O Scheduler?"
A.There is nothing called "best" i/o scheduler. Depending on your usage environment and tasks/apps been run, use different schedulers. That's the best i can suggest.
However, considering the overall performance, battery, reliability and low latency, it is believed that
SIO > Noop > Deadline > VR > BFQ > CFQ, given all schedulers are tweaked and the storage used is a flash device.
Q. "How do i change I/O schedulers?"
Voltage Control or No Frills from market.
Or init.d script:
echo "scheduler-name" > /sys/block/mmcblk0/queue/scheduler

DUAL CORE CPU Q&A and TWEAKS
DUAL CORE CPU Q&A and TWEAKS
Q. "What is the basic hardware of GS2 that make all of us enjoy this phone so much and boast about benchmark scores to office-mates and friends?"
A.
Processor: ARM Cortex-A9 MPCore processor on Exynos 4210 SoC (System on a Chip - ICs where all components are integrated into a single chip) and 45nm semi-conductor technology. Exynos 4210 is supposed to give 6.4GB/s memory bandwidth for heavy-weight ops such as full hd video encoding.
GPU: ARM Mali-400
Memory: LPDDR2 (may be DDR3)
Q. "What is the significance of bus frequency?"
A. Bus speed at its simplest form determines how fast the data should travel to and from memory. Memory throughput is directly proportional to bus frequency. In tasks that includes small amount of work on every element in a data sets, lower bus speed means longer the CPU has to wait for data to arrive from memory. Because, CPU spends only little time on each of these elements, and a slow bus cannot catch-up.
Advanced Micro-controller Bus Architecture (AMBA) is used as the on-chip bus in system-on-a-chip designs, like our device.
Q. "What is modifying bus frequency? How do I do it? Advantages?"
A. Stock behavior is dynamic bus frequency scaling, where in operating bus speed is dynamically calculated for each CPU frequency depending on the application/process’s requirement. We can modify this behavior by setting static bus frequency scaling, specifying at what bus speed should each CPU frequency operate. Three values/levels are possible.
0 – 400 mhz
1 – 266 mhz
2 – 133 mhz
Sample bus frequency modification:
echo "0 0 0 1 1 1 2 2" > /sys/devices/system/cpu/cpu0/cpufreq/busfreq_static
echo "enabled" > /sys/devices/system/cpu/cpu0/cpufreq/busfreq_static
This means for first three higher CPU frequency steps, 400 mhz bus will be used.
Next three, 266 mhz
And last two, 133 mhz
Advantages of bus frequency modification: i) Saves battery by using low bus speeds on low frequencies and ii) Prevent overheating.
Q. "I experience some lags sometimes while playing HD videos or playing heavy 3d games using static bus frequencies. Why?"
A. HD videos and some games require a minimum of 400/266 mhz bus irrespective of the CPU frequencies being used during the run. To resolve, set higer bus for 500 mhz and higher frequencies or simply disable static bus frequency scaling to switch to default.
echo "disabled" > /sys/devices/system/cpu/cpu0/cpufreq/busfreq_static
Q. "Our phone CPU has two cores. How are they utilized? Are the two cores ON all the time?"
A. The stock behavior is Dynamic Hot Plug Mode where depending on the load, the second core is turned on. If the load can be handled by a single core, the second core is turned off dynamically. This behavior can be controlled by using Tegrak Second Core app from market if your kernel supports it. (Siyah, Lulz,etc supports this). Using this app you can set three modes :-
Dynamic Hot Plug Mode: Default mode. Second core is kicked in depending on the load, and kicked out when first core can handle the load alone.
Single Core Mode: Irrespective of the load, only first core is used always. This can lead to increased battery, but reduced performance.
Dual Core Mode: Irrespective of low loads, both the cores are always active. Increased performance, but reduced battery.
Recommendation: Use the stock hotplug mode during normal use. Switch to dual core mode only for benchmarking or playing some heavy 3d games.
Q. "OK, I'm using hot plug mode, still i want to control how often the second core kicks in. To make it more aggressive/more mild depending on my usage."
A. You can set UP & LOW thresholds for second core in Screen-On and Screen-Off states.
Examples:
echo "70" > /sys/module/pm_hotplug/parameters/loadh
echo "25" > /sys/module/pm_hotplug/parameters/loadl
echo "90" > /sys/module/pm_hotplug/parameters/loadh_scroff
echo "35" > /sys/module/pm_hotplug/parameters/loadl_scroff
As you can see, when load > 70% second core becomes active and when load drops below 25%, second core is turned off.
During screen off, these values are 90 & 35 respectively. This helps in reducing unwanted kick-ins of second during screen-off state when music is playing, downloading, etc.
Q. "Like governors, is there a sampling rate/interval also at which the load on CPU is checked for crossing thresholds to turn second core ON?"
A. Yes there is. But it is set at kernel level in most kernels and can not be controlled at user level. Like you guessed, higher sampling rate could cause core 2 to kick in less often and thus save a little battery. In Siyah kernel though, these thresholds are configurable.
Q. "Advantages/Disadvantages of switching to Single Core/Dual Core modes?
A. Using only single core can save some battery, but can have some adverse effects too if there are some heavy tasks that require both cores too often: 3d games, full hd videos, etc. So use it wisely.
Using dual core mode can reduce latency by a tiny bit on high loads, as compared to hot plugging. But hot plugging is intelligent enough to turn second core ON really fast when load demands it. Only first core (cpu0) can enter deep-idle (LPA), so using dual core mode in an idle system cause unwanted excess-power consumption.
Recommendation: Use Hot Plugging and tune thresholds (like mentioned above) for a better experience.
Q. "What are these modes: IDLE, LPA and AFTR?"
A. Between screen off and deep sleep states, there are some idle modes supported by cpuidle driver. They are IDLE aka Normal Idle, LPA aka Deep Idle and AFTR aka ARM Off Top Running. Race to idle by CPU is implemented for power management.
In IDLE state, CPU is not clocked anymore, but no hardware is powered down.
In deep idle (LPA),a state after IDLE, again, the cpu is not clocked anymore like we guessed but some parts of hardware are powered down. Deep idle brings in real power savings and there is no need of putting a hard limit to frequency during screen-off; using a screen-off profile. (Good practice is to use a governor with built in screen off profile, than using an user-configured screen-off profile by putting a hard limit on frequency). Deep idle is not used when device is entering deep sleep and also when device is woken from suspend/deep sleep. While entering/exiting DEEP IDLE, CPU is set statically to SLEEP_FREQ and is not clocked below or above until it exits this state.
AFTR is a patch to support Top=Off mode for deep idle. Level 2 cache keeps it data during this mode.
We can have IDLE or AFTR modes with LPA enabled or disabled. (Obviously it is not possible to have IDLE and AFTR together)
Values:
0: IDLE
1: AFTR
2: IDLE+LPA
3: AFTR+LPA
Q. "What idle modes are recommended for power saving? How do i change it"?
A. Recommended for power saving is to enable AFTR and LPA, ie value 3
Example:
echo "3" > /sys/module/cpuidle/parameters/enable_mask
Q. "What is sched_mc?"
A. Linaro team invented sched_mc or Schedule Multi Core to make process scheduling multi-core aware. ie, utilize both cores wisely to save power and balance performance. Even though sched_mc is sort of an alternative to cpu hot plugging, we can use sched_mc with the default hot plug mode.
Possible Values:
0 : No power saving load balance, default in our exynos4210 Soc.
1 : Fill one thread/core/package first for long running threads. In our single-CPU dual-core device, multithreading does not come into picture, so load balancing is almost redundant to hotplugging.
2 : Also bias task wake-ups to semi-idle CPU package for power savings. (Bias new tasks to cpu1 if cpu0 is mostly filled with running tasks). This is 'overloading' CPU0 first.
Q. "What value is recommended for sched_mc?"
A. 1) If you find advantages to sched_mc, use sched_mc=1 for a possible battery saving. Anyhow since load-balancing is reduntant on hotplugging, it may not have any advantage on exynos chip.
2) For performance use 2. But do remember that loading CPU0 and leaving CPU1 can not do justice to hitting deep idle states sooner since second core can not enter deep idle. So extra performance or no performance, value 2 will drain some more battery, in the context of delayed didle.
3) To do justice to hotplugging, use value 0.
Example:
echo "0" /sys/devices/system/cpu/sched_mc_power_savings.
Q. "What is MALI aggressive policy on GPU?"
A. Mali aggressive scaling policy is simply lowering the up-threshold of GPU so that GPU doesn't jump to second frequency step too often. This makes more sense if lower step is under-clocked. In one release of Siyah, the threshold was changed to 55 from default 65.
Q. "What is tree rcu, fast nohz, jrcu?"
A. Read-Copy Update (RCU) is a synchronization mechanism added to Linux kernel. RCU improves scalability by allowing readers to execute concurrently with writers.
Tree RCU is a new implementation of original classic RCU to achieve more scalability as the number of CPUs increase. Tree RCU fixes a performance bug in classic RCU that results in massive lock contention on the internal RCU lock on systems with large number of CPUs.
Fast NoHz is an optimized version of the traditional Tree RCU. Many new kernels are using the Tickless NoHz design. This RCU is tailored and designed to work with the new NoHz kernel system.
JRCU mechanism in its simplest form, runs batch operations from a single CPU relieving other CPUs from this periodic responsibility. This is important for those real-time applications requiring full use of dedicated CPUs. For our dual core single CPU, JRCU can conflict with hot-plugging, hence we will have tree rcu (with or without CONFIG_RCU_FAST_NO_HZ) in our kernels.
Q. "What are SLAB, SLUB, SLQB?"
A. They're three memory allocation mechanisms.
Slab allocation is a memory management mechanism intended for the efficient memory allocation of kernel objects which displays the desirable property of eliminating fragmentation caused by allocations and de-allocations. SLAB is used to retain allocated memory that contains a data object of a certain type for reuse upon subsequent allocations of objects of the same type.
SLUB allocator promises better performance and scalability by dropping most of the queues and related overhead and simplifying the slab structure in general, while retaining the current slab allocator interface. SLUB offers to make alignment of objects and cleaning up of caches easier, as compared to SLAB.
SLQB - SLAB allocator with Queue. This is a slab allocator that focuses on per-CPU scaling. This memory allocator is designed for small number of CPUs system. This allocator is designed to be simple.
Note that SLUB is significant on a system with large number of CPUs. SLAB has the advantage of being simple.
Q. "Can i change the RCU synchronization mechanism & memory allocators?"
A. NO. They are set at compile time at kernel level, and are not configurable from user space.
MISC Q&A
Q. "What is top-off current?"
A. Charge cycle for the device's battery actually consist of two stage.
First stage consist of supplying a constant current until battery reaches it's constant/peak voltage, something between 4.1 and 4.2 v.
Upon reaching this peak voltage, a constant voltage is applied until the charge current goes below top-off current. This is the second stage. Stock top-off current is 200ma. From Siyah 2.6.9, it is set to 100ma just so that a little more juice goes into battery since a lower top-off current means longer the constant voltage is applied in the second phase of charging.
If you love your battery, do not charge to 'real' 100% too often. Perform the 'trickle' charge only once every 20 days or so.
Q. "My battery drains fast sometimes immediately after a kernel flash. It's like this: i reboot the device with 40 percent battery left and when it returns, i have only 20 percent left. Anything i can do?"
A. Your battery is not actually draining fast. But the fuel gauge is showing funny values which is not the real percentage left. On high-loads, like immediately after you reboot cause the fuel gauge to report low percentages. What you can do is to reset the fuel gauge.
[Courtesy Entropy512. The code is for i9100. Location of reset-file may be different in other variants of GS2]
Give it a few hours after you reset the gauge. It may still show you funny values for those period, then the battery percentage should be fine.
Code:
echo "1" > /sys/devices/platform/i2c-gpio.9/i2c-9/9-0036/power_supply/fuelgauge/fg_reset_soc
Q. "So CPU/GPU or GPS chip, which is the biggest power drainer in GS2?"
A. It is the bright amoled display! Display uses roughly 370mW average and 960mW with 100% brightness full white screen. Avoid bright wallpapers, reduce brightness.
Q. "What're the approximate power consumptions by the device peripherals & activities?"
A.
AMOLED Display: Average - 370mW. Full white background, 1% brightness - 450mW. Full white background, 100% brightness - 960mW. So roughly every percentage of brightness increased accounts to additional 5.2mW. (Now we know why using dark wallpapers and reducing brightness is so important than undervolting).
Illuminated button - 40mW
Led lamp next to camera - 1.3W
Camera - 700mW
Bluetooth and GPS - 110 to 180mW (Really?!)
2G to 3G switching - 800mW for 8 seconds. (This is no h/w component, but we should know)
CPU 1.4 Ghz full load, 100% brightness - 4W+
CPU 1.4 Ghz average - 3.2W
CPU 1.6 Ghz full load - 5.9W (Forget Ocing to 1600mhz)
BLN - 200mW during suspend state opposed to deep sleep 8mW without BLN.
Wifi download - 1.51W
2G download - 1.598W
2G upload - 853mW
3G download - 1.603W
3G upload - 2.136W (Stay away from uploading your videos to youtube via 3G)
Q. "Sometimes the device says 'low battery' and switches itself off. But when i turn it on, there's 30% left. Why?"
A. Some heavy load conditions such as quickly reaching 1600mhz on full load, etc will cause the battery voltage to time below 3.3V and this is wrongly interpreted by the battery as empty.
Q. "What is 500 mhz core voltage bug?"
A. It's not a bug. It's a safety feature. What is it: When frequency is raised to 500 from a frequency below it, core voltage used for 500mhz is the core voltage of 800mhz. When frequency is dropped to 500 from a frequency above it, core voltage used is it's own voltage. So climb to 500 uses 800's volt and fall to 500 uses it's own volt. If you're UVing do it properly for 500 and 800. Now you know why.
SIYAH SPECIFIC TWEAKS (2.6 gingerbread versions)
Summary of all user configurable parameters in Siyah kernel. Some which were already listed in above posts, and some which i may have missed out. Let's have everything in one place, with examples.
1) CPU Frequency & Voltages
#Set frequency steps according to the number of steps in your kernel.
echo "1600 1400 1200 1000 800 500 200 100" > /sys/devices/system/cpu/cpu0/cpufreq/freq_table
#Set voltages for frequency steps. Changes possible at +/-25mV steps
echo "1425 1325 1275 1175 1075 975 950 950" > /sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table
#Sets global scaling min&max frequencies
echo "200000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo "1400000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
2) Scaling Governor & Smooth Scaling Parameters
#Set scaling governor, according to available governors in your kernel
echo ondemandx > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
#Smooth scaling parameters to control any governor jumping to higher frequency directly (other governor specific tweaks in first post).
echo "2" > /sys/devices/system/cpu/cpu0/cpufreq/smooth_target
echo "2" > /sys/devices/system/cpu/cpu0/cpufreq/smooth_offset
echo "2" > /sys/devices/system/cpu/cpu0/cpufreq/smooth_step
note: Smooth scaling is disabled for interactive based governors: Interactive, Interactivex and Lulzactive in Siyah. Idle loop based governors shouldn't like throttling.
When CPU is on a certain frequency (let's call this current_freq) and governor decides to jump CPU up to a higher frequency (let's call this target_level), Then
If target_level less than smooth_target, CPU jumps either to smooth_target+smooth_offset or current_freq-smooth_step, whichever is smaller.
Note that L0=1600 mhz, L1=1400 mhz, L2=1200 mhz, L3=1000 mhz, ..., L7=100 mhz
Example:
CPU current_freq is 500 (L5) and Ondemand governor decides to jump to 1400 (L1).
We have smooth_target = 2 = L2, smooth_offset = 2 and smooth_step = 2
smooth_target + smooth_offset = L2+2 = L4 = 800 mhz
current_freq - smooth_step = L5-2 = L3 = 1000 mhz
Since 800 mhz is smaller CPU jumps to 800 mhz first and then 1400 mhz.
3) GPU Clock, Voltages, Thresholds & Staycounts
#Set GPU clocks ( valid values are 400/(x*0.5) where x is an integer >= 2. So valid values will be 400/1,400/1.5,etc. Examples: 40 80 89 100 114 133 160 200 267 400 )
echo "160 200 267" > /sys/class/misc/gpu_clock_control/gpu_control
#Set GPU voltages (changes possible at +/-50mV ie at 50000 steps)
echo "900000 950000 1000000" > /sys/class/misc/gpu_voltage_control/gpu_control
#Set GPU Up and Down thresholds
echo "85% 55% 85% 50%" > /sys/class/misc/gpu_clock_control/gpu_control
Working of Thresholds:
Up threshold for Step 1 (160 mhz) = 85% [GPU scales up to 200 from 160 when load >= 85%]
Down Threshold for Step 2 (200 mhz) = 55% [GPU scales down to 160 from 200 when load < 55%]
Up Threshold for Step 2 (200 mhz) = 85% [GPU scales up to 267 from 200 when load >= 85%]
Down Threshold for Step 3 (267 mhz) = 50% [GPU scales down to 200 from 267 when load < 50%]
Step 1 will not have a Down Threshold & Step 3 will not have an Up Threshold since they don't have a step to scale-down to or scale-up to.
#Set GPU Staycounts. Staycount act as rate multiplier for GPU sampling intervals. Now you have complete control over GPU!
echo "1 1 1" > /sys/class/misc/gpu_control/gpu_staycount
4) Hot Plug Thresholds, Sampling Interval & Frequency
#Set second core kick-in threshold for screen-on state
echo "25" > /sys/module/pm_hotplug/parameters/loadl
echo "70" > /sys/module/pm_hotplug/parameters/loadh
#Set second core kick-in threshold for screen-off state [Forcing second core NOT to turn on during screen-off make it easier for first core to hit deep idle, hence power savings]
echo "35" > /sys/module/pm_hotplug/parameters/loadl_scroff
echo "100" > /sys/module/pm_hotplug/parameters/loadh_scroff
#Set hot plug sampling intervals for screen-on state
echo "200" > /sys/module/pm_hotplug/parameters/rate
echo "400" > /sys/module/pm_hotplug/parameters/rate_cpuon
rate is the sampling interval to check if second core should be kicked-in, if present load >= loadh.
rate_cpuon is the sampling ineterval to check if second core should be turned off (if already online), if present load < loadl
#Set hot plug sampling intervals for screen-off state
echo "800" > /sys/module/pm_hotplug/parameters/rate_scroff
rate_scroff is the sampling interval used in screen-off state to check if second core should be turned on, if current load >= loadh_scroff
If second core is already online, rate_cpuon is used as the sampling to check if second core should be turned off
For more info on Hotplug sampling and behavior, please see this post. Unit for these sampling intervals are jiffies. Since frequency of GS2 system timer = 200hz, divide jiffy value by 200 to convert into seconds.
#Set frequency below which second core will not be turned on, regardless of thresholds.
echo "500000" > /sys/module/pm_hotplug/parameters/freq_cpu1on
If CPU frequency <= 500 mhz, then second will not be turned on.
5) Deepsleep Levels
#Set deep sleep frequency & bus speed (L4=800 mhz and 0=400mhz bus speed)
echo "4" > /sys/devices/system/cpu/cpu0/cpufreq/deepsleep_cpulevel
echo "0" > /sys/devices/system/cpu/cpu0/cpufreq/deepsleep_buslevel
6) I/O Schedulers
#Set i/o scheduler
echo "sio" > /sys/block/mmcblk0/queue/scheduler
7) Bus Frequencies
#Set bus frequencies for highest-to-lowest CPU frequencies and enable static bus frequency scaling
echo "0 0 0 1 1 2 2 2" > /sys/devices/system/cpu/cpu0/cpufreq/busfreq_static
echo "enabled" > /sys/devices/system/cpu/cpu0/cpufreq/busfreq_static
Bus speeds: 0: 400 mhz | 1: 266 mhz | 2: 133 mhz
8) Schedule Multi Core & Idle Modes
#enable sched_mc
echo "1" > /sys/devices/system/cpu/sched_mc_power_savings
#enable AFTR
echo "3" > /sys/module/cpuidle/parameters/enable_mask
9) Touch Sensitivity Parameters
#touch sensitivity
echo "50" > /sys/devices/virtual/sec/sec_touchscreen/tsp_threshold
Possible values are between 40 to 80. Lower value = higher sensitivity.
Also use Tegrak's Touch Move app from market to further control touch sensitivity
10) Charge Current
#set AC, Misc & USB charge current
echo "750 650 450" > /sys/devices/virtual/misc/charge_current/charge_current
AC refers to wall charger current, MISC refers to car charger current , USB refers to usb charge current from pc. Do not set Ac & Misc more than 1000mA or Usb more than 450.
11) Brightness Curve Settings
#brightness settings
echo "30" > /sys/class/misc/brightness_curve/min_bl
echo "1" > /sys/class/misc/brightness_curve/min_gamma
echo "24" > /sys/class/misc/brightness_curve/max_gamma
We will have lowest brightness or zero gamma for brightness level read from sensor < 30. Above that, it is linearly mapped to [min_gamma:max_gamma] which is [1:24] here.
To increase the minimum brightness, decrease the min_bl.
Possible values for min_bl = 0 to 255 | min_gamma = 0 to 24 | max_gamma = 0 to 24
12) Switch Hotplug/DualCore/SingleCore
#Dynamic hotplug mode
echo "on" > /sys/devices/virtual/misc/second_core/hotplug_on
#Single core mode
echo "off" > /sys/devices/virtual/misc/second_core/hotplug_on
echo "off" > /sys/devices/virtual/misc/second_core/second_core_on
#Dual core mode
echo "off" > /sys/devices/virtual/misc/second_core/hotplug_on
echo "on" > /sys/devices/virtual/misc/second_core/second_core_on
The above script is a replacement for Tegrak's 2nd Core app, for those who don't like apps to set something on boot.