CPU & GPU Governors And I/O Schedulers performance Optimization

CPU & GPU Governors And I/O Schedulers performance Optimization - YU Yureka General

Thank to zhanjia & Andrux
I Search about Governors And I/O Schedulers in Google & XDA
Iam sharing this information to our yu Team members .because the Governors And I/O Schedulers is the main part of the Kernels .
Governors And I/O Schedulers
1.Performance
2.Battery
3.Gaming
4.Laging
5.Multitasking
CPU Governors
What is a CPU governor?
A CPU governor in Android controls how the CPU raises and lowers its frequency in response to the demands the user is placing on their device. Governors are especially important in smartphones and tablets because they have a large impact on the apparent fluidity of the interface and the battery life of the device over a charge.
NOTE: You cannot change your CPU governor unless your phone is rooted and you have a ROM or app that lets you make a change. Also, different kernels (the intermediary software between your phone's hardware and the operating system) offer different sets of governors.
Available CPU governors:
OnDemand
Conservative
Interactive
Performance
Powersave
Scary
Userspace
Smartass
SmartassV2
Smoothass
Brazilianwax
SavagedZen
Lagfree
MinMax
Interactivex
OnDemand
OnDemand
Available in most kernels, and the default governor in most kernels. When the CPU load reaches a certain point, OnDemand will rapidly scale the CPU up to meet the demand, then gradually scale the CPU down when it isn't needed.
Review
Brief says all. By a simple explantion, OnDemand scales up to the required frequency to undergo the action you are doing and rapidly scales down after use.
Conservative
It is similar to the OnDemand governor, but will scale the CPU up more gradually to better fit demand. Conservative governor provides a less responsive experience than OnDemand, but it does save batter
Review
Conservative is the opposite of Interactive; it will slowly ramp up the frequency, then quickly drops the frequency once the CPU is no longer under a certain usage.
Interactive
Available in latest kernels, it is the default scaling option in some stock kernels. Interactive governor is similar to the OnDemand governor with an even greater focus on responsiveness.
Review
Interactive is the opposite of Conservative; it quickly scales up to the maximum allowed frequency, then slowly drops the frequency once no longer in use.
Performance
Performance governer 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. After that it returns the CPU to extremely efficient low-power state.
Review
Good at gaming, Really good. Disadvantages are it may damage your phone if too much usage.
Powersave
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
Review
Set it to your desired minimum frequency and you won't have to look for your charger for once in a while.
Scary
A new governor wrote based on Conservative with some Smartass features, it scales accordingly to Conservative's way. It will start from the bottom. 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.
Review
Hmm.. Overall I don't see any difference. After I understand its main objective. I was very curious and decided to use it again. Results are the same.. No difference. Report to me if anyone has tested this.
Userspace
Userspace is not a governor pre-set, but instead allows for non-kernel daemons or apps with root permissions to control the frequency. Commonly seen as a redundant and not useful since SetCPU and NoFrills exist.
Review
Highly not recommended for use.
Smartass
It is based on the concept of the Interactive governor.
Smartass is a complete rewrite of the code of Interactive. Performance is on par with the “old” minmax and Smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Review
Smartass is rather the governer that will save your battery and make use of your processor for daily use. Like the brief explantion said " Smartass will spend much more time on lower frequencies." So logically you don't need for sleep profiles anymore.
SmartassV2
Theoretically a merge of the best properties of Interactive and OnDemand; automatically reduces the maximum CPU frequency when phone is idle or asleep, and attempts to balance performance with efficiency by focusing on an "ideal" frequency.
Review
This is a much favourite to everybody. I believe almost everyone here is using SmartassV2. Yes, it is better than Smartass because of its speed no scaling frequencies from min to max at a short period of time.
Smoothass
A much more aggressive version of Smartass that is very quick to ramp up and down, and keeps the idle/asleep maximum frequency even lower.
Review
In my personal experience, this is really useful for daily use. And yes, I'm using it all the time. It may decrease your battery life. I saw it OC itself to 1.4 gHz when I set it to 1.2. Good use. Recommended.
Brazilianwax
Similar to SmartassV2. More aggressive scaling, so more performance, but less battery.
Review
Based on SmartassV2. But its advantage is a much more performance wise governor.
SavagedZen
Another SmartassV2 based governor. Achieves good balance between performance & battery as compared to Brazilianwax.
Review
Not much difference compared to SmartassV2. But it is a optimized version of it.
Lagfree
Again, similar to Smartass but based on Conservative rather than Interactive, instantly jumps to a certain CPU frequency after the device wakes, then operates similar to Conservative. However, it has been noted as being very slow when down-scaling, taking up to a second to switch frequencies.
Review
Used it before. Like the name of the governor, I didn't experience any lag whatsoever. Another governor based on performance, but not battery efficient.
MinMax
MinMax is just a normal governor. No scaling intermediate frequency scaling is used.
Review
Well.. it's too normal that I can't really say anything about it..
Interactivex
InteractiveX governor is based heavily on the Interactive governor, enhanced with tuned timer parameters to optimize the balance of battery vs performance. 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.
Review
A better understanding from the brief to you users, this is an Interactive governor with a wake profile. More battery friendly than Interactive.
GPU Governors
Ondemand
Much like the CPU governor, Ondemand will ramp up the frequency when a load is detected. A good balance between performance and battery savings.*
MSM-Adreno
The default GPU governor used by qualcomm for their adreno GPUs. It is more performance orientated than ondemand therefore it gives better performance in games but less battery life.*
Performance
As the name suggests, this keeps your GPU running at the max frequency. This is a governor if you want the best possible experience in games but you don't care about your battery life.*
Powersave
Like the CPU governor, this keeps your GPU running at the lowest possible frequency. Best battery life
I/O Schedulers
What is an I/O Scheduler:
*Input/output (I/O) scheduling is a term used to describe the method computer operating systems decide the order that block I/O operations will be submitted to storage volumes. I/O Scheduling is sometimes called 'disk scheduling'.
I/O schedulers can have many purposes depending on the goal of the I/O scheduler, some common goals
To minimise time wasted by hard disk seeks.
To prioritise a certain processes' I/O requests.
To give a share of the disk bandwidth to each running process.
To guarantee that certain requests will be issued before a particular deadline.
Available*I/O schedulers
CFQ *
Deadline *
VR *
Noop*
Anticipatory
BFQ
FIOPS
SIO (Simple)
Row
ZEN
Sioplus
FIFO*
Tripndroid
Anticipatory:*
Two important things here are indicative of that event:*
- Looking on the flash drive is very slow from boot
- Write operations while at any time are processed, however, be read operations preferred, ie, this scheduler returns the read operations a higher priority than the write operations.*
Benefits:*
- Requests of read accesses are never treated secondarily, that has equally good reading performance on flash drives like noop.
Disadvantages:*
- Requests from process operations are not always available*
- Reduced write performance on high-performance hard drives*
- Not very common in most kernels
CFQ:*
The CFQ - Completely Fair Queuing - similar to the Dead Line maintains a scalable continuous Process-I/O, the available I / O bandwidth is *fairly and evenly shared to all I / O requests to distribute. It creates a statistics between blocks and processes. With these statistics it can "guess" when the next block is requested by what process, each process queue contains requests of synchronous processes, which in turn is dependent upon the priority of the original process. There the V2 version has some fixes, such as I / O request improvements, hunger fixes , and some small search backward integrated to improve responsiveness.This is the default IO scheduler for Samsung smartphones.*
Benefits:*
- Has a well balanced I / O performance
- Excellent on multiprocessor systems*
- Easiest to tune.
- Best performance of the database after the deadline*
- Is the default IO scheduler for most mobile phones today
- Good for multitasking*
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) can sometimes be very high because the number of competing with each other process tasks*
Deadline:*
This scheduler has the goal of reducing I / O wait time of a process of inquiry. This is done using the block numbers of the data on the drive. This also blocks an outlying block numbers are processed, each request receives a maximum delivery time. This is in addition to the Governor BFQ, it is very popular and is in many well known kernels.*
Benefits:*
- It is nearly a real-time scheduler.*
- Excels in reducing latency of any given single I/O*
- Best scheduler for database access and queries.*
- Does quite well in benchmarks, most likely the best
- Like noop, a good scheduler for solid state/flash drives
- Good for light and medium multitasking workloads
Disadvantages:*
- If the phone is overloaded, crashing or unexpected closure of processes can occur*
- Bad battery life if doing a lot of multitasking
ROW:
ROW stands for "READ Over WRITE"which is the main requests dispatch policy of this algorithm. The ROW IO scheduler was developed with the mobile devices needs in mind. In mobile devices we favor user experience upon everything else,thus we want to give READ IO requests as much priority as possible. In mobile devices we won't have as much parallel threads as on desktops. Usually it's a single thread or at most 2 simultaneous working threads for read & write. Favoring READ requests over WRITEs decreases the READ latency greatly.
The main idea of the ROW scheduling policy is: If there are READ requests in pipe - dispatch them but don't starve the WRITE requests too much. Bellow you'll find a small comparison of ROW to existing schedulers. The test that was run for these measurements is parallel read and write.
Benefits:
- Faster UI navigation and better overall phone experience
- Faster boot times and app launch times*
- Possibly better battery life
- Sometimes used by default for custom roms and custom kernels
Disadvantages:
- Slower write speeds
- Some intensive applications like games could slow down your phone
SIO (Simple):*
It aims to achieve with minimal effort at a low latency I / O requests. Not a priority to put in queue, instead simply merge the requests. This scheduler is a mix between the noop and deadline. There is no conversion or sorting of requests.*
Benefits:*
- It is simple and stable.
- Reliable IO scheduler
- Minimized starvation for inquiries
- Good battery life
Disadvantages:*
- Slow random write speeds on flash drives as opposed to other schedulers.
- Sequential read speeds on flash drives, not as good*
Noop:*
The noop scheduler is the simplest of them. It is best suited for storage devices that are not subject to mechanical movements, such as our flash drives in our phones use to access the data. The advantage is that flash drives do not require rearrangement of the I / O requests, unlike normal hard drives. the data that come first are written first. It's basically not a real scheduler, as it leaves the scheduling of the hardware.*
Benefits:*
- Serves I/O requests with least number of cpu cycles.
- Is suitable for flash drives because there is no search errors*
- Good data throughput on db systems
Disadvantages:*
- Reducing the number of CPU cycles corresponds to a simultaneous decline in performance*
- Not very good at multitasking
VR:*
Unlike other scheduling software, synchronous and asynchronous requests are not handled separately, but it will impose a fair and balanced within this deadline requests, that the next request to be served is a function of distance from the last request. It is a very good scheduler with elements of the deadline scheduler. It is the best for MTD Android devices. Vr can make the most of the benchmark points, but it is also an unstable scheduler. *Sometimes the scores fluctuate below the average, sometimes it fluctuates above the average.*
Benefits:
- Generally excels in random writes.*
Disadvantages:*
- Performance variability can lead to different results (Only performs well sometimes)
- Very often unstable and unreliable
BFQ:*
Instead requests divided into time segments as the CFQ has, on the BFQ budget. The flash drive will be granted an active process until it has exhausted its budget (number of sectors on the flash drive). The awards BFQ high budget does not read tasks. BFQ has received many updates to the scheduler and the performance is consistently improving.*
Benefits:*
- Has a very good USB data transfer rate.*
- The best scheduler for playback of HD video recording and video streaming (due to less jitter than CFQ Scheduler, and others)*
- Regarded as a very precise working Scheduler*
- Delivers 30% more throughput than CFQ
- Being constantly updated
- Good for multitasking*
Disadvantages:*
- Not the best scheduler for benchmarks*
- Higher budgets that were allocated to a process that can affect the interactivity and bring with it increased latency.*
- Slower UI navigation
- Slower boot times
ZEN:
Based on the VR Scheduler. It's an FCFS (First come, first serve) based algorithm. It's not strictly FIFO. It does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ons. Other than that, pretty much the same as no-op.
Benefits:
- Well rounded IO Scheduler
- Very efficient IO Scheduler
- More stable than VR, mainly because it doesn't really behave like VR.*
Disadvantages:
- Not found in all kernels
Sioplus:
Based on the original Sio scheduler with improvements. Functionality for specifying the starvation of async reads against sync reads; starved write requests counter only counts when there actually are write requests in the queue; fixed a bug).*
Benefits:
- Better read and write speeds than previous SIO scheduler
- Good battery life*
Disadvantages:
- The same as SIO scheduler
- Not found in all kernels
FIOPS:*
This new I/O scheduler is designed around the following assumptions about Flash-based storage devices: no I/O seek time, read and write I/O cost is usually different from rotating media, time to make a request depends upon the request size, and high through-put and higher IOPS with low-latency.
Benefits:
- Achieves high read and write speeds in benchmarks
- Good battery life
Disadvantages:
- Not very common in most kernels
FIFO (First in First Out):
A relatively simple io schedulers that does what has been described. It is also known as FCFS (First come first serve) but this really isn't true. It does basic sorting; sorting the processes according to the appropriate order and nothing else. In other words, it is quite similar to noop.*
Benefits:
- Serves I/O requests with least number of cpu cycles.
- Is suitable for flash drives because there is no search errors
- Good data throughput on db systems
Disadvantages:
- Reducing the number of CPU cycles corresponds to a simultaneous decline in performance*
- Not very good at multitasking
Tripndroid
A new I/O scheduler based on noop, deadline and vr and meant to have minimal overhead. Made by TripNRaVeR
Recommended IO schedulers:
For everyday usage:
- SIO (My personal favourite)
- NOOP
- CFQ (Third choice)
- Deadline (Forth choice)
- ROW (My second choice)
- ZEN
For battery life:
- SIO (First choice)
- FIOPS*
- NOOP (Second choice)
- ROW (Third choice)
- FIFO
For gaming:*
- Deadline (First choice)
- CFQ (Second choice)*
- ROW (Third choice)
For performance(Benchmarking):
- VR
- SIO (Third Choice)
- Deadline (Second choice)
- FIOPS (First choice)*
For multitasking:*
- BFQ (Third choice)
- Deadline (Second choice)
- CFQ (First choice)
IO Scheduler Comparison
Overall performance:
Best<------------------------------------------------------------------------->Worst
FIOPS> Noop > ZEN >SIOplus > SIO > ROW > Tripndroid > VR > Deadline > BFQ > CFQ
Multitasking performance:
Less Apps<------------------------------------------------------------>Many Apps
Noop < FIOPS < SIO < *SIOplus < ROW < Tripndroid < ZEN < Deadline < VR < *CFQ < BFQ
Battery life:
Best<-------------------------------------------------------------------------> Worst
Noop > FIOPS > SIOplus > SIO > ROW> *ZEN > Tripndroid > Deadline > VR > CFQ > BFQ

