Develop Bugs

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

[How to]--->Simple Guide to Better Battery Life

Battery Life on a SmartPhone - The Riddle, The Enigma
I have been asked to port my original Battery Guide over to the SGS3 threads, so here it is in all it's glory.​
This thread was also recently featured on the XDA Portal. Thanks to Haroon Q. Raja for the write up.​
Attaining 20+ hours of battery life is not only possible it is totally attainable with most phone configurations. The secret to making this happen is, understanding what are the contributing factors are and knowing what to do first.
This guide will help. After reading this guide, you will be able to understand how to end power eating culprits and answer those same questions we see over and over in the threads...... that is .... solving the passive battery drain and get the 20 hours of battery life we all want and desire.
As we all know, all Samsung Galaxy S 3's and their Chipsets are not created equal. So if something works for one person and not the other, then is it a software, hardware or human error. Chances are it is a combination of all three. Hopefully this can slim those down a bit and answer some questions that you might have or have seen. I have tried to get almost everything I can think of and put it in one place.
You can click on the Post # below and it will take you directly to that post if you wanted to skip some things (although I don't know why you would want to do that)
Post 1: Tips and Tricks
Post 2: Roms/Kernels, OverClocking/Undervolting, Governors & I/O Schedulers
Post 3: Memory Management
Post 4: Apps (for your download pleasure)
Post 5: Proof
I will be using satirical stories and anecdotes to get my point across below. Not meant to offend or point fingers at anyone. I am just using real life references to get to the point. Also I am not much for fancy colors. I tried it at the top here but not so much further down. If there is something specific I want to call attention too, I will BOLD it and maybe RED it too.
This is not a GUIDE to get better battery life but rather a GUIDEline to get it. What is the difference, you say? A Guide is a step by step process that you must/should follow to get the outcome that the person who created it wanted you to get [A+B+C+D should = E]. A Guideline is more of a recommendation that allows some choice or flexibility in the understanding, execution or use [A +B-(C+D) can = E].
TopShelf10 has this to say about getting the most out of your battery life
the problem is, people want to believe that they can save battery without changing their usage habits. this simply is not possible. no rom or kernel will realistically do this for you. if you remove 1 brick from a bag full of 15 bricks, the bag will be lighter, but still very heavy. you need to download "spare parts" or "process monitor" from the market and start analyzing the way your apps are acting. also look into data syncs that are happening in the background. apps that stay open behind your back/what they are doing 9an app called "autostarts" can prevent apps from self-running under certain scenarios). animation speed. polling for notifications. gps. wifi scans. overclocking. cpu/ram usage. proper sleep. widgets. brightness. 2g/3g. data usage. call time. text volume. - THESE are the things that really affect your battery life.
bottom line is, if you truly want to save battery you are going to have to get your hands dirty...there simply isnt a one-click (or one-flash) solution.
Click to expand...
Click to collapse
Below is a list of fundamental things that can be done without rooting or custom ROM/Kernels. (Standard disclaimer applies: You use it, you set it and you are responsible)
1. Be Realistic -
Do you really think that you can get two whole days out of your battery? If you do, then you must have a very important pile of papers it is sitting on to not even pick up your phone for that long. These are phones. These are mini-computers. These are arcade games. And they want, dare I say, need to be played with, talked on or downloaded to. USE YOUR PHONE.
2. Syncing –
I know you are very important and you need to know what LeBron is doing right now, just in case you get a cup for a coffee and he might be in Starbucks at the same time and you get your picture taken with him and upload it to Facebook, Twitter or Google+. That is fine and I applaud you for it and will probably download the picture and Photoshop myself in your place. This is not the problem. Syncing your accounts is. That is what is causing battery drain. Do you really need to have your FB widget (see widgets section) streaming all day long? Does Kim K.’s endorsement of a potato chip really affect your everyday life? I doubt it. Kill them (not LeBron or Kim K. but rather the auto-syncing). Every time you “friend” someone their numbers, contact info gets sync’d to your phone. Also, there are settings in Facebook, Twitter and Google+ that you can upload pictures instantly. Don’t do that. Once you do, it is out in the Ether-World and just swallowed a bunch of battery doing it too.
Settings>Accounts and Sync>Auto-sync>uncheck it
3. Widgets –
They look cool. But widgets are nothing more than RAM and battery hungry monsters that you purposely put in your home screen. Think about it. What does a widget really do? All it really does is monitor an app that you have running. So not only is it running and taking up battery and RAM but the app that it is linked to is running in the background al’ a Facebook, Twitter, Google+, CNBC, MSNBC, BBC,… the list goes on and on because they want us to put THEM on our home page.
What a great marketing campaign the widget is.
“Hey look at me new home screen”
“Cool. Hey what widget is that?”
“Oh, it is X”
“Nice, I’ll have to download that tonight when I get home” and then and there they have you and your battery.
4. Apps –
You have to pay attention to your apps. I repeat. You have to pay attention to your apps. Especially if they run in the background. This can be anything from a harmless .99c game to a monster like Live Wallpaper. The battery drain threat is twofold here because the app is running in the background but it could also be using its anonymous data collection abilities and sending that back to the Mothership. Ever wonder why you have a 4/3G with up and down arrows in your status bar when your phone is just sitting there? This is because some app is transmitting data, whether you are using it or not. There are apps in the market that monitor these situations like Watchdog or kill the data link when the lock screen is enabled like Juice Defender (see Apps below) or you can adjust app permissions like LBE Privacy Guard. Data transfer is #2 on the What Kills My Battery list.
5. Display/ Wifi/ Airplane Mode/ Animations/ Location –
Display:
#1 when it comes to what is eating your battery. Always has been and always will be. Accept it and try to do something about it. This part is easy. Just lower the brightness. You can use Auto or set it as a brightness that is low but you are still able to see well enough to function. Live Wallpapers fall into this category. They are cool to look at but static ones take up less RAM and also less display because they are not running all the time in the background. These screens are bright at 100%, so tone it down. (see Apps below).
WIFI:
Another helpful tip is setting your WIFI sleep policy to Always. This can be done by going here Setting>Wireless>WIFI> Menu key>Advanced>WIFI Sleep Policy and set it to Always.
--->Then you can also do this Build.Prop edit as well (this is if you are Rooted, of course)
Allows your wifi to scan less, saving more battery:
wifi.supplicant_scan_interval=240 (I have mine set to 420)
Airplane Mode Toggle:
DocHoliday77 has this very helpful trick regarding Airplane Mode and how it effects your Data/Battery life.
I generally suggest toggling Airplane Mode on/off as a recommended step before running data speed tests, and to help with signal strength.
When you move from one area to another, generally your phone will automatically switch to another tower as the signal/connection to the current tower degrades. This is perfectly fine while travelling since you are not in a single location for very long. The problem comes into play once you have reached your destination. For many people, when they get home from work, for example, their phone will remain connected to the last tower they switched to on their drive home. However, there is very often a tower closer to their home that can provide better signal. The phone does not automatically switch to the better tower because it is still close enough to the current one to have adequate signal. By toggling Airplane Mode on/off, when the radio turns back on it will search for the strongest signal and will now connect to the closer, better tower!
Stronger signal will directly translate to a better battery. The better your signal, the less power is consumed for ALL radio operations (Including Cell Standby, Data, and Voice)! When the signal is weak, the radio requires more power to transmit to the receiver (the tower), which translates to higher battery use.
Toggle Airplane Mode on then off again to force the phone to connect to the best possible tower.
Animations: Set Settings > Display > Animations to .5 animations.
Location:
As pointed out by Arlanthir if your device is broadcasting your location, then you may need to rethink whether or not that is good for you and your battery. Generally, your location is based off GPS, Wifi or Mobile Networks. If these are on, then battery drain is occurring. Sometimes you need your location to work with Maps, Google Now, but most of the time, it is because of the unholy trinity, Facebook, Twitter and Google+. I mean, how do you think you "Check-In' at places right?
If you don't utilise these types of features on those three, then go into Settings>Location and untick them. Now there are also other apps like MLB At-Bat and the like that require location for blacked out games or services based on your location. I find that there is always a toast in those applications that notifies me and allows me to turn then on as needed. Then when I am done, I can turn them off.
These are 5 fundamental things that you can do to help reduce battery drain and get some more life out of your phone. Anyone can do these. All you have to do is watch your phone and use some common sense. “Why does my battery drain after only 6 hours? All I was doing was checking Facebook.” Do you really need to be on Facebook for that long of a time? I doubt it. How many services do you have running? How many tasks do you have running? (Android does a good job of shutting down tasks on its own, but if you are using a task killer, it takes more juice to start up an app than to turn it back on, so to say.) Think of it like an airplane. Takes more fuel to get up in the clouds, but once you are up there, it is pretty much coasting along with way less burn.
*******************
A special thanks to DocHoliday77 for convincing me to port this over and also for some of his helpful tips as well. You know who he is, so hit his thanks button to show your appreciation for all he does for this community.

