Develop Bugs

[Q] [CyanogenMod7 RC4] Overclock and Performance Settings

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

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

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

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

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

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

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

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

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

thanks for the tip...

[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 KERNEL​15: Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery​16: SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.​17: Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.​18: Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source.
The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.​19: LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.​20: Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors)
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
​21: Hotplug Governor:
The Hotplug governor performs very similarly to the OnDemand governor, with the added benefit of being more precise about how it steps down through the kernel's frequency table as the governor measures the user's CPU load. However, the Hotplug governor's defining feature is its ability to turn unused CPU cores off during periods of low CPU utilization. This is known as "hotplugging."
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 & Output​I/O Scheduler:- Input/output (I/O) scheduling is a term used to describe the method computer operating systems decide the order that block I/O operations will be submitted to storage volumes. I/O Scheduling is sometimes called 'disk scheduling'.
I/O schedulers can have many purposes depending on the goal of the I/O scheduler, some common goals are:
- To 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.

[KERNEL] Bricked-Kernel Hammerhead | Sweep2wake | KnockKnock/Dt2w

Welcome to the most customizable N5 kernel on xda
Bricked-Kernel Nexus 5 (hammerhead)​
Features:
* Based upon Google's msm 3.4 source
* Various fixes, improvements and optimizatios (look @ github)
* Compiled with gcc4.7.2 toolchain (linaro 09.12)
* -O3+ optimized
* Snapdragon & CortexA15 optimizations
* replaced qcom's hotplug binary with msm_mpdecision (IN-KERNEL, better battery life + performance)
* Extensive sysfs interface for mpdecision with all the tuneables you want (/sys/kernel/msm_mpdecision/)
* replaced qcom's thermal binary with my IN-KERNEL solution. (/sys/kernel/msm_thermal/)
* export krait version to: /sys/kernel/debug/krait_variant
* Allow OC up to 2,5Ghz
* Allow UC to 96Mhz
* Undervolting (faux123)
* F2FS Support
* Multirom Support
* KCAL (savoca) & Gamma Control (faux123)
* Sound Control (faux123)
* Default clocks: 300 Mhz min & 2265,6 Mhz max
Zip features:
*** ON-THE-FLY-RAMDISK EDITS!
*** THIS KERNEL USES YOUR RAMDISK, it will just modify it on the fly while flashing. These changes are not creating any incompatibilities with roms/other kernels.
* removes min freq overrides from the ramdisk
* removes governor overrides from the ramdisk
* adds init.d support to your ramdisk (if not already supported)
* modifies stock ondemand settings
* add module insertion
Check the compare links for the rest ​
Where is tha Changelog???
There will be no more changelogs.
Instead the download pages were outfitted with compare links to github for each download.​
What is sweep2wake?
Disabled as default, activate through an app like KControl or over sysfs: echo 1 > /sys/android_touch/sweep2wake​
What is doubletap2wake / knock knock?
Disabled as default, activate through an app like KControl or over sysfs: echo 1 > /sys/android_touch/doubletap2wake​
How to install?
Flash through recovery. #done.​
How to uninstall?
Flash this:
http://bricked.de/downloads/kernel/hammerhead/bricked_uninstaller_hammerhead.zip
You are done. Bye.​
Where to complain about errors/bugs?
Please use the Issuetracker for bugs/errors/feature wishes!
Issuetracker @ https://github.com/showp1984/bricked-hammerhead/issues
[email protected]
IRC Chat: Freenode IRC #bricked​
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!)
>>> DOWNLOAD <<<​
Donation Hall-of-Fame:​
> Hall of fame <
Thank you very much!​
Stock 4.4 Nexus5 boot.img - flash this if you come from another kernel coming with it's own ramdisk (eg: zip contains a *.img file) ONLY FLASH ON 4.4
Source:
​

