Related
With all the different kernel threads and other posts related to governor settings, one trend appears common. Many are stating their configuration as using a particular governor at a particular cpu min/max speed. This information is incomplete because there are other factors at work.
These other factors are the governor parameters. A governor by itself simply defines the logic used to scale the cpu speed. Each governor uses these parameters to determine thresholds, levels, frequency max/min's, etc.
These can be found in the location below; note, you need to use root explorer or similar.
/sys/devices/system/cpu/cpu0/cpufreq/
Some governor's have just a single parameter. For example performance only uses scaling_max_freq to set the maximum speed of the cpu. No other adjusts are permitted.
Powersave, on the other hand is the opposite, it's logic forces the cpu to run at the lowest speed at all times as determined by scaling_min_freq setting.
Ondemand builds on this and gives us more options:
up_threshold
scaling_max_freq
scaling_min_freq
sampling_rate
powersave_bias
ignore_nice_load
Conservative builds on Ondemand and offers these additional settings:
down_threshold
sampling_down_factor
freq_step
More information on the above governor's can be found here
Finally, there's there is something called smartass, which combines elements of conservative with a screen off profile. It offers parameters: (see lines 62-130 here
down_rate_us
up_min_freq
sleep_max_freq
sleep_wakeup_freq
awake_min_freq
sample_rate_jiffies
ramp_up_step
max_cpu_load
min_cpu_load
max_ramp_down
As you can see, you're given quite a bit of flexibility in configuration. Also, it's worth mentioning that there is some overlap. Conservative can be setup such that it closely mimics ondemand or performance; same for smartass.
Finally, contrary to what may have been read else where, there is nothing intelligent about smartass. It doesn't learn anything, nor does its logic change the more you use it. It just has more scope in what controls it. With some scripting magic (or setcpu), conservative or ondemand can also have a screen off profile.
From the information in this post and reading the links above, you can see just how much more there is to the whole governor game. More so, how meaningless a governor and low/high cpu freq statement really is.
Ultimately, the point of all this is to find an acceptable balance between performance (user experience), and battery life. In other words, we want to maximize performance while minimizing battery consumption. Achieving this is not so simple. Each device has some deviation, even with identical settings. The stock settings of any given kernel may not be ideal for your individual situation.
If you're trying to tweak this performance/battery balance, you owe it to yourself to be aware and familiar with the content of this thread.
Nice post... a bit redundant, but good to keep floating around also written noob friendly... thanks.
P.S. My dad had a gpz1100 he bored it out to a 1260cc that was a v-max killer.
Sent from my PC36100 using XDA Premium App
nice post:
the following link offers some more info (I don't quite like the frames of the IBM site and it takes ages to load)
CPU frequency scaling in Linux with cpufreq
thanks !
RM KERNEL
Just a statement regarding kernel source: The Kernel Source is of course covered under GPL version 2. Free software does NOT mean no work or time was spent working on it. I have donated a large sum of my free time to hack this kernel. If you use my modified kernel source in parts or in its entirety, I kindly ask you mention its origins and to send me a github pull request or PM whenever you find bugs or think you can help improve my kernel hack further. This way the entire community will truly benefit from the spirit of open source. Thank you
Rm -Kernel For Optimus me (pecan)
What is a Kernel?
The Kernel is the Foundation in which everything else builds upon in any software system.
NOTICE: This Kernel Only COMPATIBLE with Mine and Pax0r CM7.2 AND there Based Roms cooked roms.
Don't try to flash on stock roms or older cm7 or omgb/omfgb or cm9 roms becuase is not COMPATIBLE now with this roms
Please DO NOT use any task killers, they DO NOT improve performance nor battery life. They INTERFERE with your phone's stability (more crashes) and App compatibilities (Forced Close).
IMPORTANT NOTES
Click to expand...
Click to collapse
No Guarantees! If it kills your grandmother or your device ,I'm not responsible if
you brick your device by heavy OC, flashing, voiding your warranty,or any other pain or suffering you may feel as result of using this kernel!!! ...
Using using very high frequencies (OVER 806Mhz) is dangerous for your phone.
if you oc your phone OVER 806MHZ on my kernel then no support provided
(If you download, please hit Thanks below my post! Thank you!)
NOTE: after wipe battery,system recreate the battery stats, forcing the battery to lose its capacity, i advice you recalibrate the battery after doing that.
KNOW BUGS
Click to expand...
Click to collapse
Not All CHIPS ARE CREATED EQUAL
Download:
No Guarantees! If it kills your grandmother or your device, I am NOT responsible! If you understand this:
(If you download, please hit Thanks below my post! Thank you!)
*RC12* [STABLE] Click me
Old Downloads: Click Me
INSTALL
Click to expand...
Click to collapse
How to Flash/Install the Kernel
Root Your LG Optimus Me , Then Install Custom Recovery
Download Newer Version Of Rm 32 Kernel From Topic
Copy Zip File to Sd Card
Reboot Your Phone To Recovery Mode
Wipe Cache,Wipe Dalvik Cache And Battery
Now Install Kernel And Enjoy:laugh:
Note: After FLASHING, the first reboot may take longer than usual, please be patient... After the first reboot, it may lag during initial load (let everything finish loading). Once everything is loaded and phone is ready for use, reboot the phone a 2nd time and the lag will be gone and everything should be silky smooth...
SOURCE
Click to expand...
Click to collapse
I respect the GPL (the license covering the Linux kernel), so all the up-to-date source code for this kernel is avaiable on my github:https://github.com/kerneldevs/RM-32-kernel-pecan
My kernel is, in turn, based on the publicly-avaiable froyo kernel source from LG. You're free to fork, modify, and re-release the code as your own, but you must provide the source code for your resulting work. Doing so ensures you honor the terms of the license, but you're also giving back to the community. Basically, don't be a ****.
THANKS TO
Click to expand...
Click to collapse
drapalyuk- initial setup of pecan kernel source and for biggest work for this device
pax0r- 2nd setup of pecan kernel source and also for biggest work for this device
codeaurora forum - source and patches
Mik9-SOME PATCHES THAT I USED IN MY KERNEL
Fserve-for sharing his kernel source from his source i got some idea for this kernel
Andy572-used some patches
Tasssadar-for his kernel source based on mik9 kernel
Roqu3-for his kernel source for p350, i got a 1 fix from his source
Cyanogenmod - for sharing their kernel source code, used some 1 patches from cm kernel source.
burstlam- got i nice idea about kgsl from his zte blade source
SUPPORT
Click to expand...
Click to collapse
IF YOU LIKE MY WORK YOU CAN USE DONATE BUTTON TO SUPPORT MY WORK OR YOU CAN PRESS THANKS BUTTON TO SHOW YOUR SUPPORT .
SOME INFO OF SOME KERNEL THINGS
Click to expand...
Click to collapse
CleanCache(via ZCache backend)
ZCACHE is a compressed cache similar to ZRAM but the similarity ends there. ZCache is meant to provide as many "cleancache" pages (non-dirty or untouched "virgin" memory) to apps that request for new memory. CleanCache is very easy to allocate and no additional penalty are required to hand them out, so having more CleanCache pages will improve performance. Under heavy memory pressure, often times the kernel will NOT have enough CleanCache pages, so the kernel has to do EXTRA work to reclaim dirty cache pages and clean them for the new apps that's requesting for them. The described process creates a performance hit for the kernel and the app, so the idea is to use compression to create more CleanCache pages available for use. Of course there's a penalty to pay for using compression, but the trade-off between compression penalty and the penalty for reclaiming dirty cache pages and allocating them after cleaning is smaller for compression, so in the end, CleanCache should add more performance.
USER experience BENCHMARK ARE MOVED TO THIS LINK
MORE
Click to expand...
Click to collapse
WANT FAST NEWS ABOUT MY WORK? THEN JOIN MY FACEBOOK GROUP : https://www.facebook.com/groups/OADPROM/
If you want to donate some bucks for the work that i'm doing for LG Optimus Me, go to the my username and hit the 'donate to me' button. Otherwise I would be grateful if you can click the "Thanks" button on the bottom right of this post.
THANKS TO ALL
CHANGELOG
CHANGELOG
OLD CHANGELOG OF RM VERSIONS ARE MOVED CLICK HERE TO SEE OLD CHANGELOG
09-07-2012 RC7 http://www.mediafire.com/?sxh8wt2u1b9493t
serial: msm_serial_hs_lite: Use pm_runtime to indicate device state
mm: Make memory hotplug aware of memmap holes
mfd: Use min_uV for voltage setting
msm: timer: read clocksource from global clock variable.
msm_bus: APIs for MSM bus scaling.
arm: add ARM-specific memory low-power support
msm: rmnet: Add tailroom for sk buffer to be transmitted
msm: Add Timpani Sound Device Profile
14-07-2012 RC8 http://www.mediafire.com/?ld6lrnbxrghdewb
msm: camera: Support for Dynamic Camera Logging
add backlight driver in st1.5
msm: mfd: Use debugfs interface to allow timpani codec register access
spi_qsd: Modify timeout mechanism to check SPI state valid bit.
Define and process new type of memory tag (ATAG_MEM_RESERVED)
msm: Add XO aggregation and voting API stubs
Add tpmd_dev from the tpm-emulator source to the kernel
arm: common: CP register access tool for Read/Write to CP registers
serial: msm_serial_hs: Use runtime PM for HSUART power state transitions
21-07-2012 RC10 http://www.mediafire.com/?97g5pqr71xuuj9h
rcu: "Tiny RCU", The Bloatwatch Edition
fs: simple fsync race fix
Increase readahead value
acpuclock tweaks
axi oc back
add the Stochastic Fair Blue (SFB) network scheduler - from zachariasmaladroit
sched: Fix over-scheduling bug [author andy572]
block: introduce the BFQ I/O scheduler
block: Fix atomic functions in bfq & update bfq to v2
msm_kgsl: Fix corner cases while adding ringbuffer commands
msm_kgsl: Take the driver lock after waiting for wakeup to complete
msm_kgsl: enable writecombine
msm: 7x27: Update the SDC2 GPIO disable configs
msm: 7x27: mmc: Add platform data for dummy CMD52
usb: msm_gadget: Check both USB state and VBUS during initialization
and some more small changes, check github repo for that
25-07-2012 RC11 http://www.mediafire.com/?3l6fi81l4no860t
mmc: msm_sdcc: Enhance the current mechanism of simulating PIO interrupt
msm: socinfo: move sysdev creation outside init
fs: mark_inode_dirty barrier fix
vmalloc: remove redundant unlikely()
mm: remove likely() from mapping_unevictable()
mm: remove likely() from grab_cache_page_write_begin()
writeback: avoid unnecessary determine_dirtyable_memory call
brk: fix min_brk lower bound computation for COMPAT_BRK
mm/dmapool.c: take lock only once in dma_pool_free()
mm/dmapool.c: use TASK_UNINTERRUPTIBLE in dma_pool_alloc()
fs/select.c: fix information leak to userspace
PM: Lock PM device list mutex in show_dev_hash()
PM: Prototype the pm_generic_ operations
mmc: Attribute the IO wait time properly in mmc_wait_for_req().
Wifi fix
Last version of RM Kernel
09-08-2012 RC12 http://www.mediafire.com/?j6e21kzhdhw3x3v
revert axi oc back
revert update acpuclock
netlink: Make nlmsg_find_attr take a const nlmsghdr*.
netfilter/nf_conntrack_netlink: fix ctnetlink_parse_tuple()
net/ethernet/eth: remove deprecated: print_mac() [Marin Mitov]
ipv4/netfilter/nf_nat_standalone: workaround to make -Wswitch happy
ipv6/xfrm6_tunnel: missing middle operand
fs/ext4/move_extent: fix uninitialized start_ext.ee_block [tytso]
cpufreq: fix memory leak in cpufreq_add_dev [Xiaotian Feng]
cgroup: introduce cancel_attach() [Daisuke Nishimura]
block: rescan partitions on invalidated devices on -ENOMEDIA too
block: add proper state guards to __elv_next_request
mtd: mtdconcat: fix NAND OOB write
HERE THE INFO OF ANDROID GOV
ALL CREDITS GO TO Deedii
Android CPU governors explained
1: OnDemand
2: OndemandX
3: Performance
4: Powersave
5: Conservative
6: Userspace
7: Min Max
8: Interactive
9: InteractiveX
10: Smartass
11: SmartassV2
12: Scary
13: Lagfree
14: Smoothass
15: Brazilianwax
16: SavagedZen
17: Lazy
18: Lionheart
19: LionheartX
20: Intellidemand
21: Hotplug
1: OnDemand Governor:
This governor has a hair trigger for boosting clockspeed to the maximum speed set by the user. If the CPU load placed by the user abates, the OnDemand governor will slowly step back down through the kernel's frequency steppings until it settles at the lowest possible frequency, or the user executes another task to demand a ramp.
OnDemand has excellent interface fluidity because of its high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand is commonly chosen by smartphone manufacturers because it is well-tested, reliable, and virtually guarantees the smoothest possible performance for the phone. This is so because users are vastly more likely to ***** about performance than they are the few hours of extra battery life another governor could have granted them.
This final fact is important to know before you read about the Interactive governor: OnDemand scales its clockspeed in a work queue context. In other words, once the task that triggered the clockspeed ramp is finished, OnDemand will attempt to move the clockspeed back to minimum. If the user executes another task that triggers OnDemand's ramp, the clockspeed will bounce from minimum to maximum. This can happen especially frequently if the user is multi-tasking. This, too, has negative implications for battery life.2: OndemandX:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
3: Performance Governor:
This locks the phone's CPU at maximum frequency. While this may sound like an ugly idea, there is growing evidence to suggest that running a phone at its maximum frequency at all times will allow a faster race-to-idle. Race-to-idle is the process by which a phone completes a given task, such as syncing email, and returns the CPU to the extremely efficient low-power state. This still requires extensive testing, and a kernel that properly implements a given CPU's C-states (low power states).4: Powersave Governor:
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
5:Conservative Governor:
This biases the phone to prefer the lowest possible clockspeed as often as possible. In other words, a larger and more persistent load must be placed on the CPU before the conservative governor will be prompted to raise the CPU clockspeed. Depending on how the developer has implemented this governor, and the minimum clockspeed chosen by the user, the conservative governor can introduce choppy performance. On the other hand, it can be good for battery life.
The Conservative Governor is also frequently described as a "slow OnDemand," if that helps to give you a more complete picture of its functionality.6: Userspace Governor:
This governor, exceptionally rare for the world of mobile devices, allows any program executed by the user to set the CPU's operating frequency. This governor is more common amongst servers or desktop PCs where an application (like a power profile app) needs privileges to set the CPU clockspeed.
7: Min Max
well this governor makes use of only min & maximum frequency based on workload... no intermediate frequencies are used.8: Interactive Governor:
Much like the OnDemand governor, the Interactive governor dynamically scales CPU clockspeed in response to the workload placed on the CPU by the user. This is where the similarities end. Interactive is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Unlike OnDemand, which you'll recall scales clockspeed in the context of a work queue, Interactive scales the clockspeed over the course of a timer set arbitrarily by the kernel developer. In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. This can eliminate the frequency bouncing discussed in the OnDemand section. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. This is another pro-battery life benefit of Interactive.
However, because Interactive is permitted to spend more time at maximum frequency than OnDemand (for device performance reasons), the battery-saving benefits discussed above are effectively negated. Long story short, Interactive offers better performance than OnDemand (some say the best performance of any governor) and negligibly different battery life.
Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.9: InteractiveX Governor:
Created by kernel developer "Imoseyon," the InteractiveX governor is based heavily on the Interactive governor, enhanced with tuned timer parameters to better balance battery vs. performance. The InteractiveX governor's defining feature, however, is that it locks the CPU frequency to the user's lowest defined speed when the screen is off.10: Smartass
Is based on the concept of the interactive governor.
I have always agreed that in theory the way interactive works – by taking over the idle loop – is very attractive. I have never managed to tweak it so it would behave decently in real life. Smartass is a complete rewrite of the code plus more. I think its a success. Performance is on par with the “old” minmax and I think smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Smartass will also cap the max frequency when sleeping to 352Mhz (or if your min frequency is higher than 352 – why?! – it will cap it to your min frequency). Lets take for example the 528/176 kernel, it will sleep at 352/176. No need for sleep profiles any more!"11: SmartassV2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery.12: Scary
A new governor wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It will give the same performance as conservative right now, it will get tweaked over time.13: Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.14: Smoothass:
The same as the Smartass “governor” But MUCH more aggressive & across the board this one has a better battery life that is about a third better than stock KERNEL15: Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery16: SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.17: Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.18: Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source.
The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.19: LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.20: Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors)
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
21: Hotplug Governor:
The Hotplug governor performs very similarly to the OnDemand governor, with the added benefit of being more precise about how it steps down through the kernel's frequency table as the governor measures the user's CPU load. However, the Hotplug governor's defining feature is its ability to turn unused CPU cores off during periods of low CPU utilization. This is known as "hotplugging."
Obviously, this governor is only available on multi-core devices.
=============================================
ALL CREDITS GO TO THE USERS OF XDA WHO CREATED DIFF THREADS ABOUT I/O, THIS I/O INFO FROM ALL THREADS
ALL INFO ABOUT I/O
Click to expand...
Click to collapse
I/O:- short form of Input & OutputI/O Scheduler:- Input/output (I/O) scheduling is a term used to describe the method computer operating systems decide the order that block I/O operations will be submitted to storage volumes. I/O Scheduling is sometimes called 'disk scheduling'.
I/O schedulers can have many purposes depending on the goal of the I/O scheduler, some common goals are:
- To minimize time wasted by hard disk seeks.
- To prioritize a certain processes' I/O requests.
- To give a share of the disk bandwidth to each running process.
- To guarantee that certain requests will be issued before a particular deadline.Info on I/O Scheduler
SIO:- cheduler is based on the deadline scheduler but it's more like a mix between no-op and deadline.In other words, SIO is like a lighter version of deadline but it doesn't do any kind of sorting, so it's aimed mainly for random-access devices (like SSD hard disks) where request sorting is no needed (as any sector can be accesed in a constant time, regardless of its physical location).NOOP:- The NOOP scheduler inserts all incoming I/O requests into a simple, unordered FIFO queue and implements request merging.
The scheduler assumes I/O performance optimization will be handled at some other layer of the I/O hierarchy; e.g., at the block device; by an intelligent HBA such as a Serial Attached SCSI (SAS) RAID controller or by an externally attached controller such as a storage subsystem accessed through a switched Storage Area Network.ANTICIPATORY:- Anticipatory scheduling is an algorithm for scheduling hard disk input/output.
It seeks to increase the efficiency of disk utilization by "anticipating" synchronous read operations.
ADAPTIVE ANTICIPATORY SCHEDULER:- For the anticipatory scheduler, we scale up the anticipation timeout (antic expire) using the latency scaling factor over time. When the virtual disk latencies are low a small scaling of the timeout is sucient to prevent deceptive idleness, whereas when the latencies are high a larger scaling of the timeout value may be required to achieve the same. Note that such dynamic setting of the timeout value ensures that we attain a good trade-o between throughput (lost due to idling) and deceptive idleness mitigation. Setting a high value for the scaling factor (increasing idling time) only happens when the disk service latencies themselves are higher. This may not necessarily cause a signicant loss in throughput, because submitting a request from another process instead of idling is not going to improve throughput if the virtual disk itself does not get any faster than it is at the current period. A higher anticipation timeout might also be capable of absorbing process scheduling eects inside the VM. The results for the adaptive anticipatory scheduler are shown in Figure 2. The read time with our modied implementation (third bar in the dierent scheduler combi- nations) shows that it is possible to mitigate the eects of deceptive idleness by adapting the timeout. An interesting related observation is that the level to which the improve- ment is possible varies for dierent Domain-0 schedulers; noop - 39%, anticipatory - 67% and cfq - 36%. This again points to the fact that the I/O scheduler used in Domain-0 is important for the VM's ability in enforcing I/O scheduling guarantees. Dierent Domain-0 I/O schedulers likely have a dierent service latency footprint inside the VMs, contributing to dierent levels of improvement.CFQ:-CFQ, also known as "Completely Fair Queuing", is an I/O scheduler for the
Linux kernel which was written in 2003 by Jens Axboe.
CFQ works by placing synchronous requests submitted by processes into a number of per-process queues and then allocating timeslices for each of the queues to access the disk. The length of the time slice and the number of requests a queue is allowed to submit depends on the IO priority of the given process. Asynchronous requests for all processes are batched together in fewer queues, one per priority.DEADLINE:- The goal of the Deadline scheduler is to attempt to guarantee a start service time for a request. It does that by imposing a deadline on all I/O operations to prevent starvation of requests. It also maintains two deadline queues, in addition to the sorted queues (both read and write). Deadline queues are basically sorted by their deadline (the expiration time), while the sorted queues are sorted by the sector number.
Before serving the next request, the Deadline scheduler decides which queue to use. Read queues are given a higher priority, because processes usually block on read operations. Next, the Deadline scheduler checks if the first request in the deadline queue has expired. Otherwise, the scheduler serves a batch of requests from the sorted queue. In both cases, the scheduler also serves a batch of requests following the chosen request in the sorted queue.V(R):- The next request is decided based on its distance from the last request, with a multiplicative penalty of `rev_penalty' applied for reversing the head direction. A rev_penalty of 1 means SSTF behaviour. As this variable is increased, the algorithm approaches pure SCAN. Setting rev_penalty to 0 forces SCAN.
SIMPLE:- Does not do any kind of sorting, as it is aimed foraleatory access devices, but it does some basic merging. We try to keep minimum overhead to achieve low latency.BFQ:- BFQ is a proportional share disk scheduling algorithm based on the slice-by-slice service scheme of CFQ. But BFQ assigns budgets, measured in number of sectors, to tasks instead of time slices. The disk is not granted to the active task for a given time slice, but until it has exahusted its assigned budget. This change from the time to the service domain allows BFQ to distribute the disk bandwidth among tasks as desired, without any distortion due to ZBR, workload fluctuations or other factors. BFQ uses an ad hoc internal scheduler, called B-WF2Q+, to schedule tasks according to their budgets. Thanks to this accurate scheduler, BFQ can afford to assign high budgets to disk-bound non-seeky tasks (to boost the throughput), and yet guarantee low latencies to interactive and soft real-time applications.
cips gokhle said:
Welcome to my RM kernel thread
About
THIS KERNEL IS BASED ON PECAN KERNEL .
RM KERNEL IS a very optimized kernel for 2.3 ROMS (in 2.2 you will face problem). i made this kernel to push performance as hard as it can.
Features & Changelog
Installation
Reboot intro recovery
Flash the latest kernel
Reboot
Enjoy
NOTE: THIS KERNEL IS ONLY FOR MY CM NIGHTLY AND PAX0R CM7.2 ROMS. DON'T FLASH ON VIVEK CM7.2,OMFGB,OMGB AND CM7.1 AND 2.2 ROMS. (FOR CM7.1,OMFGB,OMGB AND VIVEK CM7.2 I'M MAKING ANOTHER VERSION)
Downloads
V1000: http://www.mediafire.com/?aw3t3jrz99151zy
Click to expand...
Click to collapse
Goodjob bro
I will try
cooler1182 said:
Goodjob bro
I will try
Click to expand...
Click to collapse
i'm waiting for your review
I not absolutely well understand what changes installation of this kernel will make.
zizka said:
I not absolutely well understand what changes installation of this kernel will make.
Click to expand...
Click to collapse
this kernel will improve your touch screen and improve your phone performance
but about touch screen it's best work with my nightly
I made backup of data and established your kernel. Phone surprisingly quickly is loaded. Programs on a memory card need time that they could be used. Touch works also well as before. Changes didn't see. There can be I blind put on Nightly9
zizka said:
I made backup of data and established your kernel. Phone surprisingly quickly is loaded. Programs on a memory card need time that they could be used. Touch works also well as before. Changes didn't see. There can be I blind put on Nightly9
Click to expand...
Click to collapse
hmm in fb group 1 tested this and it's work for him any way in nightly 10 have update version of this kernel 2.6.32.59
now, I can mount the SD-ext with link2sd. In Fruit Ninja you feel the difference, is faster and more responsive than ever
I dont see changes. Multitouch have bug axis inversion and performance no changes for me. Thxs!
THIS KERNEL IS NOW OBSOLETE, DON'T USE IT.
newest and stable kernel releases are now integrated into my version of CYANOGENMOD 7.2
cn u just upload to some other site?? mediafire isnt working! m not able to download
ethan1234 said:
cn u just upload to some other site?? mediafire isnt working! m not able to download
Click to expand...
Click to collapse
SEE THIS
http://forum.xda-developers.com/showpost.php?p=25967572&postcount=12
Guys project restarted take test guys
this kernel is better than .35?
agen47 said:
this kernel is better than .35?
Click to expand...
Click to collapse
yes it's better it have new things that 1st time for p350
i tried both versions of this kernel and both worked well cant really tell the performance difference in vsync off, maybe in some heavy games a few more fps. atm im using vsync on on kang2 running at 806mhz no kernel panic yet
agen47 said:
i tried both versions of this kernel and both worked well cant really tell the performance difference in vsync off, maybe in some heavy games a few more fps. atm im using vsync on on kang2 running at 806mhz no kernel panic yet
Click to expand...
Click to collapse
you will be only feel diff in games on vsync off
here's the basic description about vsync:
vsync off = great for benchmarks but crap in real life.
vsync on = crap for benchmarks great in real life.
Say your screen refreshes at 60Hz - Vsync on will attempt to display 30fps to avoid tearing. 30 goes into 60 twice evenly... get it?
Vsync off will display as many fps as possible. So rather than holding back and displaying 30fps it will allow 35fps. This will cause tearing because 35 does not go into 60 evenly.
It's the same affect you get when playing video games on a PC.
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
So here it is. I have had the note II since a couple weeks after its release for T-Mobile USA and have loved it since, like most of you I am sure. With that being said, what is the fun of having an android phone without changing some things to make it better?! This is a kernel based off of the Jellybean kernel source straight from Samsung themselves. I finally hit a point I felt worthy of release in this kernel so am doing just that. With that being said it is a long way from where I am sure it will be in the end. I benchmarked it against the stock kernel and MB4 with much higher scores so am pleased with that along with the battery life I am experiencing with it. Hope you all enjoy it and don't be shy to post anything you would like to see added or changed in future releases of this kernel. Thank you all.
I highly recommend doing a full CWM backup of everything as if you were flashing a ROM as this will back up everything including the previous kernel being used prior to flashing this.
The Note II packs its modules with the kernel now including the very important wifi module needed to use wifi so as of now it's looking like I will have to upload multiple zips for each ROM. Just post which ROMs you are using so I can get an idea what boot.img's you guys need exactly so I can post the corresponding flashable zip. If anyone knows of a better method of doing this feel free to let me know.
Prerequisites:
- Root
- CWM Recovery
There are a few steps to flashing this like any other Android Software:
1. Download the zip that matches the version/ROM you are using
2. Place zip on the root of either your internal or external
3. Enter Recovery and perform a CWM backup (optional but highly recommended)
4. Select "flash zip" in recovery and select the zip you downloaded and placed on your sdcard
5. Reboot
Downloads Section
Mod edit: Download links and other information removed
Changelog
Kernel #3
- CRT TV OFF support
- Charge Control System implemented *thanks to Andrei for his code*
- Charge Control enabled (Fast USB Charge)
- Crude fast USB charge disabled
- Sysfs helper file added for c control
- Faster device boot time
- Sensorhub write for every boot disabled *thanks to Andrei*
- Dynamic FSync Control System implemented and enabled *thanks to Andrei for this code*
- Increased VOODOO Headset frequency
- BFQ Scheduler set to default scheduler
- Updated ck BFS kernel optimizations for speed
- BFS modifications to kernel elements still in effect
- BFS CPU Scheduler disabled for now
- CFS CPU Scheduler enabled now
Kernel #2
- Added BFS CPU scheduler! *Written by Con Kolivas thank you buddy*
- BFS 406 currently in use
- BFS patch backported manually applied successfully (no code left out)
- Read about BFS in the post below
- VOODOO enhanced sound engine added *committed by ptmr*
- VOODOO enhanced sound engine enabled
- 16GB eMMC SDS (sudden death syndrome) patch applied *thanks to samsung*
- 16GB brick fix applied
- Exynos Memory security hole fixed *thanks to andreilux for the patch*
- Faster USB charge enabled
- Added NEW BFQ v6r1 I/O Scheduler *haven't seen anyone else using r1 supposed to benchmark higher than v6*
- Added Early Queue Merge code to BFQ I/O Scheduler
- I/O context updated for BFQ
- Added ROW I/O Scheduler
- Added SIO I/O Scheduler
- Added VR I/O Scheduler
- Added ZEN I/O Scheduler
- Deadline Scheduler optimized for flash devices (our devices)
- More Deadline Scheduler optimizations
- Added Triangle Away support *thanks chainfire*
- NTFS filesystem support
- NTFS read+WRITE enabled
- CPU hyperthreading enabled
Kernel #1
- EXT partitions using relatime
- EXT support compiled into kernel, not as a module
- EXT 1/2/3 support
- EXT 4 support with backwards compatibility
- EXT 4 used for EXT 2/3 filesystems
- Added Interactive governor
- Added Conservative governor
- Overclockable up to 1.9Ghz *thanks Glewarne*
- Support for controllable voltage interface for CPU
- Reduced CPU frequency transition for snappy response time from CPU
- Optimized GPU for higher performance and longer battery life
- Added low frequencies for GPU to save battery when not doing gfx intense tasks
- Added Overclocked frequencies for GPU *thanks to Glewarne for added freqs and tables*
- Undervolted GPU to save battery life at all times
- Increased memory allocation for GPU
- Removed Mali GPU state tracking
- Reduced Mali GPU utilization calculation timeout
- Added optimized ARM RWSEM algorithm
- Enabled Swap capability
- Compiled with emu optimizations
- Extra RAM being fed to GPU
- VPN support included as module
- Included every module stock kernel does plus some extras
- Other changes made I will remember to add here
Kernel #1 Benchmark (Stock T-Mobile MB4 ROM)
{
"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"
}
+BFS - The Brain **** Scheduler by Con Kolivas.
+
+Goals.
+
+The goal of the Brain **** Scheduler, referred to as BFS from here on, is to
+completely do away with the complex designs of the past for the cpu process
+scheduler and instead implement one that is very simple in basic design.
+The main focus of BFS is to achieve excellent desktop interactivity and
+responsiveness without heuristics and tuning knobs that are difficult to
+understand, impossible to model and predict the effect of, and when tuned to
+one workload cause massive detriment to another.
+
+
+Design summary.
+
+BFS is best described as a single runqueue, O lookup, earliest effective
+virtual deadline first design, loosely based on EEVDF (earliest eligible virtual
+deadline first) and my previous Staircase Deadline scheduler. Each component
+shall be described in order to understand the significance of, and reasoning for
+it. The codebase when the first stable version was released was approximately
+9000 lines less code than the existing mainline linux kernel scheduler (in
+2.6.31). This does not even take into account the removal of documentation and
+the cgroups code that is not used.
+
+Design reasoning.
+
+The single runqueue refers to the queued but not running processes for the
+entire system, regardless of the number of CPUs. The reason for going back to
+a single runqueue design is that once multiple runqueues are introduced,
+per-CPU or otherwise, there will be complex interactions as each runqueue will
+be responsible for the scheduling latency and fairness of the tasks only on its
+own runqueue, and to achieve fairness and low latency across multiple CPUs, any
+advantage in throughput of having CPU local tasks causes other disadvantages.
+This is due to requiring a very complex balancing system to at best achieve some
+semblance of fairness across CPUs and can only maintain relatively low latency
+for tasks bound to the same CPUs, not across them. To increase said fairness
+and latency across CPUs, the advantage of local runqueue locking, which makes
+for better scalability, is lost due to having to grab multiple locks.
+
+A significant feature of BFS is that all accounting is done purely based on CPU
+used and nowhere is sleep time used in any way to determine entitlement or
+interactivity. Interactivity "estimators" that use some kind of sleep/run
+algorithm are doomed to fail to detect all interactive tasks, and to falsely tag
+tasks that aren't interactive as being so. The reason for this is that it is
+close to impossible to determine that when a task is sleeping, whether it is
+doing it voluntarily, as in a userspace application waiting for input in the
+form of a mouse click or otherwise, or involuntarily, because it is waiting for
+another thread, process, I/O, kernel activity or whatever. Thus, such an
+estimator will introduce corner cases, and more heuristics will be required to
+cope with those corner cases, introducing more corner cases and failed
+interactivity detection and so on. Interactivity in BFS is built into the design
+by virtue of the fact that tasks that are waking up have not used up their quota
+of CPU time, and have earlier effective deadlines, thereby making it very likely
+they will preempt any CPU bound task of equivalent nice level. See below for
+more information on the virtual deadline mechanism. Even if they do not preempt
+a running task, because the rr interval is guaranteed to have a bound upper
+limit on how long a task will wait for, it will be scheduled within a timeframe
+that will not cause visible interface jitter.
+
+
+Design details.
+
+Task insertion.
+
+BFS inserts tasks into each relevant queue as an O(1) insertion into a double
+linked list. On insertion, *every* running queue is checked to see if the newly
+queued task can run on any idle queue, or preempt the lowest running task on the
+system. This is how the cross-CPU scheduling of BFS achieves significantly lower
+latency per extra CPU the system has. In this case the lookup is, in the worst
+case scenario, O where n is the number of CPUs on the system.
+
+Data protection.
+
+BFS has one single lock protecting the process local data of every task in the
+global queue. Thus every insertion, removal and modification of task data in the
+global runqueue needs to grab the global lock. However, once a task is taken by
+a CPU, the CPU has its own local data copy of the running process' accounting
+information which only that CPU accesses and modifies (such as during a
+timer tick) thus allowing the accounting data to be updated lockless. Once a
+CPU has taken a task to run, it removes it from the global queue. Thus the
+global queue only ever has, at most,
+
+ (number of tasks requesting cpu time) - (number of logical CPUs) + 1
+
+tasks in the global queue. This value is relevant for the time taken to look up
+tasks during scheduling. This will increase if many tasks with CPU affinity set
+in their policy to limit which CPUs they're allowed to run on if they outnumber
+the number of CPUs. The +1 is because when rescheduling a task, the CPU's
+currently running task is put back on the queue. Lookup will be described after
+the virtual deadline mechanism is explained.
+
+Virtual deadline.
+
+The key to achieving low latency, scheduling fairness, and "nice level"
+distribution in BFS is entirely in the virtual deadline mechanism. The one
+tunable in BFS is the rr_interval, or "round robin interval". This is the
+maximum time two SCHED_OTHER (or SCHED_NORMAL, the common scheduling policy)
+tasks of the same nice level will be running for, or looking at it the other
+way around, the longest duration two tasks of the same nice level will be
+delayed for. When a task requests cpu time, it is given a quota (time_slice)
+equal to the rr_interval and a virtual deadline. The virtual deadline is
+offset from the current time in jiffies by this equation:
+
+ jiffies + (prio_ratio * rr_interval)
+
+The prio_ratio is determined as a ratio compared to the baseline of nice -20
+and increases by 10% per nice level. The deadline is a virtual one only in that
+no guarantee is placed that a task will actually be scheduled by this time, but
+it is used to compare which task should go next. There are three components to
+how a task is next chosen. First is time_slice expiration. If a task runs out
+of its time_slice, it is descheduled, the time_slice is refilled, and the
+deadline reset to that formula above. Second is sleep, where a task no longer
+is requesting CPU for whatever reason. The time_slice and deadline are _not_
+adjusted in this case and are just carried over for when the task is next
+scheduled. Third is preemption, and that is when a newly waking task is deemed
+higher priority than a currently running task on any cpu by virtue of the fact
+that it has an earlier virtual deadline than the currently running task. The
+earlier deadline is the key to which task is next chosen for the first and
+second cases. Once a task is descheduled, it is put back on the queue, and an
+O lookup of all queued-but-not-running tasks is done to determine which has
+the earliest deadline and that task is chosen to receive CPU next.
+
+The CPU proportion of different nice tasks works out to be approximately the
+
+ (prio_ratio difference)^2
+
+The reason it is squared is that a task's deadline does not change while it is
+running unless it runs out of time_slice. Thus, even if the time actually
+passes the deadline of another task that is queued, it will not get CPU time
+unless the current running task deschedules, and the time "base" (jiffies) is
+constantly moving.
+
+Task lookup.
+
+BFS has 103 priority queues. 100 of these are dedicated to the static priority
+of realtime tasks, and the remaining 3 are, in order of best to worst priority,
+SCHED_ISO (isochronous), SCHED_NORMAL, and SCHED_IDLEPRIO (idle priority
+scheduling). When a task of these priorities is queued, a bitmap of running
+priorities is set showing which of these priorities has tasks waiting for CPU
+time. When a CPU is made to reschedule, the lookup for the next task to get
+CPU time is performed in the following way:
+
+First the bitmap is checked to see what static priority tasks are queued. If
+any realtime priorities are found, the corresponding queue is checked and the
+first task listed there is taken (provided CPU affinity is suitable) and lookup
+is complete. If the priority corresponds to a SCHED_ISO task, they are also
+taken in FIFO order (as they behave like SCHED_RR). If the priority corresponds
+to either SCHED_NORMAL or SCHED_IDLEPRIO, then the lookup becomes O. At this
+stage, every task in the runlist that corresponds to that priority is checked
+to see which has the earliest set deadline, and (provided it has suitable CPU
+affinity) it is taken off the runqueue and given the CPU. If a task has an
+expired deadline, it is taken and the rest of the lookup aborted (as they are
+chosen in FIFO order).
+
+Thus, the lookup is O in the worst case only, where n is as described
+earlier, as tasks may be chosen before the whole task list is looked over.
+
+
+Scalability.
+
+The major limitations of BFS will be that of scalability, as the separate
+runqueue designs will have less lock contention as the number of CPUs rises.
+However they do not scale linearly even with separate runqueues as multiple
+runqueues will need to be locked concurrently on such designs to be able to
+achieve fair CPU balancing, to try and achieve some sort of nice-level fairness
+across CPUs, and to achieve low enough latency for tasks on a busy CPU when
+other CPUs would be more suited. BFS has the advantage that it requires no
+balancing algorithm whatsoever, as balancing occurs by proxy simply because
+all CPUs draw off the global runqueue, in priority and deadline order. Despite
+the fact that scalability is _not_ the prime concern of BFS, it both shows very
+good scalability to smaller numbers of CPUs and is likely a more scalable design
+at these numbers of CPUs.
+
+It also has some very low overhead scalability features built into the design
+when it has been deemed their overhead is so marginal that they're worth adding.
+The first is the local copy of the running process' data to the CPU it's running
+on to allow that data to be updated lockless where possible. Then there is
+deference paid to the last CPU a task was running on, by trying that CPU first
+when looking for an idle CPU to use the next time it's scheduled. Finally there
+is the notion of "sticky" tasks that are flagged when they are involuntarily
+descheduled, meaning they still want further CPU time. This sticky flag is
+used to bias heavily against those tasks being scheduled on a different CPU
+unless that CPU would be otherwise idle. When a cpu frequency governor is used
+that scales with CPU load, such as ondemand, sticky tasks are not scheduled
+on a different CPU at all, preferring instead to go idle. This means the CPU
+they were bound to is more likely to increase its speed while the other CPU
+will go idle, thus speeding up total task execution time and likely decreasing
+power usage. This is the only scenario where BFS will allow a CPU to go idle
+in preference to scheduling a task on the earliest available spare CPU.
+
+The real cost of migrating a task from one CPU to another is entirely dependant
+on the cache footprint of the task, how cache intensive the task is, how long
+it's been running on that CPU to take up the bulk of its cache, how big the CPU
+cache is, how fast and how layered the CPU cache is, how fast a context switch
+is... and so on. In other words, it's close to random in the real world where we
+do more than just one sole workload. The only thing we can be sure of is that
+it's not free. So BFS uses the principle that an idle CPU is a wasted CPU and
+utilising idle CPUs is more important than cache locality, and cache locality
+only plays a part after that.
+
+When choosing an idle CPU for a waking task, the cache locality is determined
+according to where the task last ran and then idle CPUs are ranked from best
+to worst to choose the most suitable idle CPU based on cache locality, NUMA
+node locality and hyperthread sibling business. They are chosen in the
+following preference (if idle):
+
+* Same core, idle or busy cache, idle threads
+* Other core, same cache, idle or busy cache, idle threads.
+* Same node, other CPU, idle cache, idle threads.
+* Same node, other CPU, busy cache, idle threads.
+* Same core, busy threads.
+* Other core, same cache, busy threads.
+* Same node, other CPU, busy threads.
+* Other node, other CPU, idle cache, idle threads.
+* Other node, other CPU, busy cache, idle threads.
+* Other node, other CPU, busy threads.
+
+This shows the SMT or "hyperthread" awareness in the design as well which will
+choose a real idle core first before a logical SMT sibling which already has
+tasks on the physical CPU.
+
+Early benchmarking of BFS suggested scalability dropped off at the 16 CPU mark.
+However this benchmarking was performed on an earlier design that was far less
+scalable than the current one so it's hard to know how scalable it is in terms
+of both CPUs (due to the global runqueue) and heavily loaded machines (due to
+O lookup) at this stage. Note that in terms of scalability, the number of
+_logical_ CPUs matters, not the number of _physical_ CPUs. Thus, a dual (2x)
+quad core (4X) hyperthreaded (2X) machine is effectively a 16X. Newer benchmark
+results are very promising indeed, without needing to tweak any knobs, features
+or options. Benchmark contributions are most welcome.
+
+
+Features
+
+As the initial prime target audience for BFS was the average desktop user, it
+was designed to not need tweaking, tuning or have features set to obtain benefit
+from it. Thus the number of knobs and features has been kept to an absolute
+minimum and should not require extra user input for the vast majority of cases.
+There are precisely 2 tunables, and 2 extra scheduling policies. The rr_interval
+and iso_cpu tunables, and the SCHED_ISO and SCHED_IDLEPRIO policies. In addition
+to this, BFS also uses sub-tick accounting. What BFS does _not_ now feature is
+support for CGROUPS. The average user should neither need to know what these
+are, nor should they need to be using them to have good desktop behaviour.
+
+rr_interval
+
+There is only one "scheduler" tunable, the round robin interval. This can be
+accessed in
+
+ /proc/sys/kernel/rr_interval
+
+The value is in milliseconds, and the default value is set to 6ms. Valid values
+are from 1 to 1000. Decreasing the value will decrease latencies at the cost of
+decreasing throughput, while increasing it will improve throughput, but at the
+cost of worsening latencies. The accuracy of the rr interval is limited by HZ
+resolution of the kernel configuration. Thus, the worst case latencies are
+usually slightly higher than this actual value. BFS uses "dithering" to try and
+minimise the effect the Hz limitation has. The default value of 6 is not an
+arbitrary one. It is based on the fact that humans can detect jitter at
+approximately 7ms, so aiming for much lower latencies is pointless under most
+circumstances. It is worth noting this fact when comparing the latency
+performance of BFS to other schedulers. Worst case latencies being higher than
+7ms are far worse than average latencies not being in the microsecond range.
+Experimentation has shown that rr intervals being increased up to 300 can
+improve throughput but beyond that, scheduling noise from elsewhere prevents
+further demonstrable throughput.
+
+Isochronous scheduling.
+
+Isochronous scheduling is a unique scheduling policy designed to provide
+near-real-time performance to unprivileged (ie non-root) users without the
+ability to starve the machine indefinitely. Isochronous tasks (which means
+"same time") are set using, for example, the schedtool application like so:
+
+ schedtool -I -e amarok
+
+This will start the audio application "amarok" as SCHED_ISO. How SCHED_ISO works
+is that it has a priority level between true realtime tasks and SCHED_NORMAL
+which would allow them to preempt all normal tasks, in a SCHED_RR fashion (ie,
+if multiple SCHED_ISO tasks are running, they purely round robin at rr_interval
+rate). However if ISO tasks run for more than a tunable finite amount of time,
+they are then demoted back to SCHED_NORMAL scheduling. This finite amount of
+time is the percentage of _total CPU_ available across the machine, configurable
+as a percentage in the following "resource handling" tunable (as opposed to a
+scheduler tunable):
+
+ /proc/sys/kernel/iso_cpu
+
+and is set to 70% by default. It is calculated over a rolling 5 second average
+Because it is the total CPU available, it means that on a multi CPU machine, it
+is possible to have an ISO task running as realtime scheduling indefinitely on
+just one CPU, as the other CPUs will be available. Setting this to 100 is the
+equivalent of giving all users SCHED_RR access and setting it to 0 removes the
+ability to run any pseudo-realtime tasks.
+
+A feature of BFS is that it detects when an application tries to obtain a
+realtime policy (SCHED_RR or SCHED_FIFO) and the caller does not have the
+appropriate privileges to use those policies. When it detects this, it will
+give the task SCHED_ISO policy instead. Thus it is transparent to the user.
+Because some applications constantly set their policy as well as their nice
+level, there is potential for them to undo the override specified by the user
+on the command line of setting the policy to SCHED_ISO. To counter this, once
+a task has been set to SCHED_ISO policy, it needs superuser privileges to set
+it back to SCHED_NORMAL. This will ensure the task remains ISO and all child
+processes and threads will also inherit the ISO policy.
+
+Idleprio scheduling.
+
+Idleprio scheduling is a scheduling policy designed to give out CPU to a task
+_only_ when the CPU would be otherwise idle. The idea behind this is to allow
+ultra low priority tasks to be run in the background that have virtually no
+effect on the foreground tasks. This is ideally suited to distributed computing
+clients (like setiathome, folding, mprime etc) but can also be used to start
+a video encode or so on without any slowdown of other tasks. To avoid this
+policy from grabbing shared resources and holding them indefinitely, if it
+detects a state where the task is waiting on I/O, the machine is about to
+suspend to ram and so on, it will transiently schedule them as SCHED_NORMAL. As
+per the Isochronous task management, once a task has been scheduled as IDLEPRIO,
+it cannot be put back to SCHED_NORMAL without superuser privileges. Tasks can
+be set to start as SCHED_IDLEPRIO with the schedtool command like so:
+
+ schedtool -D -e ./mprime
+
+Subtick accounting.
+
+It is surprisingly difficult to get accurate CPU accounting, and in many cases,
+the accounting is done by simply determining what is happening at the precise
+moment a timer tick fires off. This becomes increasingly inaccurate as the
+timer tick frequency (HZ) is lowered. It is possible to create an application
+which uses almost 100% CPU, yet by being descheduled at the right time, records
+zero CPU usage. While the main problem with this is that there are possible
+security implications, it is also difficult to determine how much CPU a task
+really does use. BFS tries to use the sub-tick accounting from the TSC clock,
+where possible, to determine real CPU usage. This is not entirely reliable, but
+is far more likely to produce accurate CPU usage data than the existing designs
+and will not show tasks as consuming no CPU usage when they actually are. Thus,
+the amount of CPU reported as being used by BFS will more accurately represent
+how much CPU the task itself is using (as is shown for example by the 'time'
+application), so the reported values may be quite different to other schedulers.
+Values reported as the 'load' are more prone to problems with this design, but
+per process values are closer to real usage. When comparing throughput of BFS
+to other designs, it is important to compare the actual completed work in terms
+of total wall clock time taken and total work done, rather than the reported
+"cpu usage".
Thanks I'll flash and report back. Running tweaked 2.0
Push push
Sent from my SGH-T889 using xda app-developers app
Thank you for your work
Sent from my SGH-T889 using xda premium
Which zip do we install?
does your kernel support voodoo app?
edit: No voodoo support (I have to have voodoo support)
you should also add that your kernel changes boot screen/image
fast charging over USB?
CPU voltage edit, underclock?
I saw a whole bunch of GPU "editables" I think was cool.
If you are running jellybean flash the top download in the download section. Don't forget to make a backup first
Sent from my SGH-T889 using xda app-developers app
will the King also be releasing a ROM?
We'll see but I gotta say google has done such a great job with MB4 at this time I don't see the need.
With that being said I'm going to continue work on this kernel and I'm pleased with the benchmark improvements im seeing compared to stock
Sent from my SGH-T889 using xda app-developers app
I flashed it but wasnt recognizing my exfat 64 gb sd.Going back to stock kernel
Sent from my SGH-T889 using xda premium
Thank you I will definately look into this
Have been listening to your inputs and have some nice additions for kernel #2
Sent from my SGH-T889 using xda app-developers app
AngryDinosaur said:
Thank you for your work
Sent from my SGH-T889 using xda premium
Click to expand...
Click to collapse
Hey buddy have you notice my magic trick yet?
Sent from my GT-N5110 using Tapatalk 2
Any chance u can add a dual boot with this kernel? Just wondering
Sent from my SGH-T889 using xda premium
theXeffect said:
Any chance u can add a dual boot with this kernel? Just wondering
Sent from my SGH-T889 using xda premium
Click to expand...
Click to collapse
There is someone working on that already.
http://forum.xda-developers.com/showthread.php?p=40410021
Sent from my GT-N7105 using xda premium
theXeffect said:
Any chance u can add a dual boot with this kernel? Just wondering
Sent from my SGH-T889 using xda premium
Click to expand...
Click to collapse
Yah I'll look into that friend. usually just release an aosp and sammy version same kernel as each other just ones for aosp and one is for samsung
Side note per your guys requests voodoo patch among lots of other additions coming in kernel #2 update shaping up nicely. Thanks for all your input appreciate it.
Sent from my SGH-T889 using xda app-developers app
fast charging IMHO is the most useful so the phone isn't dying while being used for GPS or whatever. Undervolt makes me nervous though. I'll watch for a bit to see if there are any reports of phones bricking before trying it. Its not as easy to swap this phone as it was with Sprint if it dies.
robl45 said:
fast charging IMHO is the most useful so the phone isn't dying while being used for GPS or whatever. Undervolt makes me nervous though. I'll watch for a bit to see if there are any reports of phones bricking before trying it. Its not as easy to swap this phone as it was with Sprint if it dies.
Click to expand...
Click to collapse
Fast charge with charge control is coming in kernel #2 (thanks to Andrei for writing that code from scratch)
As for your concern with bricking ive been using kernel #1 for months now do lots of 3d gaming and cpu + gpu intensive tasks and haven't had one reboot or any instability. You wouldn't see any adverse effects from a very slight undervolt as they still get ample juice to function properly.
Sent from my SGH-T889 using xda app-developers app
I just flashed your kernel #1 and I love it!!! Its so fast I just love it I'm on a stock samsung galaxy note 2 with stock jellybean 4.1.2 and with your kernel its rocking thank you
Sent from my SGH-T889 using Tapatalk 4 Beta
Thank to zhanjia & Andrux
I Search about Governors And I/O Schedulers in Google & XDA
Iam sharing this information to our yu Team members .because the Governors And I/O Schedulers is the main part of the Kernels .
Governors And I/O Schedulers
1.Performance
2.Battery
3.Gaming
4.Laging
5.Multitasking
CPU Governors
What is a CPU governor?
A CPU governor in Android controls how the CPU raises and lowers its frequency in response to the demands the user is placing on their device. Governors are especially important in smartphones and tablets because they have a large impact on the apparent fluidity of the interface and the battery life of the device over a charge.
NOTE: You cannot change your CPU governor unless your phone is rooted and you have a ROM or app that lets you make a change. Also, different kernels (the intermediary software between your phone's hardware and the operating system) offer different sets of governors.
Available CPU governors:
OnDemand
Conservative
Interactive
Performance
Powersave
Scary
Userspace
Smartass
SmartassV2
Smoothass
Brazilianwax
SavagedZen
Lagfree
MinMax
Interactivex
OnDemand
OnDemand
Available in most kernels, and the default governor in most kernels. When the CPU load reaches a certain point, OnDemand will rapidly scale the CPU up to meet the demand, then gradually scale the CPU down when it isn't needed.
Review
Brief says all. By a simple explantion, OnDemand scales up to the required frequency to undergo the action you are doing and rapidly scales down after use.
Conservative
It is similar to the OnDemand governor, but will scale the CPU up more gradually to better fit demand. Conservative governor provides a less responsive experience than OnDemand, but it does save batter
Review
Conservative is the opposite of Interactive; it will slowly ramp up the frequency, then quickly drops the frequency once the CPU is no longer under a certain usage.
Interactive
Available in latest kernels, it is the default scaling option in some stock kernels. Interactive governor is similar to the OnDemand governor with an even greater focus on responsiveness.
Review
Interactive is the opposite of Conservative; it quickly scales up to the maximum allowed frequency, then slowly drops the frequency once no longer in use.
Performance
Performance governer locks the phone's CPU at maximum frequency. While this may sound like an ugly idea, there is growing evidence to suggest that running a phone at its maximum frequency at all times will allow a faster race-to-idle. Race-to-idle is the process by which a phone completes a given task. After that it returns the CPU to extremely efficient low-power state.
Review
Good at gaming, Really good. Disadvantages are it may damage your phone if too much usage.
Powersave
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
Review
Set it to your desired minimum frequency and you won't have to look for your charger for once in a while.
Scary
A new governor wrote based on Conservative with some Smartass features, it scales accordingly to Conservative's way. It will start from the bottom. It spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It will give the same performance as Conservative right now.
Review
Hmm.. Overall I don't see any difference. After I understand its main objective. I was very curious and decided to use it again. Results are the same.. No difference. Report to me if anyone has tested this.
Userspace
Userspace is not a governor pre-set, but instead allows for non-kernel daemons or apps with root permissions to control the frequency. Commonly seen as a redundant and not useful since SetCPU and NoFrills exist.
Review
Highly not recommended for use.
Smartass
It is based on the concept of the Interactive governor.
Smartass is a complete rewrite of the code of Interactive. Performance is on par with the “old” minmax and Smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Review
Smartass is rather the governer that will save your battery and make use of your processor for daily use. Like the brief explantion said " Smartass will spend much more time on lower frequencies." So logically you don't need for sleep profiles anymore.
SmartassV2
Theoretically a merge of the best properties of Interactive and OnDemand; automatically reduces the maximum CPU frequency when phone is idle or asleep, and attempts to balance performance with efficiency by focusing on an "ideal" frequency.
Review
This is a much favourite to everybody. I believe almost everyone here is using SmartassV2. Yes, it is better than Smartass because of its speed no scaling frequencies from min to max at a short period of time.
Smoothass
A much more aggressive version of Smartass that is very quick to ramp up and down, and keeps the idle/asleep maximum frequency even lower.
Review
In my personal experience, this is really useful for daily use. And yes, I'm using it all the time. It may decrease your battery life. I saw it OC itself to 1.4 gHz when I set it to 1.2. Good use. Recommended.
Brazilianwax
Similar to SmartassV2. More aggressive scaling, so more performance, but less battery.
Review
Based on SmartassV2. But its advantage is a much more performance wise governor.
SavagedZen
Another SmartassV2 based governor. Achieves good balance between performance & battery as compared to Brazilianwax.
Review
Not much difference compared to SmartassV2. But it is a optimized version of it.
Lagfree
Again, similar to Smartass but based on Conservative rather than Interactive, instantly jumps to a certain CPU frequency after the device wakes, then operates similar to Conservative. However, it has been noted as being very slow when down-scaling, taking up to a second to switch frequencies.
Review
Used it before. Like the name of the governor, I didn't experience any lag whatsoever. Another governor based on performance, but not battery efficient.
MinMax
MinMax is just a normal governor. No scaling intermediate frequency scaling is used.
Review
Well.. it's too normal that I can't really say anything about it..
Interactivex
InteractiveX governor is based heavily on the Interactive governor, enhanced with tuned timer parameters to optimize the balance of battery vs performance. InteractiveX governor's defining feature, however, is that it locks the CPU frequency to the user's lowest defined speed when the screen is off.
Review
A better understanding from the brief to you users, this is an Interactive governor with a wake profile. More battery friendly than Interactive.
GPU Governors
Ondemand
Much like the CPU governor, Ondemand will ramp up the frequency when a load is detected. A good balance between performance and battery savings.*
MSM-Adreno
The default GPU governor used by qualcomm for their adreno GPUs. It is more performance orientated than ondemand therefore it gives better performance in games but less battery life.*
Performance
As the name suggests, this keeps your GPU running at the max frequency. This is a governor if you want the best possible experience in games but you don't care about your battery life.*
Powersave
Like the CPU governor, this keeps your GPU running at the lowest possible frequency. Best battery life
I/O Schedulers
What is an I/O Scheduler:
*Input/output (I/O) scheduling is a term used to describe the method computer operating systems decide the order that block I/O operations will be submitted to storage volumes. I/O Scheduling is sometimes called 'disk scheduling'.
I/O schedulers can have many purposes depending on the goal of the I/O scheduler, some common goals
To minimise time wasted by hard disk seeks.
To prioritise a certain processes' I/O requests.
To give a share of the disk bandwidth to each running process.
To guarantee that certain requests will be issued before a particular deadline.
Available*I/O schedulers
CFQ *
Deadline *
VR *
Noop*
Anticipatory
BFQ
FIOPS
SIO (Simple)
Row
ZEN
Sioplus
FIFO*
Tripndroid
Anticipatory:*
Two important things here are indicative of that event:*
- Looking on the flash drive is very slow from boot
- Write operations while at any time are processed, however, be read operations preferred, ie, this scheduler returns the read operations a higher priority than the write operations.*
Benefits:*
- Requests of read accesses are never treated secondarily, that has equally good reading performance on flash drives like noop.
Disadvantages:*
- Requests from process operations are not always available*
- Reduced write performance on high-performance hard drives*
- Not very common in most kernels
CFQ:*
The CFQ - Completely Fair Queuing - similar to the Dead Line maintains a scalable continuous Process-I/O, the available I / O bandwidth is *fairly and evenly shared to all I / O requests to distribute. It creates a statistics between blocks and processes. With these statistics it can "guess" when the next block is requested by what process, each process queue contains requests of synchronous processes, which in turn is dependent upon the priority of the original process. There the V2 version has some fixes, such as I / O request improvements, hunger fixes , and some small search backward integrated to improve responsiveness.This is the default IO scheduler for Samsung smartphones.*
Benefits:*
- Has a well balanced I / O performance
- Excellent on multiprocessor systems*
- Easiest to tune.
- Best performance of the database after the deadline*
- Is the default IO scheduler for most mobile phones today
- Good for multitasking*
Disadvantages:*
- *Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.*
- Jitter (worst case delay) can sometimes be very high because the number of competing with each other process tasks*
Deadline:*
This scheduler has the goal of reducing I / O wait time of a process of inquiry. This is done using the block numbers of the data on the drive. This also blocks an outlying block numbers are processed, each request receives a maximum delivery time. This is in addition to the Governor BFQ, it is very popular and is in many well known kernels.*
Benefits:*
- It is nearly a real-time scheduler.*
- Excels in reducing latency of any given single I/O*
- Best scheduler for database access and queries.*
- Does quite well in benchmarks, most likely the best
- Like noop, a good scheduler for solid state/flash drives
- Good for light and medium multitasking workloads
Disadvantages:*
- If the phone is overloaded, crashing or unexpected closure of processes can occur*
- Bad battery life if doing a lot of multitasking
ROW:
ROW stands for "READ Over WRITE"which is the main requests dispatch policy of this algorithm. The ROW IO scheduler was developed with the mobile devices needs in mind. In mobile devices we favor user experience upon everything else,thus we want to give READ IO requests as much priority as possible. In mobile devices we won't have as much parallel threads as on desktops. Usually it's a single thread or at most 2 simultaneous working threads for read & write. Favoring READ requests over WRITEs decreases the READ latency greatly.
The main idea of the ROW scheduling policy is: If there are READ requests in pipe - dispatch them but don't starve the WRITE requests too much. Bellow you'll find a small comparison of ROW to existing schedulers. The test that was run for these measurements is parallel read and write.
Benefits:
- Faster UI navigation and better overall phone experience
- Faster boot times and app launch times*
- Possibly better battery life
- Sometimes used by default for custom roms and custom kernels
Disadvantages:
- Slower write speeds
- Some intensive applications like games could slow down your phone
SIO (Simple):*
It aims to achieve with minimal effort at a low latency I / O requests. Not a priority to put in queue, instead simply merge the requests. This scheduler is a mix between the noop and deadline. There is no conversion or sorting of requests.*
Benefits:*
- It is simple and stable.
- Reliable IO scheduler
- Minimized starvation for inquiries
- Good battery life
Disadvantages:*
- Slow random write speeds on flash drives as opposed to other schedulers.
- Sequential read speeds on flash drives, not as good*
Noop:*
The noop scheduler is the simplest of them. It is best suited for storage devices that are not subject to mechanical movements, such as our flash drives in our phones use to access the data. The advantage is that flash drives do not require rearrangement of the I / O requests, unlike normal hard drives. the data that come first are written first. It's basically not a real scheduler, as it leaves the scheduling of the hardware.*
Benefits:*
- Serves I/O requests with least number of cpu cycles.
- Is suitable for flash drives because there is no search errors*
- Good data throughput on db systems
Disadvantages:*
- Reducing the number of CPU cycles corresponds to a simultaneous decline in performance*
- Not very good at multitasking
VR:*
Unlike other scheduling software, synchronous and asynchronous requests are not handled separately, but it will impose a fair and balanced within this deadline requests, that the next request to be served is a function of distance from the last request. It is a very good scheduler with elements of the deadline scheduler. It is the best for MTD Android devices. Vr can make the most of the benchmark points, but it is also an unstable scheduler. *Sometimes the scores fluctuate below the average, sometimes it fluctuates above the average.*
Benefits:
- Generally excels in random writes.*
Disadvantages:*
- Performance variability can lead to different results (Only performs well sometimes)
- Very often unstable and unreliable
BFQ:*
Instead requests divided into time segments as the CFQ has, on the BFQ budget. The flash drive will be granted an active process until it has exhausted its budget (number of sectors on the flash drive). The awards BFQ high budget does not read tasks. BFQ has received many updates to the scheduler and the performance is consistently improving.*
Benefits:*
- Has a very good USB data transfer rate.*
- The best scheduler for playback of HD video recording and video streaming (due to less jitter than CFQ Scheduler, and others)*
- Regarded as a very precise working Scheduler*
- Delivers 30% more throughput than CFQ
- Being constantly updated
- Good for multitasking*
Disadvantages:*
- Not the best scheduler for benchmarks*
- Higher budgets that were allocated to a process that can affect the interactivity and bring with it increased latency.*
- Slower UI navigation
- Slower boot times
ZEN:
Based on the VR Scheduler. It's an FCFS (First come, first serve) based algorithm. It's not strictly FIFO. It does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ons. Other than that, pretty much the same as no-op.
Benefits:
- Well rounded IO Scheduler
- Very efficient IO Scheduler
- More stable than VR, mainly because it doesn't really behave like VR.*
Disadvantages:
- Not found in all kernels
Sioplus:
Based on the original Sio scheduler with improvements. Functionality for specifying the starvation of async reads against sync reads; starved write requests counter only counts when there actually are write requests in the queue; fixed a bug).*
Benefits:
- Better read and write speeds than previous SIO scheduler
- Good battery life*
Disadvantages:
- The same as SIO scheduler
- Not found in all kernels
FIOPS:*
This new I/O scheduler is designed around the following assumptions about Flash-based storage devices: no I/O seek time, read and write I/O cost is usually different from rotating media, time to make a request depends upon the request size, and high through-put and higher IOPS with low-latency.
Benefits:
- Achieves high read and write speeds in benchmarks
- Good battery life
Disadvantages:
- Not very common in most kernels
FIFO (First in First Out):
A relatively simple io schedulers that does what has been described. It is also known as FCFS (First come first serve) but this really isn't true. It does basic sorting; sorting the processes according to the appropriate order and nothing else. In other words, it is quite similar to noop.*
Benefits:
- Serves I/O requests with least number of cpu cycles.
- Is suitable for flash drives because there is no search errors
- Good data throughput on db systems
Disadvantages:
- Reducing the number of CPU cycles corresponds to a simultaneous decline in performance*
- Not very good at multitasking
Tripndroid
A new I/O scheduler based on noop, deadline and vr and meant to have minimal overhead. Made by TripNRaVeR
Recommended IO schedulers:
For everyday usage:
- SIO (My personal favourite)
- NOOP
- CFQ (Third choice)
- Deadline (Forth choice)
- ROW (My second choice)
- ZEN
For battery life:
- SIO (First choice)
- FIOPS*
- NOOP (Second choice)
- ROW (Third choice)
- FIFO
For gaming:*
- Deadline (First choice)
- CFQ (Second choice)*
- ROW (Third choice)
For performance(Benchmarking):
- VR
- SIO (Third Choice)
- Deadline (Second choice)
- FIOPS (First choice)*
For multitasking:*
- BFQ (Third choice)
- Deadline (Second choice)
- CFQ (First choice)
IO Scheduler Comparison
Overall performance:
Best<------------------------------------------------------------------------->Worst
FIOPS> Noop > ZEN >SIOplus > SIO > ROW > Tripndroid > VR > Deadline > BFQ > CFQ
Multitasking performance:
Less Apps<------------------------------------------------------------>Many Apps
Noop < FIOPS < SIO < *SIOplus < ROW < Tripndroid < ZEN < Deadline < VR < *CFQ < BFQ
Battery life:
Best<-------------------------------------------------------------------------> Worst
Noop > FIOPS > SIOplus > SIO > ROW> *ZEN > Tripndroid > Deadline > VR > CFQ > BFQ
ela1103 said:
Thank to zhanjia & Andrux
I Search about Governors And I/O Schedulers in Google & XDA
Iam sharing this information to our yu Team members .because the Governors And I/O Schedulers is the main part of the Kernels .
Governors And I/O Schedulers
1.Performance
2.Battery
3.Gaming
4.Laging
5.Multitasking
Click to expand...
Click to collapse
Thanks, very informative!
schubeir
Thanks man for the info, i knew few of them and now all:good::good::good:
No credits??? I'm sure those descriptions for I/O schedulers came from me
Thanks been looking for something like this
Sent from my Pixel XL using Tapatalk