ROMs are key things to think about when it comes to battery life. They can be fully established and working fine, can be RCs and still in development or they can be Alpha/Betas and completely experimental or just beginning. Choosing the best ROM or Kernel is going to depend on what YOU want out of your phone. Do you want a stable 4.0 ROM that has great battery life but not the customizability as MIUI or CM10 or AOKP? Because we have so many versions of 4.0.x ROMs that are official and almost all the sources have been attained, they have been Optimized to their fullest and some outstanding tweaks have really brought them to the forefront in daily drivers. Again, the choice is up to you.
Kernels go hand-in-hand with your ROM. Does the kernel support Overclocking or Undervolting. How much RAM and what tweaks are included in the kernel? Does THIS kernel work with THAT ROM? These are all spelled out for you in the OP of each kernel (and ROM) for you to find out. Read them because if you don’t, you’ll bork your phone and then your next post will be, “Help. I Bricked my phone”.
Overclocking/Undervolting –
If you don’t already know what Overclocking is, well it is pretty much self-explanatory. You can Overclock your CPU above the clock-speed that Samsung, T-Mobile governed it at. This can be done with apps like SetCPU (here and here and CPUtuner,…Generally have to be ROOTed to do these but if you are flashing ROMs and Kernels then you probably already are. UnderVolting is basically what it sounds like too. You are Undervolting your CPU to conserve battery.
This can be one of the best ways for a more advanced user to save battery. Overclocking is great to see those really cool Quadrant scores. Wow!!! But it also ramps up the battery drain, as well as temperature which can shorten your battery’s TOTAL life. If you want to Overclock to 1.8-2.1 just to see what you score on Quadrant or SmartBench, then do it for that time. Most ROMs/Kernels run stable and smooth at or about 1.2-1.6 with minimal effects on battery (as long as you do tweaks in above post). If you decide to Undervolt you can use Pimp My CPU, Voltage Control, SetCPU,... to do this but take care to step it down slowly until you find the right settings for you or you will see random reboots or phone freezes and those suck trying to diagnose.
***Please note that whether you Overclock or Undervolt, do NOT “Set on Boot” until you know that they are going to work. Otherwise if it doesn’t work and your phone randomly reboots, you will get into a boot cycle (not a bootloop) because you put them in “Set on Boot”. You must test before you should do this.***
Example scale of OC/UV setting from Ktoonsez' thread:
[KERNEL][TMO][AOSP/Touchwiz][JELLYBEAN & ICS][10/31/2012] KT747 - LJ7 - KTweaker
Stock___________________Undervolt startoff point___________________jerrygooch
Mhz - mV___________________Mhz - mV___________________________Mhz - mV
1890 - 1300___________________1890 - 1300____________________________1890 - 1200
1809 - 1275___________________1809 - 1250____________________________1809 - 1150
1728 - 1250___________________1728 - 1200____________________________1728 - 1100
1674 - 1200___________________1674 - 1175 ____________________________1674 - 1075
1512 - 1200___________________1512 - 1200 ____________________________1512 - 1075
1458 - 1187___________________1458 - 1187 ____________________________1458 - 1050
1404 - 1187___________________1404 - 1187 ____________________________1404 - 1050
1350 - 1175___________________1350 - 1175 ____________________________1350 - 1025
1296 - 1175___________________1296 - 1175 ____________________________1296 - 1025
1242 - 1150___________________1242 - 1150 ____________________________1242 - 1000
1188 - 1150___________________1188 - 1150 ____________________________1188 - 1000
1134 - 1125___________________1134 - 1125 ____________________________1134 - 975
1080 - 1125___________________1080 - 1125 ____________________________1080 - 975
1026 - 1075___________________1026 - 1075 ____________________________1026 - 925
972 - 1075____________________972 - 1075 _____________________________972 - 925
918 - 1050____________________918 - 1050 _____________________________918 - 900
864 - 1050____________________864 - 1050 _____________________________864 - 900
810 - 1025____________________810 - 1025 _____________________________810 - 875
756 - 1025____________________756 - 1025 _____________________________756 - 875
702 - 975_____________________702 - 925 ______________________________702 - 825
648 - 975_____________________648 - 925 ______________________________648 - 825
594 - 950_____________________594 - 850 ______________________________594 - 800
540 - 950_____________________540 - 850 ______________________________540 - 800
486 - 925_____________________486 - 850 ______________________________486 - 800
384 - 925_____________________384 - 825 ______________________________384 - 800
192 - 900_____________________192 - 825 ______________________________192 - 800
Governors and I/O Schedulers
Governors and I/O schedulers also have a huge impact on how your CPU regulates.
Here is about everything you need to know about them from Recognized Contributor droidphile from his thread:
[REF][TWEAKS] Kernel Governors, Modules, I/O Schedulers, CPU Tweaks, AIO App Configs .
If you haven't checked out his thread do yourself a favor and do it. A vast amount of information. Be sure to hit his THANKS too.
Governors
I) MANUAL:
These are the 19 governors we're talking about.
1) Ondemand
2) Ondemandx
3) Conservative
4) Interactive
5) Interactivex
6) Lulzactive
7) Lulzactiveq
8) Smartass
9) SmartassV2
10) Intellidemand
11) Lazy
12) Lagfree
13) Lionheart
14) LionheartX
15) Brazilianwax
16) SavagedZen
17) Userspacce
18) Powersave
19) Performance
NOTE: Info on Samsung's own multi-core aware governor - Pegasusq is here
1) Ondemand:
Default governor in almost all stock kernels. One main goal of the ondemand governor is to switch to max frequency as soon as there is a CPU activity detected to ensure the responsiveness of the system. (You can change this behavior using smooth scaling parameters, refer Siyah tweaks at the end of 3rd post.) Effectively, it uses the CPU busy time as the answer to "how critical is performance right now" question. So Ondemand jumps to maximum frequency when CPU is busy and decreases the frequency gradually when CPU is less loaded/apporaching idle. Even though many of us consider this a reliable governor, it falls short on battery saving and performance on default settings. One potential reason for ondemand governor being not very power efficient is that the governor decide the next target frequency by instant requirement during sampling interval. The instant requirement can response quickly to workload change, but it does not usually reflect workload real CPU usage requirement in a small longer time and it possibly causes frequently change between highest and lowest frequency.
2) Ondemandx:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
3) Conservative:
A slower Ondemand which scales up slowly to save battery. The conservative governor is based on the ondemand governor. It functions like the Ondemand governor by dynamically adjusting frequencies based on processor utilization. However, the conservative governor increases and decreases CPU speed more gradually. Simply put, this governor increases the frequency step by step on CPU load and jumps to lowest frequency on CPU idle. Conservative governor aims to dynamically adjust the CPU frequency to current utilization, without jumping to max frequency. The sampling_down_factor value acts as a negative multiplier of sampling_rate to reduce the frequency that the scheduler samples the CPU utilization. For example, if sampling_rate equal to 20,000 and sampling_down_factor is 2, the governor samples the CPU utilization every 40,000 microseconds.
4) Interactive:
Can be considered a faster ondemand. So more snappier, less battery. Interactive is designed for latency-sensitive, interactive workloads. Instead of sampling at every interval like ondemand, it determines how to scale up when CPU comes out of idle. The governor has the following advantages: 1) More consistent ramping, because existing governors do their CPU load sampling in a workqueue context, but interactive governor does this in a timer context, which gives more consistent CPU load sampling. 2) Higher priority for CPU frequency increase, thus giving the remaining tasks the CPU performance benefit, unlike existing governors which schedule ramp-up work to occur after your performance starved tasks have completed. Interactive It's an intelligent Ondemand because of stability optimizations. Why??
Sampling the CPU load every X ms (like Ondemand) can lead to under-powering the CPU for X ms, leading to dropped frames, stuttering UI, etc. Instead of sampling the CPU at a specified rate, the interactive governor will check whether to scale the CPU frequency up soon after coming out of idle. When the CPU comes out of idle, a timer is configured to fire within 1-2 ticks. If the CPU is very busy between exiting idle and when the timer fires, then we assume the CPU is underpowered and ramp to max frequency.
5) Interactivex:
This is an Interactive governor with a wake profile. More battery friendly than interactive.
6) Lulzactive:
This new find from Tegrak is based on Interactive & Smartass governors and is one of the favorites.
Old Version: When workload is greater than or equal to 60%, the governor scales up CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step. When screen is off, frequency is locked to global scaling minimum frequency.
New Version: Three more user configurable parameters: inc_cpu_load, pump_up_step, pump_down_step. Unlike older version, this one gives more control for the user. We can set the threshold at which governor decides to scale up/down. We can also set number of frequency steps to be skipped while polling up and down.
When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. When workload is less than inc_cpu_load, governor scales CPU down pump_down_step steps down.
Example:
Consider
inc_cpu_load=70
pump_up_step=2
pump_down_step=1
If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800.
If current frequency =1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.
7) Lulzactiveq:
Lulzactiveq is a modified lulzactive governor authored by XDA member robertobsc and is adapted in Siyah kernel for GS2 and GS3. Lulzactiveq aims to optimize the second version of luzactive from Tegrak by a) providing an extra parameter (dec_cpu_load) to make scaling down more sensible, and b) incorporating hotplug logic to the governor. Luzactiveq is the first ever interactive based governor with hotplugging logic inbuilt (atleast the first of its kind for the exynos platform). When CPU comes out of idle loop and it's time to make a scaling decision, if load >= inc_cpu_load CPU is scaled up (like original luzactiveq) and if load <dec_cpu_load, CPU is scaled down. This possibly eliminates the strict single cut-off frequency for luzactiveq to make CPU scaling decisions. Also, stand hotplug logic runs as a separate thread with the governor so that external hotplugging logic is not required to control hotplug in and out (turn On and Off) CPU cores in multi core devices like GS2 or GS3. Only a multi core aware governor makes real sense on muti-core devices. Lulzactiveq and pegasusq aims to do that.
8) Smartass:
Result of Erasmux rewriting the complete code of interactive governor. Main goal is to optimize battery life without comprising performance. Still, not as battery friendly as smartassV2 since screen-on minimum frequency is greater than frequencies used during screen-off. Smartass would jump up to highest frequency too often as well.
9) SmartassV2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery.
10) Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors )
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
11) Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.
12) Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.
13) Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source. Tweaks comes from 1) Knzo 2) Morfic. The original idea comes from Netarchy. See here. The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
To 'experience' Lionheart using conservative, try these tweaks:
sampling_rate:10000 or 20000 or 50000, whichever you feel is safer. (transition latency of the CPU is something below 10ms/10,000uS hence using 10,000 might not be safe).
up_threshold:60
down_threshold:30
freq_step:5
Lionheart goes well with deadline i/o scheduler. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand.
14) LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
15) Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery.
16) SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
17) Userspace:
Instead of automatically determining frequencies, lets user set frequencies.
18) Powersave:
Locks max frequency to min frequency. Can not be used as a screen-on or even screen-off (if scaling min frequency is too low).
19) Performance:
Sets min frequency as max frequency. Use this while benchmarking!
So, Governors can be categorized into 3/4 on a high level:
1.a) Ondemand Based:
Works on "ramp-up on high load" principle. CPU busy-time is taken into consideration for scaling decisions. Members: Ondemand, OndemandX, Intellidemand, Lazy, Lagfree.
1.b) Conservative Based:
Members: Conservative, Lionheart, LionheartX
2) Interactive Based:
Works on "make scaling decision when CPU comes out of idle-loop" principle. Members: Interactive, InteractiveX, Lulzactive, Luzactiveq, Smartass, SmartassV2, Brazilianwax, SavagedZen.
3) Weird Category:
Members: Userspace, Powersave, Performance.
I/O Schedulers
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.
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.
Some Kernel Settings from Users out "there" (Note: These are for the SGS3 kernels):
Swifks using LeanKernel (4.3 kernel/4.2 OS):
Swiftks said:
Just thought I'd share my settings:
Governor: InteractiveX
Custom Settings:
go_hispeed_low = 95
screen_off_maxfreq = 486000
Scheduler: ROW
Min: 192 MHz
Max: 1512 MHz
Frequency Lock: ON
MP-Decision: OFF
Multicore Power Saving: 1
GPU Governor: On Demmand
GPU Max Frequency: 480
Voltages:
192 MHz = 775mv
384 MHz = 800mv
486 MHz = 800mv
594 MHz = 825mv
702 MHz = 850mv
810 MHz = 900mv
918 MHz = 950mv
1026 MHz = 1000mv
1134 MHz = 1025mv
1242 MHz = 1050mv
1350 MHz = 1075mv
1458 MHz = 1100mv
1512 MHz = 1125mv
Enjoy
Sent from my SGS III
Click to expand...
Click to collapse
liltitiz from his thread [KT747: Share & discuss your settings]+[govs & scheds info] using ktoonsez' KT747 kernel.
Post is here
liltitiz said:
With my new settings I can get up to 5-6 hour of screen on with a discharging time of around 24 hours. Before I start playing with cpu1, I couldn't get more than 4hours of screen on with a discharging time around 15hours since the Linux 3.4 kernel
Note that I also use greening to hibernate apps and Tasker to turn on things like gps, data, wifi, auto rotate only when I need them.
I readjusted my settings yesterday to test something out if you got no loss in performance yet you can try them out:
Ktoonservative setup to input in ktweaker:
Boost 2nd core on button:0
Boost cpu:540
Boost gpu: doesn't matter
Boost hold cycle :0
Boost turn on 2nd core:0
Cpu down block cycle:0
Down threshold:75
Down threshold hotplug:60
Freq step:3
Ignore nice load:0
No 2nd cpu screen off:1
Sampling down factor:3
Sampling rate: 25000
Sampling rate screen off: 45000
Up threshold:94
Up threshold hotplug:96
---------------------------------------------------
Command lines to apply my asswax settings on cpu1 :
echo asswax > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo 135000 > /sys/devices/system/cpu/cpufreq/asswax/awake_ideal_freq
echo 200 > /sys/devices/system/cpu/cpufreq/asswax/down_rate_us
echo 189000 > /sys/devices/system/cpu/cpufreq/asswax/interactive_ideal_freq
echo 95 > /sys/devices/system/cpu/cpufreq/asswax/max_cpu_load
echo 65 > /sys/devices/system/cpu/cpufreq/asswax/min_cpu_load
echo 250000 > /sys/devices/system/cpu/cpufreq/asswax/ramp_down_step
echo 50000 > /sys/devices/system/cpu/cpufreq/asswax/ramp_up_step
echo 81000 > /sys/devices/system/cpu/cpufreq/asswax/sleep_ideal_freq
echo 135000 > /sys/devices/system/cpu/cpufreq/asswax/sleep_wakeup_freq
echo 5000 > /sys/devices/system/cpu/cpufreq/asswax/up_rate_us
---------------------------------------------------
If you set your ktoonservative to turn off 2nd core(cpu1) when screen is off, then it doesn't matter because your cpu1.will be off so only your ktoonservative(cpu0) settings matter. Personally I use 486 as my max freq when screen is off.
Click to expand...
Click to collapse