What is msm_thermal?
Kernel based 3-phase thermal control!
This replaces your /system/bin/thermal-engine-hh binary which is renamed by the installer to thermal-engine-hh_bck.
It will throttle your cpu speed to keep it cool and unleash it if the cpu has cooled down enough. (3 phases: low, mid and high)
Check /sys/kernel/msm_thermal/conf/ for the thermal configuration
allowed_max_high = highest threshold (phase 3)
allowed_max_low = remove the throttling if we cooled down to this (clr_thrshold)
allowed_max_freq = max frequency if throttled (limit)
[...]mid[...] = same as above, just for phase 2
[...]low[...] = Lowest threshold (phase 1)
check_interval_ms = how often shall we check? (sampling rate)
shutdown_temp = if we reach this shut down the device!
If you want to see msm_thermal doing it's job:
Code:
adb shell
cat /proc/kmsg | grep 'thermal'
What is msm_mpdecision?
100% kernel based multi core decision! (should cpu1/2/3 be online or not?)
This replaces your /system/bin/mpdecision binary which is renamed by the installer to mpdecision_bck.
Check /sys/kernel/msm_mpdecision/conf/ for the configuration.
startdelay = time until mpdecision starts doing it's magic (20000)
delay = time between checks (130)
pause = if something else plugs in the cpu, fall asleep for 10000ms (10 secs)
scroff_single_core = if the screen is off, don't plug in cpu1/2/3. Additionally: Unplug all cpus except cpu0 when screen is turned off (1)
enabled = enable(1) or disable(0) mpdecision. This does not affect scroff_single_core!
min_cpus = min cpus to be online, cannot be < 1. Default: 1
max_cpus = max cpus to be online, cannot be > 4. (if you set it to 2 and min_cpus to 1 you will basically have a dualcore) Default: 4
idle_freq = a value against that will be checked if a core +/- is requested. (499200)
If cpu0 is below that value and a core up of another cpu is requested, nothing will happen.
If any other cpu is above that value and a core down of that cpu is requested, nothing will happen. (otherwise it would now put down that cpu even though it is still working, which isn't what we want)
Hot plug thresholds (aka now it gets 'complicated')
This small formula calculates which value will be used: (number_of_cpus_online - 1) * 2
The result of this formula will be the nwns_threshold where a new cpu is hotplugged.
The result of this formula + 1 will be the nwns_threshold where a cpu is unplugged.
nwns_threshold_x = runqueue threshold, if this is reached cpuX will be hot/unplugged
twts_threshold_x = time threshold, this amount of time must have passed for the related action to be taken (hot/unplug)
Example:
One cpu is online.
(1 - 1) * 2 = 0 ergo:
nwns_threshold_0 = cpu1 will be hotplugged at this value
((1 - 1) * 2) + 1 = 1
nwns_threshold_1 = cpu0 will be unplugged at this value
Since we can't unplug cpu0 this is '0'.
Two cpus are online.
(2 - 1) * 2 = 2 ergo:
nwns_threshold_2 = cpu2 will be hotplugged at this value
((2 - 1) * 2) + 1 = 3
nwns_threshold_3 = cpu1 will be unplugged at this value
etc...
Some values are:
NwNs_Threshold: 12, 0, 25, 20, 32, 28, 0, 35
TwTs_Threshold: 140, 0, 140, 190, 140, 190, 0, 190
Where the position and function of the number equals the result of the above explained formula.
(all times are in ms)
If you want to see the mpdecision magic happening:
Code:
adb shell
cat /proc/kmsg | grep 'MPDEC'
mpdecision's input event boost, aka project butter
This will boost your min cpu speed if you touch the screen or press a button and gives you full control.
In those events the min cpu freq will be risen to a predefined value (look below) on every online cpu. This boosts overall reaction times and smoothness a lot. (works similar to the qcom mpdecision binary)
Configuration files:
[email protected]:/sys/kernel/msm_mpdecision/conf # ls | grep boost
boost_enabled
boost_freqs
boost_time
All of them work like the usual sysfs files, except one special case:
boost_freqs will list all frequencies from cpu 0 to cpu x. Cpu 3 and any following cpu will share one frequency.
To change those frequencies echo the cpu number + the frequency in khz.
Example: To change the boost freq of cpu3 (and 4,5,6,7,8, etc) the echo would look as follows:
Code:
echo "3 960000" > /sys/kernel/msm_mpdecision/conf/boost_freqs
for cpu0:
Code:
echo "0 960000" > /sys/kernel/msm_mpdecision/conf/boost_freqs
Defaults:
Code:
cat /sys/kernel/msm_mpdecision/conf/boost_freqs
960000
960000
729600
576000
Why do I have no WLAN?
Due to this kernels very high optimization settings it is too big for our boot.img with WLAN included into the kernel, so it is built as a module. That means it needs to be inserted into the kernel upon boot up, which needs to be automated for maximum comfort.
The zip adds module insertion to your ramdisk, if that fails for some reason the wlan module cannot be inserted.
if
Code:
adb shell lsmod
doesn't show this:
Code:
tun 14701 0 - Live 0x00000000
cifs 275399 0 - Live 0x00000000
bcmdhd 2964650 0 - Live 0x00000000 (C)
Then something went horribly wrong.
Chances are that I broke it and this should never happen.
One post in the issue tracker will probably fix it with the next release
You can restore wlan for your current bootup by executing:
Code:
adb shell
su
insmod /system/lib/modules/bcmdhd.ko
Is there an app available to customize this pure bodacious and awesome kernel?
Yes there is: KControl. It's in the Google Playstore.
​

A few benchmark results:
Vellamo Metal:
http://vellamo2.quicinc.com/api/v2/app/plot/Metal/submission/PEE3B604B-8C49-69F5-001E-6BCA76DF491D
(usually ranges from 11xx-12xx. Depending on system background load, thermal status, air pressure, weather, world hunger, etc...)
Antutu:
https://plus.google.com/u/0/108262968419038009038/posts/VJbxpMoFJPN
(usually ranges from 28.xxx - 30.xxx. Depending on system background load, thermal status, air pressure, weather, world hunger, etc...)
3DMark Icestorm unlimited: (the others are maxed out)
https://plus.google.com/u/0/108262968419038009038/posts/N24t9ssoBcL
(17xxx)

FIRST! o yes!!! mwhahahah!! and so it begins

Finally a Bricked thread! :victory: No more F5 spamming the kernel website

Good stuff, you've finally joined the party.
Sent from my Nexus 5 using Tapatalk

Woot! first page!

+1
10 char

Ngo93 said:
Finally a Bricked thread! :victory: No more F5 spamming the kernel website
Click to expand...
Click to collapse
If you are familiar with rss, all kernel download pages have a little rss symbol, if you click it you get here:
http://bricked.de/kernelrss.php?action=krss&device=hammerhead&release=stable&type=aosp
Just something to consider instead of spamming F5
unforgivenmercy said:
Good stuff, you've finally joined the party.
Click to expand...
Click to collapse
If you take a look at the dates on my homepage you might notice that the party ended about 2 days ago. The after party on the other hand starts now!
faux123 said:
Woot! first page!
Click to expand...
Click to collapse
Indeed! Well the thread isn't that old yet

OBI ONE is here aweseome !!! Always a pleasure to hang around in ur threads

n3ocort3x said:
OBI ONE is here aweseome !!! Always a pleasure to hang around in ur threads
Click to expand...
Click to collapse
left something on github for you

I saw, many thanks for that, but i think i have to ask u a bit about this, already in bed now, but tomorrow is another day 5star and subscribed as always

show-p1984 said:
left something on github for you
Click to expand...
Click to collapse
In the op it just says to install. So no wiping of cache or D cache correct? Sorry just re assuring
Sent from my Nexus 5 using Tapatalk

Wiping cache is redundant and you don't have to do it with kernels.
Sent from my Nexus 5 using Tapatalk

Carbajal3009 said:
In the op it just says to install. So no wiping of cache or D cache correct? Sorry just re assuring
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
The zip does it for you.
However, if it gives you a warm and fuzzy feeling you are free to do it again (so twice then ^^).

Wow, finally it is here. Flashing now.

Has anyone actually demonstrated (scientifically or otherwise) anything wrong with the qcom mpdecision binary? Im not taking anything away from kernel developers who write their own mpdecision (especially those who also provides sources), but I am curious as to whether they are actually better than those provided by qcom. Surely they know more about the capabilities of their own cpus better than anyone no?

jazzor said:
Has anyone actually demonstrated (scientifically or otherwise) anything wrong with the qcom mpdecision binary? Im not taking anything away from kernel developers who write their own mpdecision (especially those who also provides sources), but I am curious as to whether they are actually better than those provided by qcom. Surely they know more about the capabilities of their own cpus better than anyone no?
Click to expand...
Click to collapse
A fair question, I imagine there is something sacrificed using either or.
Sent from my Nexus 5 using XDA Premium 4 mobile app

jazzor said:
Has anyone actually demonstrated (scientifically or otherwise) anything wrong with the qcom mpdecision binary? Im not taking anything away from kernel developers who write their own mpdecision (especially those who also provides sources), but I am curious as to whether they are actually better than those provided by qcom. Surely they know more about the capabilities of their own cpus better than anyone no?
Click to expand...
Click to collapse
It's not that complicated (there is no black voodoo magic), that's why bricked kernel was the first to introduce this feature back on the pyramid.
CPUs need to be plugged in / unplugged based on load, there is nothing more qcom can know that we can't also see inside of the kernel.
There is one HUGE thing that is wrong with qcom's mpdecision: It's closed. It's a black box. We don't have any idea what is going on in there. Literally, none. It's not even configurable. It could contain secret nsa code, or send dirty sms to your girlfriend (who might actually enjoy that, idk...)
If we would have source, hell, awesome. I wouldn't have spent over a year (first commit: Date: Thu, 21 Jun 2012 06:06:47 +0200, see here) to get my msm_mpdecision solution to the point where it is a) awesome and b) a lot better than the binary. It can be configured in any way you might need to. It features statistics on how often and how long a cpu is hotplugged. It has the input event boost. It's the full package deal.
If you compare my kernel with the stock kernel you will see huge performance improvements and battery savings on bricked. Those are not only because of my msm_mpdecision but certainly related. Furthermore: we can completely customize it, over sysfs, on a running kernel, without reflashing.
That's what I would have expected from qcom in the first place.
Another thing wrong with qcom's binary: It's static. Meaning: If you change your min freq on stock it will always reset back to defaults. Same with their thermal binary. That's just annoying.
msm_mpdecision will notice it if you change your min frequency and dynamically work with that from there on. It will also prevent hotplug wars between apps and it: eg: an app plugs in cpus to grab some cpu data (like frequencies, etc. That is only available if the cpu is plugged in). Qcom's mpdecision would now raise hell to keep that cpu unplugged, my msm_mpdecision just sits back and chills for 10 seconds to avoid those wars. (again, even that delay is fully configurable)
There are also a bunch of boring advantages as to why it is better to let something crucial to the system run in kernel space and not in user space, but that would most certainly explode the context of this thread by the factor of 4.
My solution is not inferior to that binary in any way, in fact it has been vastly superior in my testing up until now, otherwise I would a) improve it or b) ditch it. I don't keep around bad stuff just for the point of having it or because I wrote it. If it sucks I will say that and act accordingly.