ela1103 said:
Thank to zhanjia & Andrux
I Search about Governors And I/O Schedulers in Google & XDA
Iam sharing this information to our yu Team members .because the Governors And I/O Schedulers is the main part of the Kernels .
Governors And I/O Schedulers
1.Performance
2.Battery
3.Gaming
4.Laging
5.Multitasking 

Click to expand...
Click to collapse
Thanks, very informative!
schubeir

Thanks man for the info, i knew few of them and now all:good::good::good:

No credits??? I'm sure those descriptions for I/O schedulers came from me

Thanks been looking for something like this
Sent from my Pixel XL using Tapatalk

Related

[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..

[KERNEL][RC12] Rm Kernel | Overclock 1Ghz | 2.6.32.59 |

RM KERNEL
Just a statement regarding kernel source: The Kernel Source is of course covered under GPL version 2. Free software does NOT mean no work or time was spent working on it. I have donated a large sum of my free time to hack this kernel. If you use my modified kernel source in parts or in its entirety, I kindly ask you mention its origins and to send me a github pull request or PM whenever you find bugs or think you can help improve my kernel hack further. This way the entire community will truly benefit from the spirit of open source. Thank you
Rm -Kernel For Optimus me (pecan)
What is a Kernel?
The Kernel is the Foundation in which everything else builds upon in any software system.
NOTICE: This Kernel Only COMPATIBLE with Mine and Pax0r CM7.2 AND there Based Roms cooked roms.
Don't try to flash on stock roms or older cm7 or omgb/omfgb or cm9 roms becuase is not COMPATIBLE now with this roms
Please DO NOT use any task killers, they DO NOT improve performance nor battery life. They INTERFERE with your phone's stability (more crashes) and App compatibilities (Forced Close).
IMPORTANT NOTES
Click to expand...
Click to collapse
No Guarantees! If it kills your grandmother or your device ,I'm not responsible if
you brick your device by heavy OC, flashing, voiding your warranty,or any other pain or suffering you may feel as result of using this kernel!!! ...
Using using very high frequencies (OVER 806Mhz) is dangerous for your phone.
if you oc your phone OVER 806MHZ on my kernel then no support provided
(If you download, please hit Thanks below my post! Thank you!)
NOTE: after wipe battery,system recreate the battery stats, forcing the battery to lose its capacity, i advice you recalibrate the battery after doing that.
KNOW BUGS
Click to expand...
Click to collapse
Not All CHIPS ARE CREATED EQUAL
Download:
No Guarantees! If it kills your grandmother or your device, I am NOT responsible! If you understand this:
(If you download, please hit Thanks below my post! Thank you!)
*RC12* [STABLE] Click me
Old Downloads: Click Me
INSTALL
Click to expand...
Click to collapse
How to Flash/Install the Kernel
Root Your LG Optimus Me , Then Install Custom Recovery
Download Newer Version Of Rm 32 Kernel From Topic
Copy Zip File to Sd Card
Reboot Your Phone To Recovery Mode
Wipe Cache,Wipe Dalvik Cache And Battery
Now Install Kernel And Enjoy:laugh:
Note: After FLASHING, the first reboot may take longer than usual, please be patient... After the first reboot, it may lag during initial load (let everything finish loading). Once everything is loaded and phone is ready for use, reboot the phone a 2nd time and the lag will be gone and everything should be silky smooth...
SOURCE
Click to expand...
Click to collapse
I respect the GPL (the license covering the Linux kernel), so all the up-to-date source code for this kernel is avaiable on my github:https://github.com/kerneldevs/RM-32-kernel-pecan
My kernel is, in turn, based on the publicly-avaiable froyo kernel source from LG. You're free to fork, modify, and re-release the code as your own, but you must provide the source code for your resulting work. Doing so ensures you honor the terms of the license, but you're also giving back to the community. Basically, don't be a ****.
THANKS TO
Click to expand...
Click to collapse
drapalyuk- initial setup of pecan kernel source and for biggest work for this device
pax0r- 2nd setup of pecan kernel source and also for biggest work for this device
codeaurora forum - source and patches
Mik9-SOME PATCHES THAT I USED IN MY KERNEL
Fserve-for sharing his kernel source from his source i got some idea for this kernel
Andy572-used some patches
Tasssadar-for his kernel source based on mik9 kernel
Roqu3-for his kernel source for p350, i got a 1 fix from his source
Cyanogenmod - for sharing their kernel source code, used some 1 patches from cm kernel source.
burstlam- got i nice idea about kgsl from his zte blade source
SUPPORT
Click to expand...
Click to collapse
IF YOU LIKE MY WORK YOU CAN USE DONATE BUTTON TO SUPPORT MY WORK OR YOU CAN PRESS THANKS BUTTON TO SHOW YOUR SUPPORT .
SOME INFO OF SOME KERNEL THINGS
Click to expand...
Click to collapse
CleanCache(via ZCache backend)
ZCACHE is a compressed cache similar to ZRAM but the similarity ends there. ZCache is meant to provide as many "cleancache" pages (non-dirty or untouched "virgin" memory) to apps that request for new memory. CleanCache is very easy to allocate and no additional penalty are required to hand them out, so having more CleanCache pages will improve performance. Under heavy memory pressure, often times the kernel will NOT have enough CleanCache pages, so the kernel has to do EXTRA work to reclaim dirty cache pages and clean them for the new apps that's requesting for them. The described process creates a performance hit for the kernel and the app, so the idea is to use compression to create more CleanCache pages available for use. Of course there's a penalty to pay for using compression, but the trade-off between compression penalty and the penalty for reclaiming dirty cache pages and allocating them after cleaning is smaller for compression, so in the end, CleanCache should add more performance.
USER experience BENCHMARK ARE MOVED TO THIS LINK
MORE
Click to expand...
Click to collapse
WANT FAST NEWS ABOUT MY WORK? THEN JOIN MY FACEBOOK GROUP : https://www.facebook.com/groups/OADPROM/
If you want to donate some bucks for the work that i'm doing for LG Optimus Me, go to the my username and hit the 'donate to me' button. Otherwise I would be grateful if you can click the "Thanks" button on the bottom right of this post.
THANKS TO ALL

CHANGELOG
CHANGELOG
OLD CHANGELOG OF RM VERSIONS ARE MOVED CLICK HERE TO SEE OLD CHANGELOG

09-07-2012 RC7 http://www.mediafire.com/?sxh8wt2u1b9493t
serial: msm_serial_hs_lite: Use pm_runtime to indicate device state
mm: Make memory hotplug aware of memmap holes
mfd: Use min_uV for voltage setting
msm: timer: read clocksource from global clock variable.
msm_bus: APIs for MSM bus scaling.
arm: add ARM-specific memory low-power support
msm: rmnet: Add tailroom for sk buffer to be transmitted
msm: Add Timpani Sound Device Profile
14-07-2012 RC8 http://www.mediafire.com/?ld6lrnbxrghdewb
msm: camera: Support for Dynamic Camera Logging
add backlight driver in st1.5
msm: mfd: Use debugfs interface to allow timpani codec register access
spi_qsd: Modify timeout mechanism to check SPI state valid bit.
Define and process new type of memory tag (ATAG_MEM_RESERVED)
msm: Add XO aggregation and voting API stubs
Add tpmd_dev from the tpm-emulator source to the kernel
arm: common: CP register access tool for Read/Write to CP registers
serial: msm_serial_hs: Use runtime PM for HSUART power state transitions
21-07-2012 RC10 http://www.mediafire.com/?97g5pqr71xuuj9h
rcu: "Tiny RCU", The Bloatwatch Edition
fs: simple fsync race fix
Increase readahead value
acpuclock tweaks
axi oc back
add the Stochastic Fair Blue (SFB) network scheduler - from zachariasmaladroit
sched: Fix over-scheduling bug [author andy572]
block: introduce the BFQ I/O scheduler
block: Fix atomic functions in bfq & update bfq to v2
msm_kgsl: Fix corner cases while adding ringbuffer commands
msm_kgsl: Take the driver lock after waiting for wakeup to complete
msm_kgsl: enable writecombine
msm: 7x27: Update the SDC2 GPIO disable configs
msm: 7x27: mmc: Add platform data for dummy CMD52
usb: msm_gadget: Check both USB state and VBUS during initialization
and some more small changes, check github repo for that
25-07-2012 RC11 http://www.mediafire.com/?3l6fi81l4no860t
mmc: msm_sdcc: Enhance the current mechanism of simulating PIO interrupt
msm: socinfo: move sysdev creation outside init
fs: mark_inode_dirty barrier fix
vmalloc: remove redundant unlikely()
mm: remove likely() from mapping_unevictable()
mm: remove likely() from grab_cache_page_write_begin()
writeback: avoid unnecessary determine_dirtyable_memory call
brk: fix min_brk lower bound computation for COMPAT_BRK
mm/dmapool.c: take lock only once in dma_pool_free()
mm/dmapool.c: use TASK_UNINTERRUPTIBLE in dma_pool_alloc()
fs/select.c: fix information leak to userspace
PM: Lock PM device list mutex in show_dev_hash()
PM: Prototype the pm_generic_ operations
mmc: Attribute the IO wait time properly in mmc_wait_for_req().
Wifi fix
Last version of RM Kernel
09-08-2012 RC12 http://www.mediafire.com/?j6e21kzhdhw3x3v
revert axi oc back
revert update acpuclock
netlink: Make nlmsg_find_attr take a const nlmsghdr*.
netfilter/nf_conntrack_netlink: fix ctnetlink_parse_tuple()
net/ethernet/eth: remove deprecated: print_mac() [Marin Mitov]
ipv4/netfilter/nf_nat_standalone: workaround to make -Wswitch happy
ipv6/xfrm6_tunnel: missing middle operand
fs/ext4/move_extent: fix uninitialized start_ext.ee_block [tytso]
cpufreq: fix memory leak in cpufreq_add_dev [Xiaotian Feng]
cgroup: introduce cancel_attach() [Daisuke Nishimura]
block: rescan partitions on invalidated devices on -ENOMEDIA too
block: add proper state guards to __elv_next_request
mtd: mtdconcat: fix NAND OOB write

HERE THE INFO OF ANDROID GOV
ALL CREDITS GO TO Deedii
Android CPU governors explained
1: OnDemand
2: OndemandX
3: Performance
4: Powersave
5: Conservative
6: Userspace
7: Min Max
8: Interactive
9: InteractiveX
10: Smartass
11: SmartassV2
12: Scary
13: Lagfree
14: Smoothass
15: Brazilianwax
16: SavagedZen
17: Lazy
18: Lionheart
19: LionheartX
20: Intellidemand
21: Hotplug
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 KERNEL15: Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery16: SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.17: Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.18: Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source.
The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.19: LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.20: Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors)
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
21: Hotplug Governor:
The Hotplug governor performs very similarly to the OnDemand governor, with the added benefit of being more precise about how it steps down through the kernel's frequency table as the governor measures the user's CPU load. However, the Hotplug governor's defining feature is its ability to turn unused CPU cores off during periods of low CPU utilization. This is known as "hotplugging."
Obviously, this governor is only available on multi-core devices.
=============================================
ALL CREDITS GO TO THE USERS OF XDA WHO CREATED DIFF THREADS ABOUT I/O, THIS I/O INFO FROM ALL THREADS
ALL INFO ABOUT I/O
Click to expand...
Click to collapse
I/O:- short form of Input & OutputI/O Scheduler:- Input/output (I/O) scheduling is a term used to describe the method computer operating systems decide the order that block I/O operations will be submitted to storage volumes. I/O Scheduling is sometimes called 'disk scheduling'.
I/O schedulers can have many purposes depending on the goal of the I/O scheduler, some common goals are:
- To minimize time wasted by hard disk seeks.
- To prioritize a certain processes' I/O requests.
- To give a share of the disk bandwidth to each running process.
- To guarantee that certain requests will be issued before a particular deadline.Info on I/O Scheduler
SIO:- cheduler is based on the deadline scheduler but it's more like a mix between no-op and deadline.In other words, SIO is like a lighter version of deadline but it doesn't do any kind of sorting, so it's aimed mainly for random-access devices (like SSD hard disks) where request sorting is no needed (as any sector can be accesed in a constant time, regardless of its physical location).NOOP:- The NOOP scheduler inserts all incoming I/O requests into a simple, unordered FIFO queue and implements request merging.
The scheduler assumes I/O performance optimization will be handled at some other layer of the I/O hierarchy; e.g., at the block device; by an intelligent HBA such as a Serial Attached SCSI (SAS) RAID controller or by an externally attached controller such as a storage subsystem accessed through a switched Storage Area Network.ANTICIPATORY:- Anticipatory scheduling is an algorithm for scheduling hard disk input/output.
It seeks to increase the efficiency of disk utilization by "anticipating" synchronous read operations.
ADAPTIVE ANTICIPATORY SCHEDULER:- For the anticipatory scheduler, we scale up the anticipation timeout (antic expire) using the latency scaling factor over time. When the virtual disk latencies are low a small scaling of the timeout is sucient to prevent deceptive idleness, whereas when the latencies are high a larger scaling of the timeout value may be required to achieve the same. Note that such dynamic setting of the timeout value ensures that we attain a good trade-o between throughput (lost due to idling) and deceptive idleness mitigation. Setting a high value for the scaling factor (increasing idling time) only happens when the disk service latencies themselves are higher. This may not necessarily cause a signicant loss in throughput, because submitting a request from another process instead of idling is not going to improve throughput if the virtual disk itself does not get any faster than it is at the current period. A higher anticipation timeout might also be capable of absorbing process scheduling eects inside the VM. The results for the adaptive anticipatory scheduler are shown in Figure 2. The read time with our modied implementation (third bar in the dierent scheduler combi- nations) shows that it is possible to mitigate the eects of deceptive idleness by adapting the timeout. An interesting related observation is that the level to which the improve- ment is possible varies for dierent Domain-0 schedulers; noop - 39%, anticipatory - 67% and cfq - 36%. This again points to the fact that the I/O scheduler used in Domain-0 is important for the VM's ability in enforcing I/O scheduling guarantees. Dierent Domain-0 I/O schedulers likely have a dierent service latency footprint inside the VMs, contributing to dierent levels of improvement.CFQ:-CFQ, also known as "Completely Fair Queuing", is an I/O scheduler for the
Linux kernel which was written in 2003 by Jens Axboe.
CFQ works by placing synchronous requests submitted by processes into a number of per-process queues and then allocating timeslices for each of the queues to access the disk. The length of the time slice and the number of requests a queue is allowed to submit depends on the IO priority of the given process. Asynchronous requests for all processes are batched together in fewer queues, one per priority.DEADLINE:- The goal of the Deadline scheduler is to attempt to guarantee a start service time for a request. It does that by imposing a deadline on all I/O operations to prevent starvation of requests. It also maintains two deadline queues, in addition to the sorted queues (both read and write). Deadline queues are basically sorted by their deadline (the expiration time), while the sorted queues are sorted by the sector number.
Before serving the next request, the Deadline scheduler decides which queue to use. Read queues are given a higher priority, because processes usually block on read operations. Next, the Deadline scheduler checks if the first request in the deadline queue has expired. Otherwise, the scheduler serves a batch of requests from the sorted queue. In both cases, the scheduler also serves a batch of requests following the chosen request in the sorted queue.V(R):- The next request is decided based on its distance from the last request, with a multiplicative penalty of `rev_penalty' applied for reversing the head direction. A rev_penalty of 1 means SSTF behaviour. As this variable is increased, the algorithm approaches pure SCAN. Setting rev_penalty to 0 forces SCAN.
SIMPLE:- Does not do any kind of sorting, as it is aimed foraleatory access devices, but it does some basic merging. We try to keep minimum overhead to achieve low latency.BFQ:- BFQ is a proportional share disk scheduling algorithm based on the slice-by-slice service scheme of CFQ. But BFQ assigns budgets, measured in number of sectors, to tasks instead of time slices. The disk is not granted to the active task for a given time slice, but until it has exahusted its assigned budget. This change from the time to the service domain allows BFQ to distribute the disk bandwidth among tasks as desired, without any distortion due to ZBR, workload fluctuations or other factors. BFQ uses an ad hoc internal scheduler, called B-WF2Q+, to schedule tasks according to their budgets. Thanks to this accurate scheduler, BFQ can afford to assign high budgets to disk-bound non-seeky tasks (to boost the throughput), and yet guarantee low latencies to interactive and soft real-time applications.

cips gokhle said:
Welcome to my RM kernel thread
About
THIS KERNEL IS BASED ON PECAN KERNEL .
RM KERNEL IS a very optimized kernel for 2.3 ROMS (in 2.2 you will face problem). i made this kernel to push performance as hard as it can.
Features & Changelog
Installation
Reboot intro recovery
Flash the latest kernel
Reboot
Enjoy
NOTE: THIS KERNEL IS ONLY FOR MY CM NIGHTLY AND PAX0R CM7.2 ROMS. DON'T FLASH ON VIVEK CM7.2,OMFGB,OMGB AND CM7.1 AND 2.2 ROMS. (FOR CM7.1,OMFGB,OMGB AND VIVEK CM7.2 I'M MAKING ANOTHER VERSION)
Downloads
V1000: http://www.mediafire.com/?aw3t3jrz99151zy
Click to expand...
Click to collapse
Goodjob bro
I will try

cooler1182 said:
Goodjob bro
I will try
Click to expand...
Click to collapse
i'm waiting for your review

I not absolutely well understand what changes installation of this kernel will make.

zizka said:
I not absolutely well understand what changes installation of this kernel will make.
Click to expand...
Click to collapse
this kernel will improve your touch screen and improve your phone performance
but about touch screen it's best work with my nightly

I made backup of data and established your kernel. Phone surprisingly quickly is loaded. Programs on a memory card need time that they could be used. Touch works also well as before. Changes didn't see. There can be I blind put on Nightly9

zizka said:
I made backup of data and established your kernel. Phone surprisingly quickly is loaded. Programs on a memory card need time that they could be used. Touch works also well as before. Changes didn't see. There can be I blind put on Nightly9
Click to expand...
Click to collapse
hmm in fb group 1 tested this and it's work for him any way in nightly 10 have update version of this kernel 2.6.32.59

now, I can mount the SD-ext with link2sd. In Fruit Ninja you feel the difference, is faster and more responsive than ever

I dont see changes. Multitouch have bug axis inversion and performance no changes for me. Thxs!

THIS KERNEL IS NOW OBSOLETE, DON'T USE IT.
newest and stable kernel releases are now integrated into my version of CYANOGENMOD 7.2

cn u just upload to some other site?? mediafire isnt working! m not able to download

ethan1234 said:
cn u just upload to some other site?? mediafire isnt working! m not able to download
Click to expand...
Click to collapse
SEE THIS
http://forum.xda-developers.com/showpost.php?p=25967572&postcount=12

Guys project restarted take test guys

this kernel is better than .35?

agen47 said:
this kernel is better than .35?
Click to expand...
Click to collapse
yes it's better it have new things that 1st time for p350

i tried both versions of this kernel and both worked well cant really tell the performance difference in vsync off, maybe in some heavy games a few more fps. atm im using vsync on on kang2 running at 806mhz no kernel panic yet

agen47 said:
i tried both versions of this kernel and both worked well cant really tell the performance difference in vsync off, maybe in some heavy games a few more fps. atm im using vsync on on kang2 running at 806mhz no kernel panic yet
Click to expand...
Click to collapse
you will be only feel diff in games on vsync off

here's the basic description about vsync:
vsync off = great for benchmarks but crap in real life.
vsync on = crap for benchmarks great in real life.
Say your screen refreshes at 60Hz - Vsync on will attempt to display 30fps to avoid tearing. 30 goes into 60 twice evenly... get it?
Vsync off will display as many fps as possible. So rather than holding back and displaying 30fps it will allow 35fps. This will cause tearing because 35 does not go into 60 evenly.
It's the same affect you get when playing video games on a PC.

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.

{KERNEL}[JB][TWRP+CWM]Trinity Ultimate Kernel V2.2 - FiXed - UltraKernelX - <OTA> -XT

{KERNEL}[JB][TWRP+CWM]Trinity Ultimate Kernel V2.2 - FiXed - UltraKernelX - <OTA> -XT
~ Trinity Ultimate Kernel RipJawsZ Edition V2.2A TUX ~
{
"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 -
I NOW Present you the Best Of the Best Trinity Ultimate Vengeance Kernel V2.2 TUX, I Assure you the Best Performance and Battery Life, In Your Phones Xperia S / SL, This is Based On the Official JB Sourced.. And This Kernel Have More than 12+ Optimization and Tweaks.. To Have the Best I/O And The Best Score in your Benchmark! For Now Ive Use LINARO or Code Sourcery
DOWNLOADS - STABLE
Main Server Download / Website - 2.2 =
Standard Scores - More Battery - Version
1.7Ghz Capped Freq :http://bit.ly/12QYz6f
1.9Ghz Capped Freq :http://bit.ly/1c9xm5y
High Scores - Less Battery and More Battery - Version
1.7Ghz Capped Freq : Soon!
1.9Ghz Capped Freq : Soon!
Donate To Me TrinityHaxxorX : >> TrinityHaxxorX <<
" @mericon and @TrinityHaxxorX , We Don't Allow Other Devs to Use the TWRP That We Create, Its A Unique Feature in Our Kernel, Respect Use We Respect You "

" NOTE AFTER FLASHING JUST REBOOT AND ITS OKAY! "
Press thanks when you download, just once, if every person that have downloaded TVRx ROMs since the start had pressed the thanks button I would have more than 10000000 Thanks , and if every person that have downloaded TVRx ROM since the start, had donated well you know the sentence, I would be really rich , so please :
KERNEL SECTION DONORS
Thomas Rush - 10$
AnTuTu: OC To 1.7Ghz Both | Sometimes You Get Low Score Because Of Dif. Governor and Scheduler
V1 = Trinity - 9621 V2 = 10K+
Doom - 9286
Other Kernel : N/A
Kernel Source : http://bit.ly/10Y0uF3
Proof or Vouch -
almost 22 min on battery didnt lost 1% coooool BEST WITH ALL JB ROMS! Specially My ROM! - By @sparxx4
Hello Trinity! Im just posting to say thank you for you're work. Im using your kernel in combination with ur rom. Very very good work. Kernel is very stable imo and the rom is very snappy. Buttersmooth experience, increased battery life and very good benchmark/games performance. Thumbs up @Michielwashier
Dear Trinity, I think this version is the best kernel that you've created!
Works very good for me Thank you And it's seem dancedance performance is very good in this version Did you tweaked it? It's really dancing mate Wheatley is nice too Both is my favorite And I can confirm cpu1 jumping freq is gone @LLy_BosHi
Changelog -
V2.1A | 2.2B ( Re-Fixed and Re-Vamped Version )
Added CRT Hack
Kernel 3.4.20 Thanks To @Forzaferrarileo For Commit
Added New TCP Congestion Control Thanks To @Forzaferrarileo For Commit
Weak WiFi Tweak
Switched To Forza. OC Table Thanks To @Forzaferrarileo For Commit
Simple KGSL
Re-Enabled CONFIG_TRINITY_CHANGE ~ Easy 1.7 To 2.0 Ghz
eMMC in Sleep mode before suspend
Increased DMA size To 1 * 16
Enable AFTR Feature
Added Frandom
Added SLQB Memory Allocator
Revamped VMDirty
Revamped VM
Revamped PageWriteBack
Fix Benchmark Score Output
Initial 2 BootSplash - Waiting For @mericon Bootsplash
Enabled Group Scheduling
Reverted 30 Touch Gestures
Added Conservative Governor
Added CPU1 Fix V1.3 - Revamped
Added New Mpdecision - Revamped
Added Stable 2.0Ghz OC
Added Stable Voltage
Increased ReadAHead
Added CPU1 and CPU0 Info
Added Workaround To Link CPU0 and CPU1
Added Initial File for 1.7Ghz and 2.0Ghz - CONFIG_TRINITY_CHANGER=y For 2.0 and =N for 1.7
Revamped Fastcharge
Revamped I/O
Added -O3 Optimization
Increased I/O Float
Added NTFS Support Again
Removed Old Mpdecision Replaced with CPU1 Work
Frandom V1.1
Added Initial Files For ZRAM 1.1
Added Initial Files For Snappy Google Compression
Stat For CPU1 Mpdecision Should Update From Time To Time
V2.0 - Uploaded
Using Newest TWRP
Re-Enabled Color Control
FastCharge V1.3
Smooth Cpufreq Scrolling - From galaxy s2
Re-Enabled MSM_Thermal_Management 8x60 | 8960
GPU OC (?) - What is "(?)" In A Possibility That I Won't Be Added
Added SMARTMAX
Added BADASS
Added Wheatley
msm : rpm-smd : Configure WQ for High Priority
Added LIONHEART
Added Fiops
Added ROW
Added FiFo
Added Conservative
Added I/O Tweak V1.3
Added Ondemand Tweak
Possible Fix For cpu core #1
V1.9 - Uploaded
Using 1.5 Kernel Source
Using Linaro
New VR
New SIO
New CFQ
New Dancedance
Added Mpdecision V2.0
Battery Tweak
mpdecision
ZRAM
Force To Charge At Unsupported Chargers
Optimized Build Flags
msm: cpufreq: Configure WQ for higer priority
msm_fb: display: Use spinlock instead of mutex in vsync timer handler
lib/memcopy: use glibc version
switch do_fsync() to fget_light()
Lowered Swap
Tweaked Page Write Back
JIT For Default
Update Topology V1
Added XZ Compression
Boost I/O Performance
LOAD_FREQ (4*HZ+61) avoids loadavg More
random: add new get_random_bytes_arch() function
block/deadline: tweaked for better performance on android
Reduced Android Logger RAM usage
mm.c Tweak
Drivers Tweak
I/O Tweak
msm: cpufreq: Add API to allow limiting of min and max cpu frequencies
Increased Battery Capacity
V1.8 - Uploaded
OC Upto 2.0Ghz
Patched Freq to 1.5Ghz
Fixed All Freq Except Cpu1
Revamped All Governor Except Ondemand
V1.7 - Uploaded
Added Source Added AOSP Source Defconfig
Increased 2D and 3D
Compiled With code sourcery
Fastcharge V2
remove 64Bit
I/O Tweak
Tweaked Lionheart
Tweaked Ondemand
Tweaked Dancedance
Tweaked Mpdecision
Tweaked UV
Added Battery tweak V2 Alpha
V1.6 - Uploaded
BB Installer Thanks to @letama
Exp Version
TWRP
Added @mericon to my Team.
Added New Bootsplash
Added New 3D OC
AROMA Installer
Kernel 3.4.49 with SoD Fix, Memory Leak Fix, And FPS Drop Fix - WIP -
2D OC Scallable - Upto 310Mhz
Fixed Missing Config Of Governors
Improve ADB file push/pull performance
msm: iommu: Synchronize access to IOMMU cfg port
msm: kgsl: Synchronize access to IOMMU cfg port
msm: kgsl: Make the GPU device aware of the next pending event
Improve MTP File Transfer Performance
V1.5 - Uploaded
Added Fiops
Added Smoothass
Added Lagfree
Added BrazillianWax
SuperStamina Support Beta #1 @ 1.7
driver/thermal: create kernel MSM thermal management for MSM8x60
mpdecision
msm: cpufreq: Configure WQ for higer priority
msm_fb: display: Use spinlock instead of mutex in vsync timer handler
lib/memcopy: use glibc version
switch do_fsync() to fget_light()
LOAD_FREQ (4*HZ+61) avoids loadavg More
random: add new get_random_bytes_arch() function
block/deadline: tweaked for better performance on android
Reduced Android Logger RAM usage
msm: cpufreq: Add API to allow limiting of min and max cpu frequencies
Increased Battery Capacity
Increased Charging Current - Higher is Better FTW!
V1.4- Uploaded
REMOVED DOOMLORD NEW RAMDISK VIOLATES I READ OP ALREADY. Thanks Re-Uploading
Reverted To the OLD Freq. Table
Remove Frequency Table Based On Fer. Kernel
Removed Native GPU OC That I Made
LINARO Compiled
ZRAM
Force To Charge At Unsupported Chargers
Optimized Build Flags
Added Lagfree - Not In Kernel In Defconfig It Will Be Available @ 1.5
Added BrazilianWax - Not In Kernel In Defconfig It Will Be Available @ 1.5
Remove Wheatly
Added Smoothass - Not In Kernel In Defconfig It Will Be Available @ 1.5
Fix Leak Memory
Fix Frequency Boot-up
V1.3 - Skipped Private Testing For 24hrs
V1.2 - Uploaded!
Voltage Control
New Build Flag
I/O Tweak V2
New Bootsplash By @Yakandu
GPU OC 2D/3D
GPU Control
New Frequency Table
Battery Tweak
FastCharge V1 Port from NOVA
V1.1 - Uploaded!
Increased I/O Performance x2
SIO Tweak
Compiled with Linaro Cortex
Linaro Optimization
Added Wheatly
Added SIO
Added HotPlug
Increased Entropy
Lowered Swap
Tweaked Page Write Back
JIT For Default
Update Topology V1
Added XZ Compression
Boost I/O Performance
V1.0
DoomLord RAMDISK
Pre-Rooted
Busybox
Compiled With Linaro ToolChain
Snapdragon Optimization
mm.c Tweak
Drivers Tweak
I/O Tweak
VM_READHEAD Tweak Increased
Battery Charge Tweak
dancedance Governor
Overclocking Support
Undervolting Support
Future Plan -
TWRP Recovery
Add Fugeswap
Arm: Allow CPU-supported unaligned accesses
CS ToolChain
O3 Optimization
SuperStamina Support
All Governors
USB OTG Support
USB Fast Charge
Nightmare Governor - TEST
Trinity Governor Based On - Dancedance
Tweak audio buffers for Beats
Complete I/O Scheduler
Many More That Is My Plan For 1.2 To 1.5
What Is A Kernel?
Android (like many other Smartphone operating systems) runs on the Linux kernel. The Linux kernel was created in the early 1990’s by a gentleman named Linus Torvalds in Helsinki Finland. It’s incredibly stable, incredibly friendly, and incredibly difficult for the layman to understand and modify. Thankfully it’s also very popular so it has been ported on to a multitude of hardware, including our Android devices.
Think of the kernel as an interface layer between the hardware and software on your device. The kernel decides when things happen, such as the LED indicator gets lit. An application sends a request to the operating system to blink the LED. The operating system then sends the request to the kernel, which makes the light flash for the amount of time requested by the OS.
What sounds like a round-about way to get things done is also what makes the system so scalable and robust. Application developers only have to code in a way the operating system understands and the kernel makes it work on the hardware. This also keeps the application running in it’s own user-space and separate from the kernel. That means when you run the latest uber-cool app that wasn’t designed for your particular OS version, or is still very beta and it crashes, the kernel gives you the option to Force Close the application and the kernel can run untouched.
In a standard Android ROM (we will leave developer images and the like for another discussion) the kernel is bundled along with a set of instructions that tell the device how to load the kernel and the OS during boot. This is the boot.img that you see inside a zipped ROM that you're not able to easily open. The device knows to extract this image to internal memory (the ramdisk) and follow a series of scripts (init scripts) to load the kernel and then the other portions of the OS. That’s what’s happening while you’re watching the boot animation. Interestingly enough this is done the same way for a PC, your smartphone, an Android tablet, or even a smart Linux powered toaster. If you’re feeling exceptionally geeky, plug your Android phone into the USB port on your PC and let the PC boot from the USB device. No, it doesn’t actually load, but you can watch the animation while it tries to match up the hardware support with what’s inside your PC. As I said, Linux is amazingly scalable and as a result so is Android.
 Credits -
DooMLord
Sony
XDA
BitBucket
!THREAD UNDER CONSTRUCTION!

Mpdecision and Sweep2Wake @ 1.5 Kernel SooN!
What is msm_mpdecision?
100% kernel based multi core decision! (should cpu1 be online or not?)
This replaces your /system/bin/mpdecision binary which is renamed by the installer to mpdecision_backup.
Check /sys/kernel/msm_mpdecision/conf/ for the configuration.
startdelay = time until mpdecision starts doing it's magic (70000)
delay = time between checks (500)
pause = if something else plugs in the cpu, fall asleep for 10000
scroff_single_core = if the screen is off, don't plug in cpu1 (1)
nwns_threshold_up = runqueue threshold, if this is reached cpu1 will be hotplugged (35)
nwns_threshold_down = runqueue threshold, if this is reached cpu1 will be unplugged (5)
twts_threshold_up = time threshold, this amount of time must have passed (250)
twts_threshold_down = same as above (250)
enabled = enable(1) or disable(0) mpdecision. This does not affect scroff_single_core!
idle_freq = a value against that will be checked if a core +/- is requested. (486000)
If cpu0 is below that value and a core up of cpu1 is requested, nothing will happen.
If cpu1 is above that value and a core down of cpu1 is requested, nothing will happen. (otherwise it would now put down cpu1 even though it is still working)
Click to expand...
Click to collapse
GOVERNORS
----
Official Governors to Be Added In My Kernel
----
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
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.
Thank To Droiphile

Which are the linaro beneficts? I heard a lot about it months ago...

megamarini said:
Which are the linaro beneficts? I heard a lot about it months ago...
Click to expand...
Click to collapse
Here you Go Buddy http://forum.xda-developers.com/showthread.php?t=1371044

TrinityHaxxorX said:
Here you Go Buddy http://forum.xda-developers.com/showthread.php?t=1371044
Click to expand...
Click to collapse
Thank you mate... and what about dance dance governor??? something really new??? i'm not able to find it on Google,...

we win a great devolper here ,, great job man you making alot of things in short time
keep up the good work

megamarini said:
Thank you mate... and what about dance dance governor??? something really new??? i'm not able to find it on Google,...
Click to expand...
Click to collapse
Yeah Its New...

TrinityHaxxorX said:
Yeah Its New...
Click to expand...
Click to collapse
It's battery friendly or performance?

sparxx4 said:
we win a great devolper here ,, great job man you making alot of things in short time
keep up the good work
Click to expand...
Click to collapse
Not A Shorttime lol I Worked 8-14Hrs For my ROM / Kernel Since Im Out of gaming Like MW3 and LOL So I Focus Development

megamarini said:
It's battery friendly or performance?
Click to expand...
Click to collapse
For my Opinion Yes... I'll Add the dancedance Info Later Im Still In my Friend house

@megamarini Thats Why Ive Default that as My Governor Its Likely Deepsleep Much better and the Performance is in the Core kernel or source files
It's Snuzzo's own creation. It's based on conservative, but with higher ramp rates (similar to lionheart) and better sleep routines (similar to wheatley).

TrinityHaxxorX said:
@megamarini Thats Why Ive Default that as My Governor Its Likely Deepsleep Much better and the Performance is in the Core kernel or source files
It's Snuzzo's own creation. It's based on conservative, but with higher ramp rates (similar to lionheart) and better sleep routines (similar to wheatley).
Click to expand...
Click to collapse
It looks very interesting... Thank you for your work!!:victory:

megamarini said:
It looks very interesting... Thank you for your work!!:victory:
Click to expand...
Click to collapse
Its Okay Just Give Feedback Later or Sooner

Oh yeah new kernel! XD
btw was the kernel boot up screen are SONY logo or?

jimRnor said:
Oh yeah new kernel! XD
btw was the kernel boot up screen are SONY logo or?
Click to expand...
Click to collapse
Cause I Dont have any Custom Bootsplash yet lol

yes its sony logo
___
almost 22 min on battery didnt lost 1% coooool

sparxx4 said:
yes its sony logo
___
almost 22 min on battery didnt lost 1% coooool
Click to expand...
Click to collapse
What Governor

ondemand
just flashed the kernel and didnt touch any thing
26 min on battery for 1% its roock dude with brightness almost 50% you can get more great job

sparxx4 said:
ondemand
just flashed the kernel and didnt touch any thing
26 min on battery for 1% its roock dude with brightness almost 50% you can get more great job
Click to expand...
Click to collapse
Good Use dancedance soon and give feedback

Future Plan -
TWRP Recovery
Add Fugeswap
Arm: Allow CPU-supported unaligned accesses
CS ToolChain
O3 Optimization
SuperStamina Support
All Governors
USB OTG Support
USB Fast Charge
Nightmare Governor - TEST
Trinity Governor Based On - Dancedance
Tweak audio buffers for Beats
Complete I/O Scheduler
Many More That Is My Plan For 1.2 To 1.5

[BATTERY GUIDE] Ultimate battery guide and talk topic

{
"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"
}
Ultimate battery guide
Battery, one of the most important thing on todays phones. Even if we have awesome battery life we always want more and it is never enough.
This is the small guide to tips, trick and tweaks to improve battery life.
This topic is to share tips and tricks and basically just small talk about battery and sharing screenshots.
Use Gsam or Android battery history to show your battery life.
Our goal is to make most of the screen on time with average use of 24 hours. So lets start.
Post 1: Tips
Post 2: ROMS, kernels, undervolting, underclocking
Tips to improve battery life
Location services
One of the first thing that your device will ask when you are setting up your phone. Most of the users let them ON and just forgot about them. Location services are battery hungry and the will drain your battery like you drinking juice.
Thing is that you do not need them always, just sometimes. Turn it OFF then. I have them turned off always and when I need it I just simple turn it ON.
Wi-Fi
Wi-Fi scanning is thing that will drain your battery always. When you are out and you are not expecting to use wi-fi any time soon turn it off. You do not need to run scanning all the time.
You could also edit build.prop to reduce.
Edit wifi.supplicant_scan_interval. Default value is 180. You can set it higher to reduce the scanning intervals.
Signal strength / Network mode
Signal strength is always trouble for battery. Weak signal will drain more battery. Also, constant changing between 4G/3G and 2G will drain battery faster.
Tweak to this is to set your phone to only use 2G, 3G or 4G.
Example: when I am not using my phone, or it is connected to wifi my network is on 2G. I dont need 3G or 4G then and changing network state is disabled then because it will stay always on 2G. I found it has positive effect on battery.
When I need, I just simple toggle 3G or 4G.
Screen brightness
Screen is the thing that drains most of our battery. There is not much philosophy here. Higher brightness will drain more battery.
My personal setup is that I do not use auto brightness. I always change brightness manually. Right now during winter my brightness does not go more then 25% outside, and inside it is lower. At night it is under 10%.
I found that not using auto brightness has also slight positive effect on battery.
Syncing / Airplane mode / Vibration / Animations / Task Killers
Lets start in order.
Syncing: more syncing your device does it drains more battery. On your phone probably you do not to sync all accounts and apps you have every few minutes or hours. Set those apps you do not need on manual sync.
Airplane mode: I am using airplane mode during night because I do not want to be disturbed during sleep. With airplane mode battery consumption during night is 0%. Yes, zero percent.
Vibration: more your device vibrates, more battery it drains. You can reduce vibrations on keyboard settings and similar. I found that is not much effect on battery but it has slight.
Animations: animations drains your battery also and who really needs them. Personally, I am annoyed with them and I always switch them to 0 or .5. You can do that in Settings-Developers options
Task Killers: task killers, clean maters and similar software is a big NO. You dont need it. It does more damage then good.
Bloatware
Yes, bloatware. There is huge amount of bloatware on our phones and we really do not need it. So, what to do? Freeze that bloatware.
You can find list of apps HERE.
ROMS and kernels
Custom ROMs and kernels will give you in most cases better battery life then stock firmware. Plus there is huge amount of options to play with. You can read more in posts bellow.
Summary:
If you change some of those thing you will see the effect.
You can always use apps like Greenify or Tasker and play with their options.
How to follow your battery life
GSam Battery Monitor
This one of the most useful apps to track your battery. On Lollipop (even on Kitkat) it will not give you much useful info without root.
If you are using it without root everytime you reboot the phone statistic would be reset also. If you have root it will give you access to wakelocks and some other stuff, plus stats would not get reseted.
Play store link
Wakelock detector
Wakelocks, one of the painful things on phone. If you see your battery is draining faster in idle then you got problem with wakelocks. This is useful app because it shows wakelocks on very simple setup and you can discover which app is causing which wakelock.
Play Store link
Disable service
If you are using Wakelock detector you need this app also. With this app you can freeze every single process that app can launch. It will provide detail look on all processes from apps. With this app I have reduced wakelocks to 1%.
Play Store link

ROMS
Discussion about ROMs never looked nice. It always gets to what you personally like. Some ROMs will be easier on battery, some will be rough. You will never know before you try them.
Kernels
Kernels are similar to ROMS but you can play with them. Currently there is not much kernels available but you can play even with stock one.
I recommend to use Trickster MOD Kernel Settings app to play with kernel settings.
Undervoting
Undervolting is the thing when you control how much power each CPU frequency can have. Trickster MOD app gives really nice view on them. You can undervolt every frequency by itself or all in one.
My personal recommendation is to undervolt them at once. I always use -50 value. Found it stable.
Of course, you can always play with different values but remember: when you play with this do not click on option "Set on Boot" or you will end in bootloop if you click it. Click that option when you find out that values are safe for using and stable.
Underclocking
Underclocking is changing your CPU frequency. Rough truth is that we dont need our CPU to run on 2,7 GHz in normal use. Only gamers will need that probably but since this is not thread were we are aiming gamers we dont need that high frequency.
Me personally, I use always 1,7 GHz or 1,9 GHz. To my daily usage (most common like everyone else but without games) this is more then enough. Everything is still smooth and runs fast.
Governors
A CPU governor in Android controls how the CPU raises and lowers its frequency in response to the demands the user is placing on their device. Governors are especially important in smartphones and tablets because they have a large impact on the apparent fluidity of the interface and the battery life of the device over a charge.
You can find explanation hidden here.
Many users have wrote about governors and they are practically the same on most of the phones so I will copy list from droidphile.
On his topic you have more details about governors.
Link to original topic: http://forum.xda-developers.com/galaxy-s2/general/ref-kernel-governors-modules-o-t1369817
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
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!
Schedulers
Everything has been said about them so I will use droidphile explanations.
Link to original topic: http://forum.xda-developers.com/galaxy-s2/general/ref-kernel-governors-modules-o-t1369817
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.

Develop Bugs

welcome