Before we begin on the below, I must continue something about kernels from above due to character limits in posts.
A word of advice from vikas.mishra via XDA RD dorimanx in this post:
This is long INFO post from real chip designer that help to create CPU/GPU and other chips for the living for 14 years now, so respect
He sent me PM, for now he cant post that by him self.
Vikas is monitoring our thread and want to say his professional stand about UV/OV and why it's works for some and why not for others.
==================
I am calling Vikas(vikas.mishra) to the speech stand
Hello people.
Let me introduce myself - my name is Vikas Mishra and I am a chip designer by profession. .
I have worked on critical parts of design of TI OMAP4, OMAP5, Nvidia Tegra 3 etc and have been doing this for the last 14 years.
Of late - I have seen a lot of folks posting BUGS about undervolting of the GPU/CPU.
I think I can explain what are the possible issues with undervolting/overclocking in a laymans language.
It is a little long winded but I think the length is needed for providing the appropriate context.
* What is inside your Cellphone
Your cellphone is an amazing device. It is a full fledged computer
that fits into your pocket. They have all the standard components
that a computer has - except that they are all usually soldered on
the motherboard directly and are not meant to be user-servicable.
The chief components inside your cellphone are
1. Application Processor (AP)- this is the heart of a modern
cellphone. These are manufactured by many companies - the main
ones are Qualcomm, Nvidia, Samsung and Apple. The other not so
well known ones are made by Texas Instruments, ST Ericsson,
Marvell and Broadcom.
A modern AP has logic to control the camera and process the image
that it generates, to do video encoding (video recording) and
video decoding (movie watching), Audio processor etc. in addition
to the well known CPU and GPU.
2. Power Management Controller - This is the chip that is
responsible for generating and regulating the voltages that are
used by all the components on the board.
3. DRAM - not very different from the DRAM found on a PC (except
that it is lower voltage)
4. Flash - for storage
5. Touchscreen controller
6. Logic for microphone, speaker
7. Battery
One of the most complex piece of circuitry on the phone is the AP
and the power management controller.
* Circuit Basics
A modern AP has millions of circuit units called (Flip
Flops). These flip flops have two parameters associated with them
called Setup time and Hold time. More details on what a flip flop
can be found on the wikipedia at
http://en.wikipedia.org/wiki/Flip-flop_(electronics) . This is a
nice bit of bedside reading if you are interested.
A setup time roughly indicates what frequency you can run a design
or an AP at before it becomes unstable.
A hold time roughly indicates the maximum voltage till which a
design is stable.
A fully technical analysis of what is involved in these timing
parameters requires a degree in electrical engineering but in broad
terms the problem is described below.
Chip designers diligently ensure that all of the millions of the
flip flops in a chip meet the setup and hold time across a broad
range of voltages and silicon parameters. They do a pessimistic
analysis to ensure that a chip will run reliably across a wide
range of voltage/frequency combinations.
However, contrary to the popular belief, chips vary widely in their
silicon parameters. Even chips on a the same wafer and different
flip-flops within the same chip can have widely different silicon
parameters. This is why what works on one particular chip will not
work on the other chip.
Your silicon manufacturer provides a range of voltages and
frequencies across which the device can work reliably. The phone
manufacturer will further narrow down the range depending on the
other components they choose within the phone board.
* How does voltage affect the design
Reducing voltage makes the design slower and increasing voltage
makes the design faster.
So can I keep on increasing the voltage for ever and make the
circuit faster and faster. The answer is no - a point will come when
the circuit will become unreliable. This becomes unreliable because
the "hold time" of one or more of the flops will start
violating.
As you reduce the voltage of the design, the circuit will start
becoming slower. However typically it will continue to work till at
apoint it starts failing - this failure occurs due to violation of
"setup time" of one or more flops in the design.
So what happens when the setup time or the hold time of a design
fails - the answer is that it is unpredictable. Meaning suddenly if
you ask the processor what is the value of 2+2, the answer it will
provide could be unreliable - in some cases it could be 3, in some
cases it could be 4 in some cases it could be -2349783297 (a random number).
I am of course oversimplifying but I hope you get the picture.
* How does undervolting affect your phone processor
The reason undervolting is so appealing to people because they
thing that undervolting will save power and improve battery
life. While this is true in theory, in practice there is a caveat.
It will reduce the power of the chip, but the power consumed by the
phone as a whole will not improve. In some cases in fact it can
deteriorate. Let me explain.
The most power hungry part in the phone is not the AP - it is the
LCD screen. All of these screens consume a ton of power. So even
though your AP is now consuming lesser power, the overall impact to
the phone as a whole is not that much.
If you accompany undervolting with a frequency reduction (which you
should), the total time taken for doing a web page rendering (for
example) would increase. During this time the screen is on and it
has more than compensated for the power that you saved in the
AP.
You could of course come up with examples where this wouldn't
happen - but on a whole, IMHO, you should leave the voltage of the
AP/GPU/CPU to the guys who know the system best - the guys who
designed the chip and people who manufactured it.
* How does overvolting/overclocking affect your phone processor
If you want that last drop of performance from your phone and you
over clock it, at a point some of the design flops will start
violating the hold time and the design will stop working reliably.
Again, in some anecdotal cases this would work - but this is not a
reliable means/mode of working. Just because your friend's or your
first cousin's girlfriend's phone works - doesn't mean yours will
work as well.
* What are the user observable impacts of undervolting/overclocking?
It is hard to say - simply because there are so many of flops in
the design.
In some cases - you wouldn't see anything wrong with the phone
until one day you do. In some cases it will result in a SOD
immediately. In some cases it will result in your phone not waking
up reliably.
IMHO the risks of issues with undervolting/overclocking far
outweighthe potential gains you may get out of it. Usually there
is no lasting damage to the phone/AP if you overlock/undervolt but
it is possible to do it. For example, You run the phone at such a
high frequency that the chip temperature becomes more than what it
was designed for and the Silicon just fails.
So "Just say No" . Don't overclock or undervolt your phone -
leave it to the guys who really understand what they are doing.
Thanks,
Vikas
Click to expand...
Click to collapse
^*v*^*v*^*v*^*v*^*v*^*v*^*v*^*v*^*v*^
Memory Management
Did you know that you can also free up some internal memory space by just basic maintenance? You can install a Cache Cleaner from the market. I use Cache Cleaner NG (root) and CacheMate (root) which will clear your cache for you, Cache Cleaner NG will even clear your cache on your SDcard. Open Root Explorer and if you see a bunch of free floating cache files, those need to go. Wasted space. Small in the scheme of your SDcard, but still wasted.
So here we go (best part is at the bottom though):
Ok so you go into XDA on your phone, go to the themes page and look at what and how people are theming their phones or see some pix of someone's SetCPU profiles. All those develop a cache that takes up space on your phone. Now lets say that you go to the market and look through some apps or update your apps (more on this later). This also generates cache, usually up to 2-4mb. Ever try to download something from the market and it says something like "not enough space". This not needed cache may be some of the reason.
Here are some tricks and apps that some of you may know and also some tricks that I have found that I am sure most don't know about.
SOME GOOD LOW MEMORY APPS:
Cache Cleaner NG and Cache Mate (both root and free-Cache Mate has a paid but the free one works just fine.)
Diskusage (free) ~ This one will show you a graphical version of your /data/apps and also you SD card to show you exactly what is taking up so much space. You can click on that item and hit "Show" and it will take you to the app's page in Manager Applications. It also has a root function too that will allow you to see what is in /system, /cache, /data,…
Some sort of file manager to get to some things I'll mention below. (I use Root Explorer)
SOME MEMORY CLEARING TIPS AND TRICKS:
Home Launcher ~ If you have a 3rd party home launcher, see if it has the ability to long-press an icon to take you to its screen in the Manage Apps section. I use APEX and if you long-press on say Market, it takes me to the same place as is I were to go to Settings->Applications->Manage Apps->Market. Instead of all that, just long-press on the icon and BAM! it takes you there. Here you can clear out your cache for the market or delete the data (if you need to do that). Or clear the cache of the XDA app b/c you looked at too many pix.
Browsers ~ These develop cache that takes up memory and space, especially the stock browser. If you use a 3rd party, you can get the settings to clear cache, cookies, passwords,…on exit. I use Dolphin, but I am pretty sure that most have something like this on them. (side note: most 3rd party browsers once exited will not run in the background unlike the stock one)
Media ~ So you download a bunch of mp3's from the net or click on some pix and save it to your SD card. Or maybe you just felt like wiping your card and having a fresh start. Every time you reboot, you phone will scan media. No big deal, but the more you criss-cross things from PC to phone and back again, it can create a bunch of double files in your media cache on the phone. With the proper placement of .nomedia files (this prevents your media scanner from doing just that, scanning media- i.e. pix, jpegs,…Don’t place a .nomedia in your music, album art or DCIM files**bad).
Every once in a while, I'll hit the Diskusage or go to Manage apps and clear the media cache. Then I got to my file manager and the DCIM->Thumbs and delete the .Thumbnails files (should be 2). Unmount the SD card and remount to start the media scan, pull up the Gallery and wait for the thumbs to come back (depending on how many you have, this could take awhile). By doing this you can get almost 5 mb back if you have a bunch of double scans in your media folder.
AND NOW FOR SOME TIPS THAT MOST COULD NOT KNOW:
LOSTDIR - Lets say that you have your phone plugged into your PC and for some reason you, in a fit of rage, jerk the plug out without unmounting it first. This creates a file that is put into your LOST DIR folder on your SD card. Anytime you don't safely unmount the SD card, it will create a file in that folder. In the scheme of the SD card, it isn't too much, but I don't like having useless items free floating about.
Here is a good explanation of what the Lost.dir is for, seems legit, I buy it.
TOMBSTONES - So you are downloading an update from the market and for some reason your phone freezes and the Force Close-Retry-Wait doesn't work out for you. You have to do a battery pull. Frustrating I know and the memory takes a hit too. Every time you have to do a battery pull because of a freeze up or something of the like, it creates a TOMBSTONE file in /data. These are useless and can be deleted. If you are flashing ROMs and are constantly having to do battery pulls b/c market crashes or an app freezes, then you are creating a Tombstone file.
**Here is where your file manager (with root) will help. Go into /data and scroll all the way to the bottom and open /tombstone. There should be some files in there and depending on how many there are, I could be a nice chunk of wasted memory. Just select all and delete. They are not needed. Your internal memory should go up by doing this.
LOST & FOUND - Same scenario, but now go into /data/ cache or /cache and you'll see Dalvik-Cache (don’t mess with this), Lost & Found and Recovery. If you tried to download an app and it got frozen for some reason and had to do a battery pull, the apk will be free floating in there, uninstalled (free floating radical). You can delete this. While it isn't in the Dalvik-Cache folder, it is taking up space. Once you are able to download something completely and correctly from the market, it will populate into Dalvik-Cache correctly and won't be a free radical, as I like to say.