Thanks for the very informative post. I suppose there are advantages in avoiding qcom's mpdecision. Though i'd like to point out that the Android framework (msm power HAL) does use some of the interfaces provided by the binary (see hardware/qcom/power/). With the nexus 4, this will spam a lot of stuff to logcat if you are missing this interface, not sure if this is the same with the nexus 5, but judging by the sources it seems it will. Maybe you could provide some notification about this side effect.
Similarly, this could apply to the thermal side of things as well.

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

@moderator
Since i have been on xda for quite some time,i realised that many people here dont know much about governers,i/o schedulers etc. . So i decided to give them a guide which will help them learn the basics of these things.Please remove this thread only if u find this is a waste of time.
Click to expand...
Click to collapse
First of all ,i did not make this guide.It was made by "droidphile" ,a recognised contributor of xda forums.the original thread link is here-
http://forum.xda-developers.com/showthread.php?t=1369817
Thanks To
1) Gokhanmoral for his mighty sweet Siyah Kernel which inspired me to write this thread.
2) Moderators for squeezing in extra posts when i ran out of space to fit everything in only 3 reserved posts.
3) Users/Readers for your warm comments.
4)droidphile for his excellent guide
Most of us are flash maniacs, and we do it a lot. But after a kernel flash, we wonder:
Q1. "OK i have flashed this xyz kernel. What're all these governors? How do i know which one is the best for me? How do i tweak them to bias their characters towards Battery-life/Performance/Balance between the Two".
Q2. "What's the fuzz about these modules that comes with the kernel. How do i use them. Are they any good. Is it OK to neglect them?"
Q3. "What roles does an i/o scheduler play? How to choose a reliable i/o scheduler?"
Q4. "Can i have more control on CPU? More info and tweaks on dual core CPU, bus frequency, etc?"
Q5. "Better understanding on impact of different values for basic/advanced parameters in the Kernel Config App, so that i can tweak the settings according to my taste?"
Hope this thread could give you answers for all these questions. We're covering governors, modules, i/o schedulers that comes with Siyah kernel, plus more. That should cover almost all the popular governors/modules/io schedulers! Many people seem to get lost in Kernel dev threads without getting answers about governors and such.
The info in this thread holds good for non-siyah kernel users too. You should find here, info on most of the governors/modules/io schedulers in your kernel if not all.
INDEX--
POST 1: KERNEL GOVERNORS
POST 2: GOVERNOR TWEAKS
POST 3: LOADABLE KERNEL MODULES
POST 4: I/O SCHEDULERS
POST 5: DUAL CORE CPU Q&A AND TWEAKS