Useful Apps
These are some apps that will help you get the most of your battery life. I will put a brief descpition of them and you can also click on their names to take you directly to their market link. Note that some of these are ROOT apps and almost all of them also have PAID versions that greatly expand their functionality. Use the free ones and see how you like them and then kick in for the PAID ones if you want. The only one that I really suggest paying for right out of the gate to get the most out of your battery is Juice Defender Plus.
Tasker –
Paid app from the Market. This app is highly technical and not for noobs. Use at your own risk.
I would love for some of you out there to give me your Tasker Battery Saving Profiles. Either put them in the thread here or PM to me directly.
Here is a thread about how it works by brandall:
[TUT] The Ultimate Noob/Beginners Guide to Tasker
Greenify –
XDA Thread is here: READ IT (at the very least, read the OP)
This app is probably one of the best battery saving apps that has come out in quite a long time. It allows you to "Hibernate" apps that are not being used at the time, get them out of the foreground and prevents them from running when not in use, thus eating battery.
It is really easy to use. All you have to do is fire it up, grant Root and then select the apps that you want to "Hibernate". (Note: be very careful what types of apps that you do this with, i.e. /system/apps, as it could cause adverse effects like missed notifications, missed SMS/MMS, misbehaving apps,...you get my point I hope).
Batstat Widget –
I know, I know. Above I said that widgets were nothing more that monitoring apps on your home page, but this one works great, has low memory and is very, very simple. It shows Charge in %, Volts to know when you are FULLY charged and Temperature F/C to tell you that your phone is getting hot and exactly how hot it is.
BetterBatteryStats –
This app will show you what exactly is eating at your battery. Processes, Running Services, Wakelocks, Partial Wakelocks. It is a PAID app but for XDA users it is free. See here for more extensive details, instructions, screenies, change-logs,... and credits go to Chamonix and his development team for this app.
JuiceDefender (Plus) [Since I use JD+, that is what I am going to refer too.]
–
This app’s ability to kill Radio/Data has NO EFFECT on phone calls or messaging. You will still get that call in the middle of the night you were expecting.
If you set it to custom, the go into the settings tab on the right and then all the way at the bottom, there is two buttons to push, The first in Interactive which will pull up Juice Defender for up for any app that isn't already configured and the other is Configure Apps. This is the one that you can customize on an app-to-app basis where if you are no using an app and the screen is locked, it kills the radio/data traffic for that app.
Say you are listening to IHeartRadio, this you would want either Enable or Enable/off (which means the screen will be locked but the radio/data will be working). Now take the browser. If you are not using the browser, then you don't need it transmitting data right? So you would set that one to Enable (which means that it will only enable data traffic when that app is being used).
Juice Defender only works when the screen is locked (WidgetLocker lock screens interfere with JuiceDefender), don't forget and all widgets are battery drains b/c all they really are is a monitoring app and if it is tied to something like Facebook or Google+, then that data will be running constantly.
Settings:
Enable = Radio/data on when app is in use (front)
Enable/off = Radio/data on for background apps (when screen is locked)
Disable = Disables radio/data traffic completely when that app is running
Do Nothing = What is says
Examples:
Angry Birds = Disable (Here is a little known trick that I use for this and any game with Ads. With this and something like Adfree, no more ads in Angry Birds even though the ads are embedded in the .apk)
Pandora/Jango/ Tune-in = Enable/Off (this will keep your battery temp down when streaming)
Browser/ Market = Enable (not enable/off b/c then it will keep your radio/data open)
Beautiful Widgets = Enable/off
mClock/Clockr = Enable/off
SMS/MMS = Enable or Do Nothing (why would you push disable)
I have been using JD+ for over a year on 3 different phones and multiple ROMs and have noticed a considerable difference in battery life. Just takes some time to figure out YOUR settings and what YOU like. I have also used it on Stock kernel and had no problems either.
Here are my personal setting but I am on JD+ and not Ultimate
Profile - Customize
Notification - Graphical
Settings
Mobile Data and WIFI both Enable
Options - Auto Disable
Location - Disable
Schedule -Enable --->2hrs
Night Enable --->12a to 9a (user take priority)
Apps --.Set to Interactive
E = Enable
ESo = Enable/Scrren Off
D = Disable
DN = Do Nothing
At-Bat12 = ESo
IHeartRadio = ESo
Jango = ESo
Sticher = ESo
Dolphin = E
Google Play Store = E
Messaging = E
Twitter = E
XDA pre = E
Zedge = E
Angry Birds (all variants) = Disable --->You get no ads this way wink wink
These are all Do Nothing
Addfree
Apparatus
BW
Betterbatterystats
Cachemate
Elixir
Fasterfix
FlickGolf
Google Search
Maps
Moboplayer
PowerAmp -->I can listen to music without it looking for Album Art b/c it is set to do nothing, so one of the above apps take priority and when the screen is off, data is off when I am listening to music
Quadrant
Blah, blah, blah you get the idea.
If you have every app you own and in the phone set to do "something", then you are going to run into priority issues when multi-tasking which will kill your battery for 1 b/c it is opening and closing radios and 2 for the RAM it is taking to figure out which priority take the lead. Hence why I have so many set to Do Nothing.
LBE Privacy Guard –
There may or may not be some issues with this app and Jelly Bean, so make sure you read the Market Comments and hit their website to make sure. Thanks to mypenismighty for the tip.
This will go good with JuiceDefender, as they both prevent unwanted data transfer. Protect your privacy by controlling the permission of each application to access your sensitive data. Block malicious operation from Mal-wares and Trojans. Block unwanted network traffic if you don’t have a unlimited data plan. Find out which application is trying to steal your privacy by checking the security log.
RAM Munchers eat battery too. These will fix that for you.
Autostarts (paid-CAUTION this is for advanced users) –
Keep control over your phone: See what applications do behind your back.
Shows you what apps run on phone startup, and what other events trigger in the background. Root users can disable unwanted autostarts and speed up their phone boot.
Watchdog –
See what is eating your RAM. Hint: if it is using RAM,then probably it is also using battery too.
Spare Parts –
Spare Parts allows you to enable some settings
that are not found in the default setting menu
Process Monitor –
List the running process on your Android device.
Long click item to kill application or open application.
Fastboot –
This is a handy little app that kills all your services at once and lets them restart back up. I use this right before I hit the lock screen, so that if any app-services are running that I don’t have configured in Juice Defender Plus they will be killed, frees up about 50-70mb of memory, and then I lock the screen and JD takes over. This one is optional if you want it or not. I like it just fine and it works for me.
Matte Screen Filter –
Puts a sort of Dim setting on your screen. Almost like a display overlay, ok? And I did mean to rhyme those. I don’t use it because I have my display set how I want it but you can.
Battery Calibrator –
Pointless, but if you want to check out more info, click the hide tag below.
If you are having some haywire battery readings, this is for you. THIS WILL NOT INCREASE YOUR BATTERY LIFE, but will give you a truer reading if your battstats somehow get corrupted.
When you flash a new ROM, it is always best to wipe the old battery stats associated with that ROM, so you can start fresh as a daisy. How this works is you plug you phone in and charge to 100%, do not mess with it or surf the net (I do this overnight). While still plugged in, hit the apps, grant SU permission and hit the Calibrate Battery button. Grant SU permission again and once done, unplug your phone. Your Batterystats.bin has been deleted. You running your phone down by just using it normally. Most say to run it until it shuts off, but I have had bad experiences doing this, so I let it get to 10-15% and plug it in then. Charge fully up to 100% (again no surfing or games) and you will notice a dramatic increase in battery life.
**Note that this can be done two other ways. You can boot into CWR or Custom Recovery and go to Advanced Settings and there will be the Wipe Batterystats.bin option. Or you can do it manually by going into /data/system/ and deleting the batterystats.bin in there. Any of the three methods work to get the entirely same result in the end. I just like using the app or manually myself. **
Why battery calibration is important and what it is doing.
The app and what it does is more for when you are flashing a ROM and have around 60% and then once booted up fully, you charge it up to 100%. Decided you don't like your ROM and go back to your original ROM via backup, it will show 60% instead of the 100 or 90% you had before you went back to back up b/c you backed up the batstat bin when you nandroided your original ROM. Also simply charing your phone up to 100% and shortly after you unplug it, the Battstats will reset.
Recently (about this time last year) there has been information debunking this process. I will post it below. Here is the post by Dianne Hackborn, a Google Dev on her G+ account.
Dianne Hackborn - Jan 12, 2012 - Public
Today's myth debunking:
"The battery indicator in the status/notification bar is a reflection of the batterystats.bin file in the data/system/ directory."
No, it does not.
This file is used to maintain, across reboots, low-level data about the kinds of operations the device and your apps are doing between battery changes. That is, it is solely used to compute the blame for battery usage shown in the "Battery Use" UI in settings.
That is, it has deeply significant things like "app X held a wake lock for 2 minutes" and "the screen was on at 60% brightness for 10 minutes."
It has no impact on the current battery level shown to you.
It has no impact on your battery life.
Deleting it is not going to do anything to make your more device more fantastic and wonderful... well, unless you have some deep hatred for seeing anything shown in the battery usage UI. And anyway, it is reset every time you unplug from power with a relatively full charge (thus why the battery usage UI data resets at that point), so this would be a much easier way to make it go away.
Click to expand...
Click to collapse
Here is a post from this thread with ERD Entropy512 and I discussing the Battery Calibration app.

Proof that these things work. Stock battery by the way. Sorry for the huge pix. I'll tag them with a Hide Parse for better viewing real estate.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Battery screenshots as of 12/13/12
View attachment 1561698View attachment 1561700View attachment 1561701
Change Log:
9 August 13 -Added in Greenify, Tasker, Kernel settings, cleaned up a bit.
13 December 12 - Added more battery screenies
2 November 12 - Initial Post
***********
If anyone has any tips or tricks that they want to share, by all means post them in here and I will link it in the OP. We are all in this together.

After reading this posts I am afraid to even use my phone cuz battery will drain lol jkjk! Thanks great thread!

Awesome thread man! Really glad to see you brought it over here!
Thanks for taking the time! I know it'll come in very handy for just about everyone.
Great job on a great guide!
:thumbup::thumbup:
Sent from my SGH-T999 using xda app-developers app

Woodrube said:
Y U Quote the whole OP
Click to expand...
Click to collapse
Awesome guide.. We thank you
Sent from my SGH-T999 using xda premium

This is some really great information. Thank you for taking the time to share it with everybody.

I knew it wouldn't take long for this to get to the top!
:thumbup:
Sent from my SGH-T999 using xda app-developers app

Great thread thank you
Sent from my SGH-T999 using xda app-developers app

I wanted to warn people that LBE Privacy Guard caused crazy boot loops for me. The reviews from the Play Store suggests that it's a Jellybean issue. Anyway, I was able to go into recovery, fix permissions, and force stop and uninstall before it went crazy again. Other than that, thanks for the great tips!

Woodrube good post, I remember seeing this in the vibrant section. Keep up the good work mod.
Sent from my SGH-T999 using Tapatalk 2

Thanks man. I ported the meat and bones of it over, but I added a ton of stuff specific to the SGS3, plus the sections about Governors and I/O schedulers.
If anyone reads this, I could use more OC/UV examples to put in the OP. It would be much appreciated.

This is great, what really got me is how the phone doesnt automatically go to the best tower for the best signal, so I will defnitely start toggling airplane mode when I travel, thanks a lot for all this helpful information and apps that can help up save battery as much as possible!

Be sure to turn off Latitude updates in
Maps > Menu > Settings > Location settings > Location reporting > Do not update your location

Already on the portal.
Great Great Great!
Thanks a lot.

Plus Post for anyone.....we seem to forget the things that kill us....back stab us the most when it comes to Battery Life!!
GOOD POST!!! VERY DETAILED AND INFORMANT!!!!

Great advice on the whole, but I don't agree with the stuff about app widgets.
Widgets don't use a bunch of resources just because they are widgets - I think you could almost say the opposite: the design of widgets allows them to be visible on your desktop without using any resources because the app code that controls the widget only needs to be loaded when the widget changes.
In the end, the resources used by an app widget depend on what it does and how it is designed - same as for any app. If your widget is supposed to go to the network and update some info for you every few minutes then this will drain your battery. However, there are tons of utility widgets that do nothing (and are not in memory) unless they are pressed or one of the phone states they are listening to changes (e.g. a radio is turned on).
Of course, a badly designed app will hurt your battery regardless. Personally I think apps need to get away from creating a custom Application object since these get instantiated whenever the system creates the app's (or app widget's) process, even if it is just to update a widget.

Nice thread
Thxs for this nice thread Any ore would be appreciated.
I have learned a few things besides already being techy.
Nice to see whole lot of apps for android

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

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

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

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

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

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

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