GOVERNERS
GOVERNERS
Click to expand...
Click to collapse
I) MANUAL:
These are the 19 governors we're talking about.
1) Ondemand
2) Ondemandx
3) Conservative
4) Interactive
5) Interactivex
6) Lulzactive
7) Lulzactiveq
8) Smartass
9) SmartassV2
10) Intellidemand
11) Lazy
12) Lagfree
13) Lionheart
14) LionheartX
15) Brazilianwax
16) SavagedZen
17) Userspacce
18) Powersave
19) Performance
**NOTE: Info on Samsung's own multi-core aware governor - Pegasusq is here-http://forum.xda-developers.com/showpost.php?p=24233103&postcount=3&nocache=1&z=3535953573882580
1) Ondemand:
Default governor in almost all stock kernels. One main goal of the ondemand governor is to switch to max frequency as soon as there is a CPU activity detected to ensure the responsiveness of the system. (You can change this behavior using smooth scaling parameters, refer Siyah tweaks at the end of 3rd post.) Effectively, it uses the CPU busy time as the answer to "how critical is performance right now" question. So Ondemand jumps to maximum frequency when CPU is busy and decreases the frequency gradually when CPU is less loaded/apporaching idle. Even though many of us consider this a reliable governor, it falls short on battery saving and performance on default settings. One potential reason for ondemand governor being not very power efficient is that the governor decide the next target frequency by instant requirement during sampling interval. The instant requirement can response quickly to workload change, but it does not usually reflect workload real CPU usage requirement in a small longer time and it possibly causes frequently change between highest and lowest frequency.
2) Ondemandx:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
3) Conservative:
A slower Ondemand which scales up slowly to save battery. The conservative governor is based on the ondemand governor. It functions like the Ondemand governor by dynamically adjusting frequencies based on processor utilization. However, the conservative governor increases and decreases CPU speed more gradually. Simply put, this governor increases the frequency step by step on CPU load and jumps to lowest frequency on CPU idle. Conservative governor aims to dynamically adjust the CPU frequency to current utilization, without jumping to max frequency. The sampling_down_factor value acts as a negative multiplier of sampling_rate to reduce the frequency that the scheduler samples the CPU utilization. For example, if sampling_rate equal to 20,000 and sampling_down_factor is 2, the governor samples the CPU utilization every 40,000 microseconds.
4) Interactive:
Can be considered a faster ondemand. So more snappier, less battery. Interactive is designed for latency-sensitive, interactive workloads. Instead of sampling at every interval like ondemand, it determines how to scale up when CPU comes out of idle. The governor has the following advantages: 1) More consistent ramping, because existing governors do their CPU load sampling in a workqueue context, but interactive governor does this in a timer context, which gives more consistent CPU load sampling. 2) Higher priority for CPU frequency increase, thus giving the remaining tasks the CPU performance benefit, unlike existing governors which schedule ramp-up work to occur after your performance starved tasks have completed. Interactive It's an intelligent Ondemand because of stability optimizations. Why??
Sampling the CPU load every X ms (like Ondemand) can lead to under-powering the CPU for X ms, leading to dropped frames, stuttering UI, etc. Instead of sampling the CPU at a specified rate, the interactive governor will check whether to scale the CPU frequency up soon after coming out of idle. When the CPU comes out of idle, a timer is configured to fire within 1-2 ticks. If the CPU is very busy between exiting idle and when the timer fires, then we assume the CPU is underpowered and ramp to max frequency.
5) Interactivex:
This is an Interactive governor with a wake profile. More battery friendly than interactive.
6) Lulzactive:
This new find from Tegrak is based on Interactive & Smartass governors and is one of the favorites.
Old Version: When workload is greater than or equal to 60%, the governor scales up CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step. When screen is off, frequency is locked to global scaling minimum frequency.
New Version: Three more user configurable parameters: inc_cpu_load, pump_up_step, pump_down_step. Unlike older version, this one gives more control for the user. We can set the threshold at which governor decides to scale up/down. We can also set number of frequency steps to be skipped while polling up and down.
When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. When workload is less than inc_cpu_load, governor scales CPU down pump_down_step steps down.
Example:
Consider
inc_cpu_load=70
pump_up_step=2
pump_down_step=1
If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800.
If current frequency =1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.
7) Lulzactiveq:
Lulzactiveq is a modified lulzactive governor authored by XDA member robertobsc and is adapted in Siyah kernel for GS2 and GS3. Lulzactiveq aims to optimize the second version of luzactive from Tegrak by a) providing an extra parameter (dec_cpu_load) to make scaling down more sensible, and b) incorporating hotplug logic to the governor. Luzactiveq is the first ever interactive based governor with hotplugging logic inbuilt (atleast the first of its kind for the exynos platform). When CPU comes out of idle loop and it's time to make a scaling decision, if load >= inc_cpu_load CPU is scaled up (like original luzactiveq) and if load <dec_cpu_load, CPU is scaled down. This possibly eliminates the strict single cut-off frequency for luzactiveq to make CPU scaling decisions. Also, stand hotplug logic runs as a separate thread with the governor so that external hotplugging logic is not required to control hotplug in and out (turn On and Off) CPU cores in multi core devices like GS2 or GS3. Only a multi core aware governor makes real sense on muti-core devices. Lulzactiveq and pegasusq aims to do that.
8) Smartass:
Result of Erasmux rewriting the complete code of interactive governor. Main goal is to optimize battery life without comprising performance. Still, not as battery friendly as smartassV2 since screen-on minimum frequency is greater than frequencies used during screen-off. Smartass would jump up to highest frequency too often as well.
9) SmartassV2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery.
10) Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors )
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
11) Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.
12) Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.
13) Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source. Tweaks comes from 1) Knzo 2) Morfic. The original idea comes from Netarchy. See here. The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
To 'experience' Lionheart using conservative, try these tweaks:
sampling_rate:10000 or 20000 or 50000, whichever you feel is safer. (transition latency of the CPU is something below 10ms/10,000uS hence using 10,000 might not be safe).
up_threshold:60
down_threshold:30
freq_step:5
Lionheart goes well with deadline i/o scheduler. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand.
14) LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
15) Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery.
16) SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
17) Userspace:
Instead of automatically determining frequencies, lets user set frequencies.
18) Powersave:
Locks max frequency to min frequency. Can not be used as a screen-on or even screen-off (if scaling min frequency is too low).
19) Performance:
Sets min frequency as max frequency. Use this while benchmarking!
So, Governors can be categorized into 3/4 on a high level:
1.a) Ondemand Based:
Works on "ramp-up on high load" principle. CPU busy-time is taken into consideration for scaling decisions. Members: Ondemand, OndemandX, Intellidemand, Lazy, Lagfree.
1.b) Conservative Based:
Members: Conservative, Lionheart, LionheartX
2) Interactive Based:
Works on "make scaling decision when CPU comes out of idle-loop" principle. Members: Interactive, InteractiveX, Lulzactive, Luzactiveq, Smartass, SmartassV2, Brazilianwax, SavagedZen.
3) Weird Category:
Members: Userspace, Powersave, Performance
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
II) QUESTION TIME:
Q. "Ok. Enough of explanations. Tell me which governor is for performance and which one is for battery life."
A. Tough question! lulzactive and smartassV2 for a balance between performance and battery. For light weight tasks, lulzactive should be better for battery. And for heavy weight tasks, lulzactive should be better for performance also. To get maximum performance, use a tweaked ondemand or conservative, but never complain about battery. NOTE: It's not so easy to tame luzactive. If you don't know how exactly to do it, stay away from it or you will end up complaining about battery drain!
Q. "Hey, almost forgot. How do i change governors?"
A. Best way is to use an init.d script if your kernel supports it. (echo "governor-name" > /sys/devices/system/cpu/cpu0/cpufreq /scaling_governor) Else use Voltage Control/SetCpu/No Frills/Antuntu CPU Master, etc. Voltage Control has the interfaces for gpu oc/uc/uv and charge-current change if your kernel supports them. Like we guessed, these apps will tell us the active governor too.
Q. "How do i know which governor is best for me?"
A. It depends on what you need and your daily usage pattern. Performance or battery. Better choose a governor that's balanced for battery/performance. Or tweak a governor to give performance an upper-hand as compared to battery. We can always re-charge the phone: In car when off to work, or overnight. But we can not recharge performance! After all, we bought GS2 to enjoy it's sheer power.
Q. "Well i have set my favorite governor as screen-on governor and another one as screen-off governor. Why the hell is the phone not waking up after deep sleep. I need to force-restart the phone by pressing power button for about 10 secs. Is it a sleep-of-death?"
A. Yes it is. Do not use two governors as screen-on & screen-off govs, if they both have an upper frequency limit for screen-off state.
Didn't get it? Examples for Wrong combinations: (screen-on:screen-off):-
ondemandX:smartassV2
Examples for right combinations:-
ondemand:smartassV2, lulzactive:smartassV2
Q. "I can feel slight lags here and there with a governor. For ex: while scrolling through app drawer/vertically scrolling browser, etc. I really love this governor and don't tell me to use another governor. Can i diminish this lag?"
A. Hmm well, you can. Basically what we have to do is make the governor "poll" less often to scale-down cpu. Increase down-sampling-time of your governor (whichever parameter that corresponds to), so that the cpu will stay longer on a frequency before scaling down. This should eliminate the lag.
Q. "Even though i don't have too much uv/oc, once in a while; may be once in two weeks, i experience a freeze/lock/reboot. I'm using governor X. How do i solve this?"
A. Well, a random reboot/freeze once in a while signifies that we're android/galaxy SII enthusiast. If everything go smooth as silk, what's the fun? We could use stock rom/kernel/governor and be happy. A rare reboot or freeze is nothing to worry about. Just restart the phone.
Q. "OK. I want to tweak these governors according to my usage pattern, because i'm not happy with the default behavior of these governors".
A. You can tweak the governors using an init.d script to echo suitable values into:
/sys/devices/system/cpu/cpufreq/name-of-active-governor/name-of-the-paramater-to-tweak
Example:
echo "20000" /sys/devices/system/cpu/cpufreq/lulzactive/up_sample_time
Q. "I'm going to set scaling min freq as 100 mhz because my kernel supports it. Hope there's nothing wrong in doing that."
A. Wait! You may want to stay away from using 100mhz during screen-off or screen-on states for three reasons 1) It seems 100 mhz uses more power than 200 mhz. According to tests, 100 mhz accounted to 1 W / GHz and 200 mhz to 0.7 W / GHz, when both the cores were online. 2) 200 mhz can finish same task faster compared 100 mhz and thus hit deep idle soon. 3) 200 mhz is the 'sweet spot' of frequency in SGS II. ie, the frequency used in the calculations based on the optimal energy to run (Ex: In Milestone it's 550 MHz). So , 'energetically efficient' frequency for our CPU is 200 mhz.
Q. "I want to know is there's anything more i can do to improve battery life. I have already tweaked my governor settings but..."
A. Take my word. Best way is to limit scaling max freq to 800 or 1000 mhz. Sgs2 can do majority of the task with 1000 or 800 as the max. OCing to 1600mhz draws considerably more power than stock 1200mhz or even 1400mhz. Try scaling between 200 and 1000 mhz for a day and feel the difference.
Q. "How to make my device more snappier. I don't care much about batt....err...I do care about battery life, but only in terms of avoiding unwanted power consumption. Device should instantly dance to my tunes."
A. Scale 500 to 1200 during screen-on and 200-500 during screen-off. Use performance tweaked conservative/ondemand(x). No excess power consumption because 1400 and 1600 is out the league. Response will be sweet. And don't worry, minimum of 500 during screen-on will not drain too much battery like you think!
GOVERNER TWEAKS IN NEXT POST

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

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

I/o schedulers
I/O SCHEDULERS
Q. "What purposes does an i/o scheduler serve?"
A.
Minimize hard disk seek latency.
Prioritize I/O requests from processes.
Allocate disk bandwidth for running processes.
Guarantee that certain requests will be served before a deadline.
So in the simplest of simplest form: Kernel controls the disk access using I/O Scheduler.
Q. "What goals every I/O scheduler tries to balance?"
A.
Fairness (let every process have its share of the access to disk)
Performance (try to serve requests close to current disk head position first, because seeking there is fastest)
Real-time (guarantee that a request is serviced in a given time)
Q. "Description, advantages, disadvantages of each I/O Scheduler?"
A.
1) Noop
Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.
Advantages:
Serves I/O requests with least number of cpu cycles. (Battery friendly?)
Best for flash drives since there is no seeking penalty.
Good throughput on db systems.
Disadvantages:
Reduction in number of cpu cycles used is proportional to drop in performance.
2) Deadline
Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.
Advantages:
Nearly a real time scheduler.
Excels in reducing latency of any given single I/O.
Best scheduler for database access and queries.
Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.
Like noop, a good scheduler for solid state/flash drives.
Disadvantages:
When system is overloaded, set of processes that may miss deadline is largely unpredictable.
3) CFQ
Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.
Advantages:
Considered to deliver a balanced i/o performance.
Easiest to tune.
Excels on multiprocessor systems.
Best database system performance after deadline.
Disadvantages:
Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.
4) BFQ
Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.
Advantages:
Believed to be very good for usb data transfer rate.
Believed to be the best scheduler for HD video recording and video streaming. (because of less jitter as compared to CFQ and others)
Considered an accurate i/o scheduler.
Achieves about 30% more throughput than CFQ on most workloads.
Disadvantages:
Not the best scheduler for benchmarking.
Higher budget assigned to a process can affect interactivity and increased latency.
5) SIO
Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.
Advantages:
Simple, so reliable.
Minimized starvation of requests.
Disadvantages:
Slow random-read speeds on flash drives, compared to other schedulers.
Sequential-read speeds on flash drives also not so good.
6) V(R)
Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.
Advantages:
May be best for benchmarking because at the peak of it's 'form' VR performs best.
I/O Schedulers
Disadvantages:
Performance fluctuation results in below-average performance at times.
Least reliable/most unstable.
7) Anticipatory
Based on two facts
i) Disk seeks are really slow.
ii) Write operations can happen whenever, but there is always some process waiting for read operation.
So anticipatory prioritize read operations over write. It anticipates synchronous read operations.
Advantages:
Read requests from processes are never starved.
As good as noop for read-performance on flash drives.
Disadvantages:
'Guess works' might not be always reliable.
Reduced write-performance on high performance disks.
Q. "Best I/O Scheduler?"
A.There is nothing called "best" i/o scheduler. Depending on your usage environment and tasks/apps been run, use different schedulers. That's the best i can suggest.
However, considering the overall performance, battery, reliability and low latency, it is believed that
SIO > Noop > Deadline > VR > BFQ > CFQ, given all schedulers are tweaked and the storage used is a flash device.
Q. "How do i change I/O schedulers?"
Voltage Control or No Frills from market.
Or init.d script:
echo "scheduler-name" > /sys/block/mmcblk0/queue/scheduler

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