6. CPU GOVERNOR ADJUSTMENTS
Governor Adjustments are typically parameters for a given governor that you can further tweak. There are certain Performance Scripts out there that may set some of these parameters as well. One such example is System Performance Mod Thunderbolt! By @pikachu01​
Given below are some of the parameters of commonly used Governors. There are quite a lot of parameters for each governor. Having to list each one will be pretty intensive. I may choose to add these in future as time permits AND if there is a demand for it. In addition, I am adding Hide tags for each governor in order to tidy up the post.
ONDEMAND GOVERNER-
Ignore_nice_load - You can use the ignore_nice_load option to ignore all processes, that run with a positive nice value. These will not be counted toward the overall CPU utilization. Set this parameter to 1 if you do not care how long it takes for such processes to complete.
sampling_rate - Measured in us. , this is how often the kernel look at the CPU usage and make decisions on what to do about the frequency. Higher values means CPU polls less often. For lower frequencies, this could be considered an advantage since it might not jump to next frequency very often, but for higher frequencies, the scale-down time will be increased.
up_threshold - Measured in percentage 1-100, When CPU load reaches this point, governor will scale CPU up. Higher value means less responsiveness and lower values corresponds to more responsiveness at the cost of battery.
powersave_bias - Default value is 0. Setting a higher value will bias the governor towards lower frequency steps. Use this if you want CPU to spend less time on higher frequencies. A better alternative would be to underclock to a lower frequency than using powersave bias.
The powersave_bias parameter modifies the behavior of the ondemand governor to save more power by reducing the target frequency by a specified percentage. By default, the it selects the minimum processor frequency that can still complete a workload with minimal idle time. Doing so should result in the highest performance to power efficiency ratio. In some cases, you might prefer a greater emphasis on power efficiency than performance. In this case, set the powersave_bias parameter to a value between 1 and 1000 to reduce the target frequency by one-thousandth of that value. Say if you set powersave_bias to 100 it will cause a one-tenth reduction in target frequency. If the Max frequency of the device is 2 GHz, the governor instead will request 1.8GHz – a one-tenth reduction. If 1.8 GHz is an exact match with an available hardware frequency (listed in the scaling_available_freq parameter), the processor is set to this frequency. If 1.8 GHz is not available, the processor fluctuates between the closest available upper and lower frequencies for an average frequency of 1.8 GHz. The default value is 0.
sampling_down_factor - In the simplest form, sampling_down_factor determines how often CPU should stay at higher frequencies when truly busy. Default behavior is fast switching to lower frequencies (1). Having sampling_down_factor set to 1 makes no changes from existing behavior (for the non-modified ondemand), but having sampling_down_factor set to a value greater than 1 causes it to act as a multiplier for the scheduling interval for re-evaluating the load when the CPU is at its highest clock frequency (which is scaling_max_freq) due to high load. This improves performance by reducing the overhead of load evaluation and helping the CPU stay at its highest clock frequency when it is truly busy, rather than shifting back and forth in speed. This tunable has no effect on behavior at lower frequencies/lower CPU loads.
down_differential - This factor indirectly calculate the 'down-threshold' of Ondemand. After completing sampling-down-factor*sampling-rate at max frequency because of high load, governor samples the load again to calculate an estimate of the new target frequency in a way that the lowest frequency will be chosen that would not trigger up_threshold in the next sample. Because triggering up-threshold will again cause CPU to scale up to max frequency. During this choice down_differential is taken into account as a breathing room value. Target frequency is calculated as max_load_freq / (up_threshold - down_differential). The obtained value might be a non-existent value in the freq_table and CPU driver will round it off to a value in freq_table. max_load_freq is the theoretical frequency at which CPU can handle 100% workload. It is usually a value below scaling_max_freq. See this post by AndereiLux for more info.
freq_step - Whenever up-scaling logic is triggered the governor instructs the CPU to raise its frequency by freq_step percentage of max allowed frequency. (max policy * (freq step / 100)). Ex: max policy is 1600 and freq step 21%, it will scale 1600 * 21% = 336. We have a 100MHz grained frequency table so it rounds up to the next 100MHz, hence 336 becomes 400. So say we're idling at 200MHz and the up-scaling logic gets triggered with the above settings, the next frequency will be 600MHz. Note that freq_step and smooth_scaling does pretty much the same thing.
SMARTASSV2 GOVERNER –
awake_ideal_freq - The frequency until which CPU is scaled up rapidly on screen-awake (from sleep). Thereafter, scaling up is less aggressive.
sleep_ideal_freq - The frequency until which CPU is scaled down rapidly when screen is turned off. Thereafter, scaling down is less aggressive.
up_rate_us - The minimum amount of time to spend at a frequency before we can ramp up. (Ignored below awake-ideal frequency since governor needs to rapidly scale up to awake_ideal_freq when below it)
down_rate_us - The minimum amount of time to spend at a frequency before we can ramp down. (Ignored above sleep-ideal frequency since governor needs to rapidly scale down to sleep_ideal_freq when above it)
max_cpu_load - Same as up_threshold in other governors.
min_cpu_load - Same as down_threshold in other governors.
ramp_down_step - Frequency delta when ramping down below the ideal frequency. Zero disables and will calculate ramp down according to load heuristic. When above the ideal frequency we always ramp down to the ideal freq.
ramp_up_step - Frequency when ramping up above the ideal frequency. Zero disables and causes to always jump straight to max frequency. When below the ideal frequency we always ramp up to the ideal freq.
sleep_wakeup_freq - The frequency to set when waking up from sleep. When sleep_ideal_freq=0 this will have no effect.
KTOONSERVATIVE & CONSERVATIVE GOVERNER-
Boost_2nd_Core_On_Button -
This configuration option when set, allows you to turn the second Core ON with Back+Home+Menu button combo.
Boost_CPU - @KToonsez hasn't documented much on this setting. But based on my experiments, I feel that this, specifies the frequency to which the second Core is set when turned on by the button combo above.
Boost_GPU - Similar to Boost_CPU, this will set the frequency of operation of the GPU when the second core is turned on.
Boost_Hold_Cycles -
This setting specifies the duration for which the Core 2 will be kept on. A value of 22 translates as 1 second.
Boost_Turn_on_2nd_Core -
When set, this setting will make second core turn on immediately on touch.
CPU_Down_Block_Cycles -
This setting is used to counteract the effects of hot plugging. It specifies duration for which the CPU Cycles are throttled before hot plugging the second core out.
Disable_Hotplug_BT -
As the name suggests, when set. this setting will stop the second core from being turned off when Bluetooth connection is active.
Disable_Hotplugging -
When set the entire process of hot plugging is turned off.
freq_step - Defines how much (as a percentage of the maximum CPU speed) the conservative governor will increase the CPU speed by each time the CPU load reaches the Up Threshold.
sampling_down_factor & sampling_rate- The sampling_down_factor value acts as a negative multiplier of sampling_rate to reduce the frequency that the scheduler samples the CPU utilization. For example, if you set sampling_rate to 10,000 and sampling_down_factor to 2, the scheduler samples the CPU utilization every 20,000 microseconds.
freq_step - The freq_step parameter changes the size of the frequency step that the governor uses to change CPU frequency in either direction. By default this setting is 5, which means the governor will change the CPU frequency by five percent of the maximum or minimum frequency each time it changes frequencies. If you set this value to 100, the governor will behave exactly like the ondemand governor and immediately increase to the highest speed.
ignore_nice_load - You can set the ignore_nice_load option to ignore all processes that run with a positive nice value will not be counted toward the overall CPU utilization. Hence will not cause the CPU frequency to increase and might take longer to complete. When set to 0 (the default), all processes are counted toward the CPU utilization value. When set to 1, niced processes are ignored.
No_2nd_CPU_Screen_Off -
As the name says, setting this to 1 (default value), will turn off second core on your device. For those with more than 2 cores, there will be corresponding settings for 3rd and 4th core.
Sampling_Down_Factor - This parameter controls the rate at which the
kernel makes a decision on when to decrease the frequency while running
at top speed. When set to 1, decisions to re-evaluate the CPU load, are made at the same interval regardless of current clock speed. But when set to greater than 1 (e.g. 2 Default value) it acts as a multiplier for the scheduling interval for reevaluating load when the CPU is at its top speed due to high load.
This improves performance by reducing the overhead of load evaluation and helping the CPU stay at its top speed when truly busy, rather than shifting back and forth in speed. This tunable has no effect on behavior at lower speeds/lower CPU loads.
Sampling_Rate - This is measured in uS (10^-6 seconds). That is how often the kernel will poll the CPU usage and make decisions on what to do about the frequency. It's default value is 25000.
Sampling_Rate_Min - As the name states, this value provides a minimum limit on the Sampling_Rate. This is based on the Hardware Latency and Kernel variables. Default value is 10000.
Sampling_Rate_Screen_Off - As the name suggests, this is the value of Sampling_Rate when the screen is turned off. Default Value 40000.
Up_Threshold - It specifies what the average CPU usage between the samplings of 'sampling_rate' needs to be for the kernel to determine if it should increase the frequency. For example when it is set to '70', between the checking intervals the CPU needs to be average more than 70% in order to determine that the CPU frequency needs to be increased.
Up_threashold_Hotplug - As the name suggests, this value determines when to bring the second Core Online. It is done when the CPU load reached this %.
INTERACTIVE GOVERNER-
hispeed_freq - An intermediate "hi speed" at which to initially ramp when CPU load hits the value specified in go_hispeed_load. If load stays high for the amount of time specified in above_hispeed_delay, then speed may be bumped higher. Default is maximum speed.
Above_hispeed_delay - Once speed is set to hispeed_freq, wait for this long before bumping speed higher in response to continued high load. Default is 20000 uS.
go_hispeed_load - Go to hi speed when CPU load at or above this value. (Similar to Up-Threshold in other governors). The CPU load at which to ramp to the intermediate "hi speed". Default is 85%.
min_sample_time - The minimum amount of time to spend at the current frequency before ramping down. This is to ensure that the governor has seen enough historic cpu load data to determine the appropriate workload. Default is 80000 uS.
timer_rate - The sample rate of the timer used to increase frequency. It reevaluates cpu load when the system is not idle. Default is 20000 uS.
input_boost: If non-zero, boost speed of all CPUs to hispeed_freq on touchscreen activity. Default is 0.
boost: If non-zero, immediately boost speed of all CPUs to at least hispeed_freq until zero is written to this attribute. If zero, allow CPU speeds to drop below hispeed_freq according to load as usual.
boostpulse: Immediately boost speed of all CPUs to hispeed_freq for min_sample_time, after which speeds are allowed to drop below hispeed_freq according to load as usual.
WHEATLEY GOVERNER -
target_residency - The minimum average residency in µs which is considered acceptable for a proper efficient usage of the C4 state. Default is 10000 = 10ms.
allowed_misses - The number sampling intervals in a row the average residency is allowed to be lower than target_residency before the governor reduces the frequency. This ensures that the governor is not too aggressive in scaling down the frequency and reduces it just because some background process was temporarily causing a larger number of wakeups. The default is 5.

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

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

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

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

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

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

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

Great guide, excellent work! Subscribed!

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

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

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

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

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

what's is smart cpu efficiency explain in details please?

recently miui add a new feature called smart cpu efficiency but I wanna know more about this feature and how it's works and after are the pro and cons in full details please and is it really a good feature please answer as soon as possible....

Guys behind MiUI aren't exactly the "brightest" one's so it's just a fancy name, all do it whose not been to hard to do a better tuning than they did on "8". The CPU is regulated trough three part's; governor, HPM scheduler and hotplug. I won't discuss it there is plenty documentation provided, you just need to search for it and make comparation between vendors (OEM's)...

its just the fancy name

Zola III said:
Guys behind MiUI aren't exactly the "brightest" one's so it's just a fancy name, all do it whose not been to hard to do a better tuning than they did on "8". The CPU is regulated trough three part's; governor, HPM scheduler and hotplug. I won't discuss it there is plenty documentation provided, you just need to search for it and make comparation between vendors (OEM's)...
Click to expand...
Click to collapse
I get your point that it's just a fancy name but I wanna know how actually work and how it effect on cpu and how good it is or bad because as I seen this feature active by security app by miui and it just turn down A-72 1.80ghz core to A-1.40ghz and and doesn't even let the device use this and force the device to use A-53 1.40ghz core which is killing my device and it's performance and multitasking help me out with this is true or wrong
https://ibb.co/dAYP9Q