[KERNEL] [25/9] [LP][ KK] Carbon Kernel R5

CARBON KERNEL
Code:
#include <std_disclaimer.h>
/*
* Your warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this KERNEL
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
*
*/
R1
Bricked_hotplug
custom governors (conservative , ondemandplus , intelliactive, smartass, optimax, wheatley, n more )
new power management mode PowerSuspend for deep sleep fixes
frandom add
kernel mode NEON
LCD KCAL Color Calibration
Double Tap 2 Wake
Sweep 2 Wake+Sweep 2 Sleep
Multi Core Power Saving
Faux Sound 3.8
RAM management n optimization
Underclock upto 96 Mhz
dynamic fsync
simple algorithm for GPU from faux123
latest Linaro 5.1.1 (UBER) used for the build with full -o3 optimizations
R2
msm_hotplug and brick_hotplug (msm_hotplug enabled by default)
added state notifier
added USB fast charging
GPU overclock upload 650 Mhz
GPU underclocked to 100 Mhz
Franco Thermals added back with fixes
added governors
abyssplugv2
adaptive
badass
dancedance
darkness
hyper
intelliactive
intellimm
lazy
lionheart
nightmare
ondemandplus
optimax
pegasusq
slim
smartmax
smartmax_eps
uberdemand
wheatly
I/O schedulers added
BFQ
SIO
ZEN
FIOPS
VR
TRIPNDROID
Multicore powersaving enabled to aggressive by default
Added 10 new TCP cong
Used SaberMod 6.0 with -O3 optimizations
and much more check my github for more details
https://github.com/tarunkapadia93/android_kernel_xiaomi_armani/tree/cm-12.1
R3 :
compatible with CM R7 n Nameless R3 n the other lastest builds (that means no SystemUI FC any more )
based of caf kernels by @rebelos
few fixes
led notification light fixed
R4 BETA FINAL:
back to bricked hotplug with proper tuning this time
rebased of armani-dev kernel
video recording issue solved
dt2w & s2s+s2w added
new governor
same list of i/o
gpu max clock too 533Mhz (i dont see a real good scaling at 650 Mhz i m working on this part so pls wait)
R5:
Compiled with Linaro 4.9.4 Cortex A7 (Thanx to Christopher83)
O3 Optimizations
MultiROM support aka Kexec Patched
Works with Both KK n LP Roms
Hotplugs
Intelli_plug
Bricked_Hotplug aka MSM_MPDecision
MSM_Hotplug
Alucard_Hotplug
Governors
Intellidemand
Intellimm
Alucard
Hyper
Impulse
Pegasusq
Nightmare
Intelliactive
Yankactive
Smartmax
Zzmove
I/O Sched
BFQ
FIOPS
SIO
Zen
Vr
TripNdroid
CPU Overclock to 1.7Ghz
GPU Overclock to 590 Mhz
Double Tap 2 Wake
Simple Thermal Driver by @SultaXDA
Dynamic Fsync
Kcal Updates
Faux Sound
Much more
KNOWN BUGS :
LED NOT BLINKING SOMETIMES N STAYS SOLID
How to Install :
Boot into recovery
Wipe cache
Wipe dalvik cache
Flash kernel
Reboot and enjoy!
*use Kernel auditor(best) or Aero Kernel Control (full native sysfs best if you know what you are doing) to activate or tweak with kernel settings
## NOTE ##
After Flashing any Kernel Or Rom let you Phone Cool down to normal temp before you start using it. Pls dont complain the phone is heating n lagging. Flashing n things have heavy CPU usage so if will Heat.
Disable "Enable per-app Profile" if you are running benchmarks like Antutu
Downloads
Carbon kernel downloads
CARBON_KERNEL_LP_KK_25092015_1734.zip - 8.29 MB
its can be flashed on all aosp and cm based roms​
Thanx to everyone with helped me all the dev who i cherry-picked from thanx alot :angel:
XDA:DevDB Information
[KERNEL] [25/9] [LP][ KK] Carbon Kernel R5, Kernel for the Xiaomi Redmi 1S
Contributors
Tarun93, fellow kernel dev (kD a.k.a thewisenerd, zeroblade1984, LuffyXDA, armani-dev )
Source Code: https://github.com/tarunkapadia93/android_kernel_xiaomi_armani
Kernel Special Features:
Version Information
Status: Stable
Current Stable Version: R5
Stable Release Date: 2015-09-25
Current Beta Version: R4 BETA Final
Beta Release Date: 2015-06-19
Created 2015-01-23
Last Updated 2015-09-25

Setting n tweaks
daily use settings
governor = alucard
i/o scheduler = BFQ
cpu = 300 min 1689 max
Alucard Hotplug
gpu mac clk = 450
DT2W will drain battery so think before you tweak around with the kernel n end up telling me your kernel is giving me **** Battery packup
Faux Sound
dont complaint if sound distorts at loud profile
loud profile is mean for full size cans (headphones) n similar things where you need a little more power
dont switch it on if you are using IEM (in-ear earphones) or normal earphones
i normally keep a setting of
digital output gain = 3
analog output gain=5
Hope that this clears some questions n helps you guys :fingers-crossed:

msm_mpdecision
show-p1984 said:
What is msm_thermal?
What is msm_mpdecision?
100% kernel based multi core decision! (should cpu1/2/3 be online or not?)
This replaces your /system/bin/mpdecision binary which is renamed by the installer to mpdecision_bck.
Check /sys/kernel/msm_mpdecision/conf/ for the configuration.
startdelay = time until mpdecision starts doing it's magic
delay = time between checks
pause = if something else plugs in the cpu, fall asleep for 10000ms
max_cpus_online_susp = if the screen is off, how many core should be active when the screen is off
enabled = enable(1) or disable(0) mpdecision. This does not affect max_cpus_online_susp
min_cpus = min cpus to be online, cannot be < 1. Default: 1
max_cpus = max cpus to be online, cannot be > 4. (if you set it to 2 and min_cpus to 1 you will basically have a dualcore) Default: 4
idle_freq = a value against that will be checked if a core +/- is requested. (300000)
If cpu0 is below that value and a core up of another cpu is requested, nothing will happen.
If any other cpu is above that value and a core down of that cpu is requested, nothing will happen. (otherwise it would now put down that cpu even though it is still working, which isn't what we want)
Hot plug thresholds (aka now it gets 'complicated')
This small formula calculates which value will be used: (number_of_cpus_online - 1) * 2
The result of this formula will be the nwns_threshold where a new cpu is hotplugged.
The result of this formula + 1 will be the nwns_threshold where a cpu is unplugged.
nwns_threshold_x = runqueue threshold, if this is reached cpuX will be hot/unplugged
twts_threshold_x = time threshold, this amount of time must have passed for the related action to be taken (hot/unplug)
Example:
One cpu is online.
(1 - 1) * 2 = 0 ergo:
nwns_threshold_0 = cpu1 will be hotplugged at this value
((1 - 1) * 2) + 1 = 1
nwns_threshold_1 = cpu0 will be unplugged at this value
Since we can't unplug cpu0 this is '0'.
Two cpus are online.
(2 - 1) * 2 = 2 ergo:
nwns_threshold_2 = cpu2 will be hotplugged at this value
((2 - 1) * 2) + 1 = 3
nwns_threshold_3 = cpu1 will be unplugged at this value
etc...
Some values are:
NwNs_Threshold: 12, 0, 25, 20, 32, 28, 0, 35
TwTs_Threshold: 140, 0, 140, 190, 140, 190, 0, 190
Where the position and function of the number equals the result of the above explained formula.
(all times are in ms)
If you want to see the mpdecision magic happening:
Code:
adb shell
cat /proc/kmsg | grep 'MPDEC'
mpdecision's input event boost, aka project butter
This will boost your min cpu speed if you touch the screen or press a button and gives you full control.
In those events the min cpu freq will be risen to a predefined value (look below) on every online cpu. This boosts overall reaction times and smoothness a lot. (works similar to the qcom mpdecision binary)
Configuration files:
[email protected]:/sys/kernel/msm_mpdecision/conf # ls | grep boost
boost_enabled
boost_freqs
boost_time
All of them work like the usual sysfs files, except one special case:
boost_freqs will list all frequencies from cpu 0 to cpu x. Cpu 3 and any following cpu will share one frequency.
To change those frequencies echo the cpu number + the frequency in khz.
Example: To change the boost freq of cpu3 (and 4,5,6,7,8, etc) the echo would look as follows:
Code:
echo "3 960000" > /sys/kernel/msm_mpdecision/conf/boost_freqs
for cpu0:
Code:
echo "0 960000" > /sys/kernel/msm_mpdecision/conf/boost_freqs
Defaults:
Code:
cat /sys/kernel/msm_mpdecision/conf/boost_freqs
960000
960000
729600
576000
Why do I have no WLAN?
Due to this kernels very high optimization settings it is too big for our boot.img with WLAN included into the kernel, so it is built as a module. That means it needs to be inserted into the kernel upon boot up, which needs to be automated for maximum comfort.
​
Click to expand...
Click to collapse
enabling n disabling a hotplug is simple
1 = enabled
0=disabled
to disabling a hotplug here is a example via terminal
Code:
echo "0" /sys/kernel/msm_mpdecision/conf/enabled
you can use third party apps too to make it a macro
i like aero kernel control available in the playstore
goto misc settings
tap "+" sign
navigate to the path you want n set the parameter as a macro
msm_hotplug
enabling n disabling msm_hotplug
/sys/module/msm_hotplug/enabled
other parameters
/sys/module/msm_hotplug/
msm_mpdecision
enabling n disabling the msm_mpdecision
/sys/kernel/msm_mpdecision/conf/enabled
other parameters
/sys/kernel/msm_mpdecision/conf/
intelli_plug
enabling n disabling the intelli_plug
/sys/module/intelli_plug/parameters/intell_plug_active
other parameters
/sys/module/intelli_plug/parameters/
MAKE SURE YOU DISABLE THE OTHER HOTPLUGS BEFORE YOU ENABLE ONE
if you enable intelli_plug make sure bricked_hotplug and msm_hotplug are disabled
if you enable msm_hotplug make sure bricked_hotplug n intelli_plug are disabled
bricked_hotplug is enabled by default as i feel its the best daily driver for max sot n battery life without compromising on performance
The zip adds module insertion to your ramdisk, if that fails for some reason the wlan module cannot be inserted.
if
Code:
adb shell lsmod
doesn't show this:
Code:
tun 14701 0 - Live 0x00000000
cifs 275399 0 - Live 0x00000000
bcmdhd 2964650 0 - Live 0x00000000 (C)
Then something went horribly wrong.
Chances are that I broke it and this should never happen.
One post in the issue tracker will probably fix it with the next release
You can restore wlan for your current bootup by executing:
Code:
adb shell
su
insmod /system/lib/modules/bcmdhd.ko

Thanks. Downloading. Gonna try asap. Will leave feedback.

bhu1 said:
Thanks. Downloading. Gonna try asap. Will leave feedback.
Click to expand...
Click to collapse
which rom are you trying it out on ??? pls mention the ROM if you can guys

Tarun93 said:
which rom are you trying it out on ??? pls mention the ROM if you can guys
Click to expand...
Click to collapse
Flashed it on cm11 RC16 for now, everything seems swift and smooth for now. Gonna leave more feedback soon on CM11 RC16.
Tomorrow I'll move to carbon RC6, will provide more feedback then.
Now, I'm gonna go and play around with the settings. Heh.
---------- Post added 24th January 2015 at 12:07 AM ---------- Previous post was 23rd January 2015 at 11:35 PM ----------
So, I played around with some settings and I found a bug. Sweep2Sleep (Also Sweep2Wake) isn't properly implemented, neither is it working nor are its settings proper. https://app.box.com/s/q58sztnn0y8eizuu0go99jlizyngnn3m
Edit : So, I tried the wake settings in trickster mod and when I selected s2w+s2s then s2s is working but s2w is just not working, I tried swiping in many ways, many many times but Its just not working. Also, if u select just s2s then it just reverts back to s2w+s2s probably because s2s isn't working.
I did a standard test I do with all kernels that I try (I have tried all the latest versions of all kernels that are currently available), I close every app that is running in background using greenify, CPU is set to 1.6ghz - 300 MHz, intelliplug (eco mode disabled in urs, no other has eco mode, I use mp-decision on those which doesn't have intelliplug), on demand governer, GPU set at Max (550 on urs and beast kernel and 450 on others) and I play a 720p hevc video, on ur kernel i was getting the smoothest playback among all (It was lagging for the least amount of time, same lag times as beast kernel, so might be just cause of OCd GPU). But in any case, currently this kernel is the best performing and feature rich kernel available. Period.
I'll try other settings (especially eco mode), and will leave further feedback soon.
Thanks, I await further updates. Loving the increasing amount of kernels on our forums.

bhu1 said:
Flashed it on cm11 RC16 for now, everything seems swift and smooth for now. Gonna leave more feedback soon on CM11 RC16.
Tomorrow I'll move to carbon RC6, will provide more feedback then.
Now, I'm gonna go and play around with the settings. Heh.
---------- Post added 24th January 2015 at 12:07 AM ---------- Previous post was 23rd January 2015 at 11:35 PM ----------
So, I played around with some settings and I found a bug. Sweep2Sleep (Also Sweep2Wake) isn't properly implemented, neither is it working nor are its settings proper. https://app.box.com/s/q58sztnn0y8eizuu0go99jlizyngnn3m
Edit : So, I tried the wake settings in trickster mod and when I selected s2w+s2s then s2s is working but s2w is just not working, I tried swiping in many ways, many many times but Its just not working. Also, if u select just s2s then it just reverts back to s2w+s2s probably because s2s isn't working.
I did a standard test I do with all kernels that I try (I have tried all the latest versions of all kernels that are currently available), I close every app that is running in background using greenify, CPU is set to 1.6ghz - 300 MHz, intelliplug (eco mode disabled in urs, no other has eco mode, I use mp-decision on those which doesn't have intelliplug), on demand governer, GPU set at Max (550 on urs and beast kernel and 450 on others) and I play a 720p hevc video, on ur kernel i was getting the smoothest playback among all (It was lagging for the least amount of time, same lag times as beast kernel, so might be just cause of OCd GPU). But in any case, currently this kernel is the best performing and feature rich kernel available. Period.
I'll try other settings (especially eco mode), and will leave further feedback soon.
Thanks, I await further updates. Loving the increasing amount of kernels on our forums.
Click to expand...
Click to collapse
Hey plz comment on the battery life, SOT also.... Thnx

bhu1 said:
So, I played around with some settings and I found a bug. Sweep2Sleep (Also Sweep2Wake) isn't properly implemented, neither is it working nor are its settings proper. https://app.box.com/s/q58sztnn0y8eizuu0go99jlizyngnn3m
Edit : So, I tried the wake settings in trickster mod and when I selected s2w+s2s then s2s is working but s2w is just not working, I tried swiping in many ways, many many times but Its just not working. Also, if u select just s2s then it just reverts back to s2w+s2s probably because s2s isn't working.
Click to expand...
Click to collapse
This is what happens when you don't read the phuxking documentation.

thewisenerd said:
This is what happens when you don't read the phuxking documentation.
Click to expand...
Click to collapse
What do u mean by 'Documentation' ? If u inferring that I didn't read the OP, then I'll inform that I properly read it before flashing the kernel, it says nothing about this. I did notice that the feature list says 'Sleep 2 Sleep' instead of 'Sweep 2 Sleep' but nothing else. What am I missing here, buddy ?

bhu1 said:
What do u mean by 'Documentation' ? If u inferring that I didn't read the OP, then I'll inform that I properly read it before flashing the kernel, it says nothing about this. I did notice that the feature list says 'Sleep 2 Sleep' instead of 'Sweep 2 Sleep' but nothing else. What am I missing here, buddy ?
Click to expand...
Click to collapse
S2w work from bottom left to right,while s2s work from bottom right to left
press thanks if i helped you

Hsmetric181 said:
S2w work from bottom left to right,while s2s work from bottom right to left
press thanks if i helped you
Click to expand...
Click to collapse
I know that, S2W isn't working in any case.

Great Work.
Using this kernel currently with CM R16, everything is working fine.
Battery life is excellent for me. After nearly 15h - there is still 72% battery left. Usage: Screen on: 30 min, Wifi, Bluetooth always enabled.
Only thing so far is that Netflix is not working, but this might be totally Rom related, as it was also not working with the orginal kernel.

bhu1 said:
I know that, S2W isn't working in any case.
Click to expand...
Click to collapse
only s2w wouldnt work s2s n s2w both with be enable together

Thanks for this kernel tarun...really a great one...every thing works awesome...just by using trickstar mod...and this kernel is working for me on PAC latest nitly...just have to flash kernel comparability patch updated!!! Lol

little warm
is this only for me or not, but i feel little warm when using this kernel on carbon. and thats make battery reduce faster.

justian said:
is this only for me or not, but i feel little warm when using this kernel on carbon. and thats make battery reduce faster.
Click to expand...
Click to collapse
fir the first start yes it is let it cool down for a while n you are good to go it wont heat there after

is this working on Mokee 4.4.4 Nightly?

I cant turn the zram off. If i turn it off and save it emidiately gets turned on again. Am i doing something wrong?

everything is working for me guys.
bhu1 said:
I know that, S2W isn't working in any case.
Click to expand...
Click to collapse
S2W is also working properly for me. I am on CM11 RC16.

Tarun93 please mention the settings for best battery and best performance separately please coz I play games a lot and I want to get max battery when I'm not gaming .