BG. said:
I get your point that it's just a fancy name but I wanna know how actually work and how it effect on cpu and how good it is or bad because as I seen this feature active by security app by miui and it just turn down A-72 1.80ghz core to A-1.40ghz and and doesn't even let the device use this and force the device to use A-53 1.40ghz core which is killing my device and it's performance and multitasking help me out with this is true or wrong
https://ibb.co/dAYP9Q
Click to expand...
Click to collapse
Basically it's a corectl hotplug which is one of the three parts (the last one in hierarchy) that are used for CPU control others are HPM sched which is highest priority & rather complicated & CPU governor. Hire is a catch HPM sched whose broken in the kernel code we got from Xiaomi & after lots of work it's now patched to work properly (as much as possible). I don't know the state of the code in MiUI nor could I but I am pretty much certain that they didn't do a homework. Nor do I know the parameters they used to configure all tree parts. The 1.4 GHz is biggest long time sustainable frequency for the A72's on S65x SoC's & even that much if only up to two active. That isn't the problem, which leads me to believe that problem is a hotplug configuration as it's lagging behind in activating big cores and naturally HMP sched places the task on the first ready core that meets the demand the best of those available. Actually hotplug needs around 150~200 microseconds to wake up the core so it's ready to be used while HPM sched and governor make a decision in one circle or less which is 20~40 ms usually while migration from one to another core takes between 50 to 90 ms. So you see hotplug can't keep up with them nor it will ever can. That's why you need at all times to have at least one active core per each & every cluster (preferable & optimal by my findings is two & every second one starting with first so that the L2 cache is always active fully [this brings down transition times to 50 Ms]). If you have root feel free to play with it as you will find it im QC power init & you can read about settings hire at XDA (Mi Max) on power performance optimisations thread.
Best regards.

So after all it turns out to be dumb & by all means far north from efficient. Typical MiUI.

Zola III said:
Basically it's a corectl hotplug which is one of the three parts (the last one in hierarchy) that are used for CPU control others are HPM sched which is highest priority & rather complicated & CPU governor. Hire is a catch HPM sched whose broken in the kernel code we got from Xiaomi & after lots of work it's now patched to work properly (as much as possible). I don't know the state of the code in MiUI nor could I but I am pretty much certain that they didn't do a homework. Nor do I know the parameters they used to configure all tree parts. The 1.4 GHz is biggest long time sustainable frequency for the A72's on S65x SoC's & even that much if only up to two active. That isn't the problem, which leads me to believe that problem is a hotplug configuration as it's lagging behind in activating big cores and naturally HMP sched places the task on the first ready core that meets the demand the best of those available. Actually hotplug needs around 150~200 microseconds to wake up the core so it's ready to be used while HPM sched and governor make a decision in one circle or less which is 20~40 ms usually while migration from one to another core takes between 50 to 90 ms. So you see hotplug can't keep up with them nor it will ever can. That's why you need at all times to have at least one active core per each & every cluster (preferable & optimal by my findings is two & every second one starting with first so that the L2 cache is always active fully [this brings down transition times to 50 Ms]). If you have root feel free to play with it as you will find it im QC power init & you can read about settings hire at XDA (Mi Max) on power performance optimisations thread.
Best regards.
Click to expand...
Click to collapse
thanks for helping out

Well I hope you are satisfied with explanation.
See you later alligator.

Zola III said:
So after all it turns out to be dumb & by all means far north from efficient. Typical MiUI.
Click to expand...
Click to collapse
could you please give me few simple examples regarding this issue so I can post and point out on the form

BG. said:
could you please give me few simple examples regarding this issue so I can post and point out on the form
Click to expand...
Click to collapse
Their is no simpler explanation.
The numbers I presented are extrapolated from numerous analysis published as scientific works all available floating around the net.
A) hot plug is relatively slow (not because of it self but) as awakening from deep retention states on all ARM CPU's up to date takes time (to init & test/flush queues and RAM subsystem integrity)
B) HPM scheduler is designed to place the work on first available ready CPU core that best meets the demand (dependant on given idle/packing parameters assigned to HPM)
C) hotplug will never be able to awake any core in deep retention state on time for a HPM decision timing
D) all transitions from one to another core (no matter which one) is costly.
So in short what could & needs to be done;
A) Ensure that at least one CPU is always active per cluster
B) Ensure that HPM is properly configured & running as intended (migration load, packing & idle conditions)
C) Minimise transition times (by providing optimal setup) and minimise their number.
How to achieve this?
Well;
A) properly configure hotplug disabling it to power down control core's that are needed to stay online all the time (this excludes the device sleep), example (of a 2+2 always on configuration on a octa core dual cluster SoC [S652]);
write /sys/devices/system/cpu/cpu0/core_ctl/not_preferred "1 0 1 0"
write /sys/devices/system/cpu/cpu4/core_ctl/not_preferred "1 0 1 0"
write /sys/devices/system/cpu/cpu4/core_ctl/is_big_cluster 1
B) there are two approaches with HPM super packing (Sony) & absolute idle load (Xiaomi on MiUI 8) both tied to min CPU's active and all CPU's active how ever the both approaches are wrong, high enough init with limited packaging & giving idling cores advantage is really the best way to go along with providing ideal conditions of available core's (which is 2+2)
C) this two already implied hire together make the ideal possible setup for a task placement & minimising the up/down migration times plus if set as shown (when possible) ensures the usage of all L2 cache available along with exclusive access, it also provides faster awakening of other core's when they are needed from deep retention state. The power drive cost is the same as the performance gain (5~6%) so for given job the power consumption is exactly the same while other positive effects remain. Additionally it's good to prevent up migration of the tasks that are lower priority & flagged as background tasks.
Notes:
1. If enabling the described hotplug configuration on the A53 cluster make sure that it's enabled only on the V2 revision of the core's & that the tool chain (compiler) is set to the strict ID-ing of the core revision along with no A53 erratums forced.
2. The given 2+2 configuration covers all possible scenarios of the thread migrations including SMP one's & it's considered as optimal one by me.
3. In order for this to work properly (& anything else for that matter) the general scheduler patching is required which is available in nijel8 Github kernel repository (mainline port fixes and mostly from Petr).
4. Alternative setup is all four A53 cores active with one A72 core's active all the time, it provides some power saving (in idle and low load states mostly) compared to 2+2 (with A72 core's which falls close to none with A73 core's) but it doesn't cover SMP up migration case along with minor performance degradation. The rest part remains the same.
Feel free to quote me.
As I believe in good old healthy logic which this is I don't find it particularly "smart" one either.
Best regards.

@Zola III
Another worthy input from you regarding performance/power saving... :good:
I will quote you in the performance thread so this not get lost here along with a question... See you there.

nijel8 said:
@Zola III
Another worthy input from you regarding performance/power saving... :good:
I will quote you in the performance thread so this not get lost here along with a question... See you there.
Click to expand...
Click to collapse
Well it's pretty much not anything new nor something we didn't try already together & most of the stuff you already implemented.
Cheers!

thank you guy thank a lot for all your help

Red Magic 5G MOD Kernel GPUOC 900/940mhz +battery 1.4 STABLE!

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
*** NOTE THAT 3.16 NA OR 4.13 Red Magic 5G SPECIFIC ROMS SHOULD BE USED WITH THIS KERNEL! THE COMBINED ROM (WITH RM5S) HAS UPDATED KERNEL CODE THAT IS NOT FULLY COMPATIBLE AND NUBIA HAS NOT UPDATED THEIR SOURCE CODE ***
*** Please click Thanks (Thumbs up icon) on my post here if you like my kernel and rate the thread 5 stars, then just use it and enjoy - if you want to send me a beer or two feel free - you don't have to use PayPal - Revolut and Amazon.com (USA) gift cards avoid fees. I like to hear from happy users I hope you are glad that you have the fastest phone in the world currently. The active cooling in this device is utilized to the extreme with MOD kernel, meanwhile your battery usage will be much improved at the same time. How? Well, that's all in the source code, free for all to fork it on GitHub and modify to your liking. Just don't forget to credit me and the many great devs that made the improvements possible... without them, there would be no MOD kernel. This is just a hobby of mine and I like to produce a nice product that all can enjoy. I'm also quite friendly and although I may tell you no I won't add that feature (such as network hacking tools), I won't hold anything against you for asking. I have not been compensated other than by some generous folks on my Telegram channel, so this whole project is basically self funded. Red Magic will not support it, unfortunately, but you can if you feel the improvements are worth it. I believe they are, but I come from a biased point of view as the sole developer for RM5G ***
********************************************************************************************************************************************************************************************************************************
NOTICE: YOU ASSUME FULL LIABILITY FOR ANYTHING THAT MAY HAPPEN TO YOUR PHONE USING THIS KERNEL. ALTHOUGH IT WORKS 100% ON MY PHONE, IT MAY NOT WORK THE SAME ON YOURS. THE PROCESS OF ROOTING A PHONE AND INSTALLING A CUSTOM KERNEL ALWAYS HAS RISKS, SO IF YOU ARE NOT COMFORTABLE ASSUMING THOSE RISKS, DON'T INSTALL THE KERNEL! THIS IS A TYPICAL DISCLAIMER FOR CUSTOM KERNELS I HAVE FOUND NO BUGS WITH IT AT ALL. USERS ON CN, GLOBAL, AND NA ALSO HAVE NOT FOUND ANY PERFORMANCE ISSUES OR BUGS (DO NOT USE V7.14 or V8.11) IF YOU DON'T KNOW WHAT YOU ARE DOING, IT'S BEST TO REMAIN STOCK. OR JOIN THE TELEGRAM GROUP, AND GET SOME REAL HELP.
********************************************************************************************************************************************************************************************************************************
Easy root method: https://forum.xda-developers.com/nu...nner-tutorial-unlock-bootloader-t4131585/amp/ although I suggest still using Magisk 20.4 for root.
Note: if you've already rooted and want to upgrade, people have had success saving the kernel as boot.img and TWRP as recovery.img in SmartPack, vbmeta skip as vbmeta.img and placing into the ROM update.zip using MT Manager (a root browser) and saving the updated file. Then do a Settings / System Update / click the 3 dots / local update and select your modified file. In fact I upgraded from 3.13 to 3.16 NA ROM without losing anything this way. Now for normal installation:
Custom kernels require root and Magisk to be installed. This is due to the signature not being signed by Red Magic (the company) itself. Following the above method you will still pass SafetyNet and most apps will work without trouble. If you have a specific app that detects root, well, Magisk Hide the app from Magisk Manager and see if that fixes it. You should also Hide Magisk Manager from various forms of detection (under Settings). Last case is to move the installation of Magisk under a random directory (which I have not had to do and all my banking apps still work), only if the root detection methods used by your app providers are more picky.
MOD KERNEL 1.4 STABLE:
RELEASE NOTES:
Block mode I/O has been changed to Multi-Queue from Single-Queue so your default scheduler is now MQ-deadline (credits to PappaSmurf, excellent kernel dev). You can choose between mq-deadline, kyber, and none in a kernel manager under I/O scheduler. From my benching with Androbench, it doesn't make much difference which one you use. Some have parameters you can tweak. None literally means no scheduler which is fine on an SSD, and has no overhead if you want to select it in a kernel manager. I always recommend SmartPack. To get settings to stick you Toggle "Apply on Boot" and it will go to what you've selected after 5-10 seconds on the next boot.
All debugging has been turned off completely on BBRv2 - thanks to PappaSmurf (I missed a few spots), and debug can't be turned back on from the userspace now. BBRv2 is selected as the default TCP algorithm which users have explained as a "no-lag" algorithm while gaming. It's just generally a fast algorithm all around. For me it works great, but you can still choose from many different algorithms in a kernel manager if you want to.
In SmartPack / Misc / TCP Congestion Algorithm, you have many choices: reno / bbr / bbr2 / bic / cdg / cubic / dctcp / westwood / highspeed / hybla / htcp / vegas / veno / scalable / lp / yeah / illinois. A SmartPack script is included below you can add in SmartPack to show the true TCP algorithm as it will always show Reno (a bug also shared by FK kernel manager). Below it's called Check_TCP.sh just go to SmartPack / Script Manager / Import / Check_TCP.sh. Afterwards, click Execute to see the active algorithm. If you set it on boot, this is the algorithm that will run, despite what the field says in Misc.
Battery is running very well on normal usage I'm getting around 7.5% active screen on drain over 7 hours and <0.7% screen off drain over 13 hours at 90hz screen setting. This is with actively using the phone for multiple "normal" purposes, reading emails, browsing websites with Chrome, reading news, streaming videos, etc. various shopping (Amazon/eBay) and tracking, Reddit feeds and live video, and other random "daily" tasks, up to 10 apps open at a time. Gaming of course will drain more, as will 144hz. I also have dark mode enabled in Settings. To get idle drain down I disabled 3 additional wakelocks that were causing high screen off drain, and so far I haven't seen an issue with blocking them. I also removed wakelocks that no longer exist since the Boeffla WL Blocker default list was created (it was quite old) so it now should be relevant for this device, with no interaction on the users part to disable anything via a kernel manager. Still, in SmartPack you will see a Wakelocks menu in case you install an app that causes idle drain to rise, this can be used to find and block wakelocks causing the problems. It can sort by wakeups and also by time. As it states though, you should be very careful what you disable. There can be unintended consequences and most wakelocks are not well documented as to what they actually control.
Dynamic Stune Boost is entirely removed from the kernel code now, as I didn't see any benefit from using it with this kernel.
Don't forget Dynamic Fsync is hidden under Misc in SmartPack which if you turn on will speed up your SQLite speeds. AnTuTu will penalize you for this, ignore it, your phone will be faster - but I leave it off by default. Androbench will show the true memory benefit. It is significant if an app does a lot of operations on databases. Journaling for the database is held in memory until the screen is off, then it is written. Although there is a chance of a data loss or corruption with this on if the device were to crash, it is safer than just turning off fsync. If you have any unstable apps, just leave it off - better to be safe. On a solid system though, you may notice better performance.
Also remember under SmartPack / GPU there is AdrenoBoost - it is set to low. You can alter to medium or high to get faster transfer between GPU frequencies, although it has worked great for me the way I use the phone. For you another setting may suit you better. Recall RedMagic OS only allows several frequencies which I spaced out as well as possible at 305mhz, 400mhz, 525mhz, 670mhz, 800mhz, and either 900 or 940mhz depending on the version you installed.
Overall I'm very satisfied with this kernel build and don't plan on adding or subtracting anything from it for the time being. It does what it should do, gives solid performance, and good battery life. My last score on AnTuTu setup with defaults 12GB/256GB was 682K which currently is still the top performing phone out there - running at 940mhz GPU. Not all phones can handle 940mhz so use 900mhz if yours cannot. If there are enough requests for an intermediate build (say 925mhz) I can add one later off the same code base. Also note in releases there are "gaming" builds that don't keep track of CPU times at each frequency, which was a request by users to remove any potential lag while gaming. I run the non gaming version, useful if you want to tweak battery usage, but nonetheless, both versions are there for you to use.
I'm on Telegram t.me/NubiaRedMagic5G_Mods as long as I have the phone. Which will be quite a while if Red Magic / Nubia decides to fix N41 5G in the USA.
Also note that all the features of this kernel (besides ones specifically added by me) are the creation of other developers whose contributions are all notated in the kernel source code. Some of the developers that have contributions here or helped me in some fashion: Resurrect88, DD3Boh, PappaSmurf, kdrag0n, Ayrton990, Flar2, Lord Boeffla, plus many more across the globe. Without them, I wouldn't be making any kernels! And I'm sure there are many other devs I've forgotten to mention, I thank all you guys for your help and support.
MOD 1.4 Download Link:
https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.4
PRIOR RELEASES BELOW:
8th Release:
MOD KERNEL 1.35-BBRv2 STABLE:
RELEASE NOTES:
This is an intermediate release - I realized that the prior release was draining far more battery than it should, and I found the source was debug related code in BBRv2 from Google. So this is the updated kernel that gives you battery life like before this TCP algorithm was added.
CONFIG_CPU_FREQ_TIMES=y has also been added so you can see in a kernel manager how much time is spent in each mhz block for each set of processors. This can be useful if you set in a kernel manager (like SmartPack) a minimum CPU mhz to see how much time is actually spent at each level.
The code base also has Dynamic Stune Boost, but I haven't had time to optimize it for the device, so it's just on default settings. So there are 2 versions of this 1.35-bbr2 release. At some point it will be enabled as part of a regular release (some 17 commits squashed together into 1, Stune Assist was causing issues so I turned it off). The main idea of that set of code additions is to run the device at lower frequencies, saving battery, while still achieving the same performance level to the user of the phone. If you want to try different options for it in SmartPack or FK Kernel Manager you can.
Downloads:
https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.35-bbr2
7th Release:
MOD KERNEL 1.3-BBRv2 STABLE:
RELEASE NOTES:
Added the 31+ commits for BBRv2 from Google. Squashed the commits down to 6 by author from Google (for easy code maintenance). It's said to be the best TCP (internet congestion) algorithm so this sets it by default. You can still select from the others added in 1.3, as mentioned only EX Kernel manager properly shows them. But SmartPack if you choose the one you want under Misc, then click Apply on Boot, it actually will load the TCP algo you selected. It's just a visual defect. I also made a script for SmartPack uploaded to show you the TCP algo that's selected in my repo you can install so you can verify for yourself. Give it 10 seconds (default on boot setting) before you check.
Downloads:
https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.3-bbr2
6th Release:
MOD KERNEL 1.3 STABLE
RELEASE NOTES:
All this release adds is TCP congestion algorithms. The only kernel manager which correctly shows the algo set correctly is EX Kernel Manager. Using SmartPack or FK Kernel Manager will tell you that you're always on Reno, when in fact, you aren't. I'm not quite sure if this is bug related to 865 kernels as a fellow dev had the same experience (on an Op8 Pro). Now the default is set to BBR. Why? No reason specifically, although it is one of the better algorithms for internet usage. You can easily change in any kernel manager and set on boot which one you'd like to use (see above RELEASE NOTES if using SmartPack). But this gives you plenty of options:
BBR, BIC, CDG, CUBIC, DCTCP, WESTWOOD, HSTCP, HYBLA, HTCP, VEGAS, RENO, VENO, SCALABLE, LP, YEAH, ILLINOIS
You can Google the benefits of each and pick what you like. Or just leave it alone. The prime idea of MOD kernel is that you don't need to adjust anything it just works optimally without any intervention. Read the release notes for prior features that have been added. There are many just not summarized in a single place at the moment. All the optimization has been done for Red Magic OS.
Downloads:
https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.3
5th Release:
MOD KERNEL 1.25BETA
RELEASE NOTES:
This release is mostly about battery savings. I'm averaging around 6.5% active drain on normal tasks with this version (90hz setting), and around 0.5% screen off drain. A big improvement over the stock kernel. So I ended up with about 13 hours SOT + 24 hours screen off on 1 charge! See the picture, I stopped at 11% left. Now I didn't say anything about gaming. If you want to game and have power saving benefits, don't enable any of the built in boosting modes in the game launcher - the Red Magic OS will override everything. Let the kernel do the work for you. And if you're seeing any graphics lag, go into SmartPack kernel manager (free) and go under GPU, Adreno Boost is enabled on low, you can set it to medium or high. That will increase the speed at which the GPU throttles up and down.
1) Switch to the Energy Model for CPUs: Several subsystems (thermal and/or the task scheduler for example) can leverage information about the energy consumed by CPUs to make smarter decisions. This config option enables the framework from which subsystems can access the energy models.
2) Added CPUMASKS for the Little, Big, and Prime cores from Sultan Alsawaf Sultan: SultanXDA, prime added by Danny Lin: kdrag0n.
3) Added kernel control of the minimum frequencies for the little and big clusters by Danny Lin kdrag0n. They are set to run at their minimum running frequencies when idle 691mhz (little) and 710mhz (big) which results in nice power savings when web browsing or just under low load in general. Prime cluster min is not set as it makes the CPU scheduler function poorly.
4) Added AdrenoBoost by Aaron Segaert: Flar2, with all its changes squashed into 1 commit. Defaults to low setting. As mentioned before, you can change in SmartPack, and set on boot if you need a higher value than low: https://github.com/SmartPack/SmartPack-Kernel-Manager/releases
5) Uploaded the various GPU OC files to the repo, It still will just build off the default one, but they are here to be complete. 940mhz version again is posted, Building direct from the repo will give you 900mhz max GPU.
Downloads:
https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.25BETA
4th Release:
MOD KERNEL 1.2 BETA
RELEASE NOTES: (Note a 940mhz GPU clock edition is available, if you want to try it, a few of us have had good results on it. Likely the max an 865 GPU can run. You'll sacrifice the power savings, however):
1) Enable Power-efficient workqueues by default, add a toggle that can turn this off via a kernel manager (under CPU in SmartPack). Enabling this makes the per-cpu workqueues which were observed to contribute significantly to power consumption unbound, leading to measurably lower power usage at the cost of small performance overhead. Have also added many other power saving features to the defconfig. The phone is a beast, power savings is a good thing to implement.
2) Update the LZ4 decompressor algorithm with a much faster variant for the ZRAM swap, now version 1.8.3-9 credits Gao Xiang [email protected] and many others (check commits). Speed improvement below (should help on 8GB devices):
Compressor name Compress. Decompress. Compr. size Ratio Filename
lz4hc 1.7.3 -9 12 MB/s 653 MB/s 42203253 42.20 enwik8
lz4hc 1.8.3 -9 11 MB/s 965 MB/s 42203094 42.20 enwik8
3) Default scheduler is set to SQ deadline. Should see minimal improvements in speed until I get a MQ variant working. On the task list ahead.
Download Link:
1.2BETA: https://github.com/mrslezak/NX659J_Q_kernel/releases/download/1.2BETA/MOD-RM5G-GPUOC-Beta1.2.zip
940mhz GPU release here, it's still 1.2BETA, just with the max clock a few of us have been able to use. That doesn't mean your device can for sure handle it, but give it a try if you'd like! Note the power savings will likely not be there vs the other release at 900mhz:
https://github.com/mrslezak/NX659J_...oad/1.2BETA/MOD-RM5G-GPUOC-940mhz-Beta1.2.zip
3rd Release:
1.15BETA: https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.15BETA
This is a HEAVILY updated release of the MOD kernel 1.10BETA - I realized the phone's software will allow 6 frequency clocks, although 1 did not have a regulator defined (now patched). NOW I VERY HIGHLY suggest installing SmartPack Kernel manager. It will give you insights into the kernel and how it's performing and it's free. It also will let you adjust added options now in the kernel. Just root your phone and flash from TWRP. If you haven't already installed Magisk, then install that too. There's a guide I posted on XDA about that. Use the experimental method there is no reason to unlock your bootloader. https://forum.xda-developers.com/nu...how-to-unlock-bootloader-redmagic-5g-t4081743
RELEASE NOTES:
1) Bugfix: there was 1 missing 800mhz GPU frequency regulator clock on the prior version. This has been set to TURBO, 1 level under the 900mhz regulator of TURBO_L1.
2) Boeffla WakeLock blocker (v1.10 + tweaks) has been added to reduce battery drain when the phone is not being used, using the latest version and all patches. A default block list is included. You can access in SmartPack Kernel Manager under the new menu that will appear "Wakelocks" - especially investigate if your phone has high idle drain, you can experiment with blocking other wakelocks (which don't allow your phone to sleep). Or you can leave as is. I get just under 1% drain (screen off) and the phone sleeps quite often with this version. Take a look at the screen shot! That's just normal phone usage, not gaming.
3) All debug entries (except those required) have been stripped completely out of the kernel. This results in less wasteful debug information being generated.
4) The default algorithm for ZRAM has been changed from LZO (high compression, but slow) to LZ4 (slightly less compression, but fast). LZ4 algo was added. It still defaults to 4GB.
5) Dynamic Fsync has been added to the kernel as well. This patch allows journal entries to be written only when the screen is off. I.e. they are cached and written afterwards. This increases database performance. It is disabled by default so in SmartPack Kernel manager, if you'd like to turn it on, go under Misc, select Dynamic Fysnc, and select apply on boot. There is always a risk of data loss when delaying writes, although I've personally never have had issues - it only happens if the phone crashes, and mine has never crashed on this kernel. This won't normally increase your benchmark scores (except AndroBench), it increases SQLite database access speed. Up to you to use or not, works fine on my device.
6) Here are the updated frequencies (note there is 1 more). Will have to wait for AOSP before I can add back more. Note the 670MHz is likely the 865+ max frequency per the release notes today on the device (which I assumed by the source code anyhow pre-announcement): 900MHz / 800MHz / 670MHz / 525MHz / 400MHz / 305MHz
AS ALWAYS, USE AT YOUR OWN RISK!!!
Github Source:
https://github.com/mrslezak/NX659J_Q_kernel
Initial Release:
https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.0.BETA
Second release - gets over the "reset to 490mhz" bug caused by the system software, at the expense of reducing frequencies to 6 total:
https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.10BETA
Newest release -> will be posted on the top from now on.
Telegram:
https://t.me/NubiaRedMagic5G_Mods
And note the AnTuTu benchmark is just a first run after installing. 670K is likely a record on any 865 phone. The last bench turning off 4GB ZRAM (12gb/256gb device) I got 673K. AnTuTu doesn't equal performance, but if you've benched you'll see this is an insane improvement over the stock kernel. Only when the demand is there will it scale up to 900mhz. I've been using for a while now and notice no difference in battery life. The Adreno driver is very good at handling extra clock frequencies efficiently without modification (despite an "Adreno Boost" that is often added to kernels). The gamers using the kernel are making statements that they couldn't imagine the game play any better than it already was, but now it's even smoother.
Unfortunately the way the Nubia software behaves, it auto-resets to power level 5 (which was 490mhz) on the 1.0BETA on boot and also after boosting the frequencies up. I tried every possible way to bypass this but eventually just gave in and removed frequencies. So the BETA1.10 and above have less frequencies but will always revert to 305mhz, the base minimum frequency of the device. Hopefully once we have AOSP ready I can add more.
MattoftheDead
I.e. M.O.D. Kernel Developer
The first Red Magic 5G OC kernel.
Xiaomi Mi9 / Mi9T Pro Pie V2 and Q V1.5 Kernel Dev

Nice work. Do you notice any benefits to OCing the GPU like that? I don't think there are many games that would benefit atm.

This is amazing !!! :laugh:

Is this going to work on all roms like CN, NA or EU Roms? Im currently running NA 3.11 flash from CN rom with root and twrp

We have people using it on CN Global and NA versions no problem at all. Works fine on every model.

Kernel is fully functional no issues at all.
CN Rom to NA Rom v3.11
305mhz min to 900mhz max confirmed and using smart pack to control the frequency
Thank you for this hopefully there is more development i really appreciate ur effort

Kernel building is just a hobby of mine, I was posting a minimal kernel to get some more kernel developers on board to hopefully add more features. I usually add Boeffla Wakelock Blocker and Dynamic Fsync and call it a basic kernel. The last super kernel I made took way too long, and I don't have that kind of time anymore - boost functions and underclocking to balance out the battery life and such. Development work doesn't pay anything, I didn't get the phone free, all my donations go to other developers. And I have a full time job and family. But if anyone wants to port over my MOD Kernel Q 1.5 Mi9 features, well that would be a super kernel. It's just really, really time consuming, time I don't have at the moment. And the merging of source has to be EXACT or you end up with a really slow phone rather one that balances underclocking, boost, and overclocking.

MishaalRahman said:
Nice work. Do you notice any benefits to OCing the GPU like that? I don't think there are many games that would benefit atm.
Click to expand...
Click to collapse
All the gamers using the kernel are reporting that the games run smoother than before, which no one thought was possible. It is already a flagship device. But the GPU OC with the Adreno driver scales when needed up to the frequencies that it has in the table and has no issue on 670, 800, and 900mhz reported so far. There are gamers on NA, Global, and CN ROMs, with no bugs reported. No issues and everything works properly. I have tested myself and although I'm not a gamer, all the functions work as they should. It still connects via Bluetooth, it still takes photos and videos, etc. There is no lag whatsoever. Overall I think the frequencies are ideal for this device with it's advanced active cooling system. Other devices however, with passive cooling, are unlikely to handle the increased GPU clocks.

I found an unusual bug where the GPU Minimum Frequency will reset on its own to 490mhz even if i set the minimum frequency to 305mhz im using smart pack kernel manager that you provided and cool tool btw to monitor the gpu frequency.
I also set the battery optimization to off on smart pack so it wont turn off itself.
This also happens when i played games that actually boost to 800 to 900mhz then after i close the game it sets back the minimum frequency to 490mhz so i have to set it again to 305mhz on the kernel manager to save more battery and lower the temps.
I also notice it sets back to 490mhz minimum frequency by just watching youtube videos so i have to set it back to 305mhz again. I tried different kernel manager too like Franco Kernel Manager and Kernel Audiator and still doesnt fix the issue
I think this was a minor bug for sure
I never touch the GPU governor btw
Performance was super nice thou i scored 645k on antutu on my first run but for now im going back to stock and gonna wait for your next update

What to do to root the phone without breaking the fingerprint please. I read the article publish nothing understood someone can explain to me step by step. I am an amateur I never root a phone. I have cn 2.55 16gb.

I don't have the same issue - I just tried to recreate it by watching a YouTube video and I went back to SmartPack and it still shows 305MHz GPU frequency. Although I'm using the debloated / optimized ROM I created Black Magic 5G which has everything setup properly, Nubia apps frozen, everything moved to 3rd party apps. NETFLIX patched to 4K HDR10, YouTube Vanced, a ton of root utilities, AdAway ad blocker, etc. You can find it on the Telegram channel (I'm using the NA/Global version of Black Magic 5G). Then I watched Netflix, still at 305mhz. As I have no idea how you've setup your phone, I just can't recreate it.
shaifabra5 said:
I found an unusual bug where the GPU Minimum Frequency will reset on its own to 490mhz even if i set the minimum frequency to 305mhz im using smart pack kernel manager that you provided and cool tool btw to monitor the gpu frequency.
I also set the battery optimization to off on smart pack so it wont turn off itself.
This also happens when i played games that actually boost to 800 to 900mhz then after i close the game it sets back the minimum frequency to 490mhz so i have to set it again to 305mhz on the kernel manager to save more battery and lower the temps.
I also notice it sets back to 490mhz minimum frequency by just watching youtube videos so i have to set it back to 305mhz again. I tried different kernel manager too like Franco Kernel Manager and Kernel Audiator and still doesnt fix the issue
I think this was a minor bug for sure
I never touch the GPU governor btw
Performance was super nice thou i scored 645k on antutu on my first run but for now im going back to stock and gonna wait for your next update
Click to expand...
Click to collapse

Yeah maybe because you modified the rom.
Im currently running Flash Global V3.11 when i tested your kernel no modification made im just rooted with TWRP Installed and i posted this kernel on red magic 5g group on facebook and 3 of us having the same issues as well.
Im gonna try it again on V3.13
UPDATE:
still returning to 490mhz as minimum frequency after gaming and after watching one youtube clip
kinda sad hopefully you can fix this bug on the global rom that nubia provided if you have the time, great kernel for gaming because of the 900mhz boost and the phone can sustain this boost because of the active fan

Why don't I have a roughly similar score?

Is it possible to overclock the CPU as well? They officially release the specs sheet of ROG Phone 3 it has overclocked CPU (3.091ghz) and an overclocked GPU. I know this phone can keep up with those clocks because of the cooling system but the problem is the battery life. But still, its worth it.

Blink003 said:
Is it possible to overclock the CPU as well? They officially release the specs sheet of ROG Phone 3 it has overclocked CPU (3.091ghz) and an overclocked GPU. I know this phone can keep up with those clocks because of the cooling system but the problem is the battery life. But still, its worth it.
Click to expand...
Click to collapse
I believe Qualcomm blocked overclocking of CPUs quite a while ago from SD845. Only GPUs can be overclocked.
Though I don't know if devs have gotten tools to get around it.

The 490 bug looks like it's related to the gaming mode APK resetting the min frequency. I can't decompile or recompile APKs so I don't have a way to get around the system reverting to 490 without removing 3 other frequencies. It seems hard-coded in the app that it only expects to see 5 frequencies so to have all working properly, 3 need to be removed. This is in contrast to what my buddy dev on the Op8 Pro can do, but this device is designed differently in how it boots and custom apps that increase frequency clocks. If any devs are good with APKs it's a very simple function call that sets the minimum GPU frequency. The only odd thing I see is that the minimum power level stays at 8 (minimum) which corresponds to the lowest clock speed. That number doesn't change in a kernel manager when the min GPU clock reverts to 490.
I'm off on vacation not near a PC but will try to come up with a stock # of clock frequencies that still scrolls smoothly between them and the Adreno GPU driver. May take a few tries but it's quite easy to modify. I already think 180mhz is too low from using it, it's more of a sleep frequency some suggested going this low but I think the phone design is for 300+. I prefer to use more clocks for better throttling but have to work with what we are given and do the best inside those boundaries.
No you can't raise CPU clocks on 865 devices that ROG device is supposedly using the 865+ or whatever the mid device is named between the 865 and 875. They have blocked CPU OC hardware wise for some time now.

mslezak said:
No you can't raise CPU clocks on 865 devices that ROG device is supposedly using the 865+ or whatever the mid device is named between the 865 and 875. They have blocked CPU OC hardware wise for some time now.
Click to expand...
Click to collapse
Qualcomm's Meizu’s CMO Wan Zhiqiang recently commented on Weibo saying that there won’t be a Snapdragon 865 Plus this year.
We will see!

No 865+ this year..
Trust me whatever they call it it's already defined in the source code as a second GPU bin clock for another device ID. So maybe it won't be called an 865+ but there is some device between the 865 and 875 coming out. I have OEM confirmation as well this device exists the name isn't important. I can tell you the top GPU frequency is 670mhz that's it, vs. the 587mhz default on the 865. Still the 865 handles 900mhz GPU no problem the only benefit would be higher CPU clocks. And an extra GPU clock. Which I'll attempt to spoof next time I get near a PC.

mslezak said:
Trust me whatever they call it it's already defined in the source code as a second GPU bin clock for another device ID. So maybe it won't be called an 865+ but there is some device between the 865 and 875 coming out. I have OEM confirmation as well this device exists the name isn't important. I can tell you the top GPU frequency is 670mhz that's it, vs. the 587mhz default on the 865. Still the 865 handles 900mhz GPU no problem the only benefit would be higher CPU clocks. And an extra GPU clock. Which I'll attempt to spoof next time I get near a PC.
Click to expand...
Click to collapse
Is it possible to overclock the memory clock too? I assumed that 900mhz is the core clock.

mslezak said:
Trust me whatever they call it it's already defined in the source code as a second GPU bin clock for another device ID. So maybe it won't be called an 865+ but there is some device between the 865 and 875 coming out. I have OEM confirmation as well this device exists the name isn't important. I can tell you the top GPU frequency is 670mhz that's it, vs. the 587mhz default on the 865. Still the 865 handles 900mhz GPU no problem the only benefit would be higher CPU clocks. And an extra GPU clock. Which I'll attempt to spoof next time I get near a PC.
Click to expand...
Click to collapse
You're right, that makes sense.
I'm glad they are making a refreshed chip.
On another note, do you think we will see an overclocking tool in the future?
Possibly with a custom ROM?