Develop Bugs

I/O scheduler 'Q

Im currently running latest omgb with chads ingenious beta while using no frills cpu app. Is it better to run the stock bfq or use noop considering noop is for flash based devices?

No-op has to be the worst of all option. It's so bad, not even HTC uses it in their stock kernels. Deadline is FAR more optimized for MMC drives and devices. BFQ, depending on what you do with your device, may be quicker, may not be. CFQ isn't bad of AOSP, but displays noticeable lag on many Sense ROMs. VR.... well, good luck finding info on that one. Personally, I would stick with either BFQ or Deadline.

giving deadline a shot and seems smoother

Rock n roll. Glad to hear.

CPU governor and I/O Scheduler questions!

HI everyone. i have yet another question! lol.
i tried looking on google but noting specific for the epic. i was curious what the best cpu governor and the i/o scheduler is.
for the schedulers i have noop, cfq, bfq, deadline and sio
for cpu governors i have interactive, interactive x, ondemand, smartass, smartass v2 userspace, performance, conservative and powersave.

I use SmartassV2 and noop. SmartassV2, in my opinion, keeps the CPU frequencies low unless the power is really needed. Ondemand works well, but it is a little to generous some times. I use noop because it works well with flash memory. I am going to try out deadline because it seems like it would allow apps to load faster.

Just a quick FYI...
The SIO scheduler is supposed to be based on noop and deadline.
I haven't done much testing with it, but it specifically says it's designed for flash devices.
=]

nubecoder said:
Just a quick FYI...
The SIO scheduler is supposed to be based on noop and deadline.
I haven't done much testing with it, but it specifically says it's designed for flash devices.
=]
Click to expand...
Click to collapse
I was doing some testing with Quadrant and SIO gets the highest score. I am going to try it out this week and see how it is in the long run. Thanks for the heads up nube.

Gavisann said:
I was doing some testing with Quadrant and SIO gets the highest score. I am going to try it out this week and see how it is in the long run. Thanks for the heads up nube.
Click to expand...
Click to collapse
thank you. i noticed that sio was getting the best quadrant scores too.

nubecoder said:
Just a quick FYI...
The SIO scheduler is supposed to be based on noop and deadline.
I haven't done much testing with it, but it specifically says it's designed for flash devices.
=]
Click to expand...
Click to collapse
Thank you for the amazing rom! one of the best for the epic right now.

kirt231 said:
Thank you for the amazing rom! one of the best for the epic right now.
Click to expand...
Click to collapse
=]
I don't do roms...
Some roms might be using my kernel though, so I understand the confusion.
=]

SIO seems faster but drains the heck out of my battery??
Im using VC deadline and ondemand and Im still at 100% 3 hrs unplugged with some minor messing around....ran the stopwatch for a bit trying to figure out what the hell was buzzing every (as it turns out) 1min. and have been messing around with the ui.
Nothing maujor but a few weeks ago I would have been at 90% by now easy

using smartassv2
with deadline quadrant score 2739
with sio 2733
both are good but as sio is lite version of deadline with a mix of noop so its balanced
deadline can cause some troubles if a program got stuck but its a performer
im using samsung galaxy sl i9003(ti omap3630 at 1.1ghz)

So far I am really loving SIO and smartassV2. My phone is fast when I need it to be and great on battery. From my rough calculations, I drain about 4% an hour when the phone is idle and about 7-10% an hour when I am browsing or watching a video. By the end of an average day, my battery lasts about 14-18 hours.

[REF][Super Friendly] Explanation of Governors, I/O Schedulers and Kernels [24-Nov]

Introduction
"It takes few hours to make a thread but it doesn't even take few seconds to say Thanks"- arpith.fbi
Click to expand...
Click to collapse
Code:
Don't be afraid to ask me anything.
I won't bite, but I might lick you.
Just thank me for this super brief thread.
Give credits to this thread by linking it if you're using any of my info.
Thank you to you too
Have you unlocked your bootloader of your current device ? If so, read it ! If not, learn the benifits ! :victory:
What is this thread about ? It is a very brief explanation of every governors and schedulers to let you find the best combo for your device.
I've been searching a lot about informations about Kernels, Governors, I/O Schedulers and also Android Optimization Tips. No matter its Google or XDA or other android forums. I will go into it and try the best I can to find these infos. So I thought of sharing it to here for the Xperia S, Acro S, and Ion[COLOR] users.
My main reason to share this is to benefit users for better knowledge about Kernels, Governors, I/O Schedulers and Tips on Android Optimization. I'm not aware of whether where this should be posted, its related to kernels, governors and schedulers so I think it would be best if I share it to here. Yes, I wrote it word by word with references.Happy learning. :angel:
After months on XDA, no matter its in a development forum or Off Topic forum. Users kept on asking what's this what's that. And I'm sure that not all members will understand what is it until they bump into my thread
FAQs regarding on :-
-I/O Schedulers
-Kernel Governers
-Better RAM
-Better Battery
-FAQs
*Will add more when I found something useful.
Click to expand...
Click to collapse
I do a lot of asking by PM, to learn, it doesn't matter whether its a stupid one. (People who know me understands)
With my experience and lots of asking. I managed to find a lot of infos that we can use to optimize our phone.
I will try to explain as clear as I can.
Governors :-
-Smoothass
-Smartass
-SmartassV2
-SavagedZen
-Interactivex
-Lagfree
-Minmax
-Ondemand
-Conservative
-Brazilianwax
-Userspace
-Powersave
-Performance
-Scary
-Lulzactive *
-Intellidemand *
-Badass *
-Lionheart *
-Lionheartx *
-Virtuous *
* Not enough information about it, will add it later on.
Explanation
OnDemand
Brief
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.
Click to expand...
Click to collapse
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
Brief
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
Click to expand...
Click to collapse
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
Brief
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.
Click to expand...
Click to collapse
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
Brief
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.
Click to expand...
Click to collapse
Review
Good at gaming, Really good. Disadvantages are it may damage your phone if too much usage.
Powersave
Brief
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
Click to expand...
Click to collapse
Review
Set it to your desired minimum frequency and you won't have to look for your charger for once in a while.
Scary
Brief
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.
Click to expand...
Click to collapse
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
Brief
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.
Click to expand...
Click to collapse
Review
Highly not recommended for use.
Smartass
Brief
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.
Click to expand...
Click to collapse
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
Brief
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.
Click to expand...
Click to collapse
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
Brief
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.
Click to expand...
Click to collapse
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
Brief
Similar to SmartassV2. More aggressive scaling, so more performance, but less battery.
Click to expand...
Click to collapse
Review
Based on SmartassV2. But its advantage is a much more performance wise governor.
SavagedZen
Brief
Another SmartassV2 based governor. Achieves good balance between performance & battery as compared to Brazilianwax.
Click to expand...
Click to collapse
Review
Not much difference compared to SmartassV2. But it is a optimized version of it.
Lagfree
Brief
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.
Click to expand...
Click to collapse
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
Brief
MinMax is just a normal governor. No scaling intermediate frequency scaling is used.
Click to expand...
Click to collapse
Review
Well.. it's too normal that I can't really say anything about it..
Interactivex
Brief
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.
Click to expand...
Click to collapse
Review
A better understanding from the brief to you users, this is an Interactive governor with a wake profile. More battery friendly than Interactive.
Due to current kernels doesn't have these governors. I will be delaying the explanation, its very interesting. If you want it ASAP, post below
-Lulzactive *
-Intellidemand *
-Badass *
-Lionheart *
-Lionheartx *
-Virtuous *
**********************************************************************************************************************************************************************
I/O Schedulers(thanks to droidphile)
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.
Click to expand...
Click to collapse
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. 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.
Click to expand...
Click to collapse
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.
Click to expand...
Click to collapse
BFQ
nstead 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.
Click to expand...
Click to collapse
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.
Click to expand...
Click to collapse
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.
Click to expand...
Click to collapse
VR
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.
Click to expand...
Click to collapse
Credits
-droidphile
-kokzhanjia

Reserved for kernel info

Many thanks for sharing your knowledge on all of this! You made it very easy to understand
Sent from my LT26i using xda app-developers app

Thank u very much!

Thanks a lot !
Sent from my Xperia S using xda premium

Thanks for gathering all this info, it is a very handy guide.
You may want to add that this all works on locked bootloader as well. The big difference is you only get the stock kernel choices & no over clock. I use conservative & cfq thru 'cpu master' my locked ION
~Jaramie
Sent from my ION

how about hotplug - pegasusq ??????? can u explain this governors ?????

Segarys said:
Many thanks for sharing your knowledge on all of this! You made it very easy to understand
Sent from my LT26i using xda app-developers app
Click to expand...
Click to collapse
davidbar93 said:
Thank u very much!
Click to expand...
Click to collapse
Xecutioner_Venom said:
Thanks a lot !
Sent from my Xperia S using xda premium
Click to expand...
Click to collapse
ToledoJab said:
Thanks for gathering all this info, it is a very handy guide.
You may want to add that this all works on locked bootloader as well. The big difference is you only get the stock kernel choices & no over clock. I use conservative & cfq thru 'cpu master' my locked ION
~Jaramie
Sent from my ION
Click to expand...
Click to collapse
Thanks
saberamani said:
how about hotplug - pegasusq ??????? can u explain this governors ?????
Click to expand...
Click to collapse
Yeah, i will add it along with other unexplained governors
Thanks for reminding..

[Q] Need Advice for Performance Setting

I used touchwi5 build 3 Rom by ipromeh.
can anyone give me advice to choose CPU Governor and IO Governor for the best battery life and performance? and how the best setting for Memory management (zRam, Purging of Assets, and KSM)?
thanks before.
Sorry for my bad english.

For the best result, try Galaxy S4 life companion!!
*nah, just kidding*
For the governor, most users used smartassV2 OR lulzactive, but some were satisfied using hyper. And for the I/O, ROW or SIO, but you may try vr.
For memory management, you will have to try it yourself. Because 'good settings' may vary per user.
No, I wasn't sending this from my computer.

Kreaz said:
For the best result, try Galaxy S4 life companion!!
*nah, just kidding*
For the governor, most users used smartassV2 OR lulzactive, but some were satisfied using hyper. And for the I/O, ROW or SIO, but you may try vr.
For memory management, you will have to try it yourself. Because 'good settings' may vary per user.
No, I wasn't sending this from my computer.
Click to expand...
Click to collapse
hahaha..what a nice comment on 1st line..
Sent from my GT-I8150 using Tapatalk 2

Kreaz said:
For the best result, try Galaxy S4 life companion!!
*nah, just kidding*
For the governor, most users used smartassV2 OR lulzactive, but some were satisfied using hyper. And for the I/O, ROW or SIO, but you may try vr.
For memory management, you will have to try it yourself. Because 'good settings' may vary per user.
No, I wasn't sending this from my computer.
Click to expand...
Click to collapse
THX.
now im on Smartassv2 and VR.

Interactive – why is this the best governor? [INFO] - UPDATED 2/23

Many people have tried this governor out, but few have tested it in the 3 most important categories that should be considered when deciding which governor is the best for you:
=====================
UPDATED 2/23 - I have been getting a lot of PMs about what settings I specifically use for for the interactive governor and the deadline IO scheduler. See the end of this post for those settings.
=====================
Performance
Battery Life
CPU times
First, let’s talk about the MAIN reason this governor stands out above the default “ondemand” for probably most if not all Android devices….. TIME. Yes, time. The main difference between the two governors is that interactive operates more on timed values instead of actually calculating load and trying to compensate for the ever changing size and number of operations being asked of the CPU to execute. Always adjusting based upon load, determining that load, and compensating for it costs you two things – TIME (again this word is used, but in the dynamic of the ondemand governor, I reference it in a negative way – a cost or penalty) and latency. Ondemand uses up and down threshold values to figure out how to bring the CPU out of idle or back down to idle, etc. A predetermined “tick” of 50,000 ms to check what kind of load is being placed on the CPU. This is done going up AND going down.
Interactive uses timers to adjust. There is a “tick” much like ondemand, but it is significantly shorter and the way it responds is a bit more clever. Rather than try to play cat and mouse with your operation requests, it uses timers to more aggressively respond and handle a work queue. From android.googlesource.com:
Code:
“The CPUfreq governor "interactive" is designed for latency-sensitive,
interactive workloads. This governor sets the CPU speed depending on
usage, similar to "ondemand" and "conservative" governors. However,
the governor is more aggressive about scaling the CPU speed up in
response to CPU-intensive activity."
Now let’s look at the brains of the governor:
Code:
[U]min_sample_time:[/U] The minimum amount of time to spend at the current
frequency before ramping down. This is to ensure that the governor has
seen enough historic cpu load data to determine the appropriate
workload. Default is 80000 uS.
Code:
[U]hispeed_freq:[/U] An intermediate "hi speed" at which to initially ramp
when CPU load hits the value specified in go_hispeed_load. If load
stays high for the amount of time specified in above_hispeed_delay,
then speed may be bumped higher. Default is maximum speed.
Code:
[U]go_hispeed_load:[/U] The CPU load at which to ramp to the intermediate "hi
speed". Default is 85%.
Code:
[U]above_hispeed_delay:[/U] Once speed is set to hispeed_freq, wait for this
long before bumping speed higher in response to continued high load.
Default is 20000 uS.
Code:
[U]timer_rate:[/U] Sample rate for reevaluating cpu load when the system is
not idle. Default is 20000 uS.
And here we even have the option to use hispeed_freq as a touch module:
Code:
[U]input_boost:[/U] If non-zero, boost speed of all CPUs to hispeed_freq on
touchscreen activity. Default is 0.
What you can clearly see here is the distinction of making operations time sensitive instead of load sensitive. Rather brilliant. What this does is removes the “calculation” factor from the equation and allows the user to completely take control of the device in terms of (remember those 3) performance, battery life, CPU times! The last two are closely related and could be thought of as one.
Studying these values, and testing them individually myself, I have found that the trick is to set the hispeed_freq to approximately 70-75% of the CPU’s STOCK speed. So for a note 3, right around 1.72 GHz (if you do not use the touch boost module). And what we want to do is make this parameter extremely aggressive by inputting a value right around 60-65 for go_hispeed_load.
What this does is give you a very snappy response mechanism for medium intensive tasks without spinning the CPU up unnecessarily. Most things you do on a day to day basis will not require the processor to be ramped to max. Ondemand, however, shows behavior patterns in CPU times that are FAR more aggressive – the reason is the latency issue with ondemand (playing cat and mouse as I stated earlier) and not being as capable of keeping up with your ever changing dynamic work queues.
I would rather not write a novel, all of this just rolled off the keys just now because I was bored, but any questions about comparisons between the two governors, please feel free to post here and I will do my best to reply with something useful to you. For a reference, here are my personal settings for this governor:
My personal settings for interactive:
above_hispeed_delay: 15000
boost: 0
boostpulse_duration: 60000
go_hispeed_load: 70
hispeed_freq: 1728000
io_is_busy: 0
min_sampling_time: 60000
target_loads: 90
timer_rate: 15000
timer_slack: 60000
My personal settings for deadline:
add_random: 1
iostats: 1
nomerges: 0
rotational: 0
rq_affinity: 1
fifo_batch: 4
front_merges: 1
read_expire: 500
write_expire: 3000
writes_starved: 3

Thanks for shedding light in this cun7. Very helpful.
Sent from my SM-N900T using Tapatalk

Dropping dem knowledge bombs business coon

Allot of useful information there cun7. Thank you Good sir.

Great insight... Thank you Bbro
Sent from my SPH-L720 using Tapatalk

It would also be worth mentioning, that in my own personal testing, interactive spends less time overall in higher frequency steps, and the result in the UI is still the same - very fluid with no latency or stuttering. There is so much power wasted when using the ondemand governor. It just isn't as responsive or fine tuned when it comes to your interaction with the device.
Interactive performs when it needs to, and settles down when it doesn't. But more importantly it does this more accurately/appropriately than any other. Why it isn't the default setting on mobile platforms is beyond my understanding. ondemand is "tried and true", I get that, but it just isn't efficient. There are better ways to skin a cat.

Thanks For this! What's your insight regarding Schedulers and it's settings?
Sent from my SM-N900T using XDA Premium 4 mobile app

Vinsane said:
Thanks For this! What's your insight regarding Schedulers and it's settings?
Sent from my SM-N900T using XDA Premium 4 mobile app
Click to expand...
Click to collapse
On these devices, noop or deadline. Nothing else performs as optimally or logical for a device that does not having a "moving mechanism" disk for IO.
ROW seems to be one that I have seen popping into some kernel builds as of the last year or so. Why? I honestly don't know. This IO scheduler is terrible for a device that does read AND write operations regularly. Giving one a higher priority makes absolutely no sense. Performance suffers under heavy load where you have smaller read operations being given higher priority on the disk over a large write operations. As with anything, there needs to be balance, not just a one size fits only 1 when there are two more needing to be fitted, make sense?
Deadline in my opinion is the best overall because it makes an attempt to prioritize which operations get served first based upon their calculated "need", and services them accordingly - again here we see the time being the carefully calculated variable and not some other factor. deadline says "hey do this one over here, it is going to be the most taxing on CPU and is therefore more important to the user experience"...
noop is a solid one as well, and much simpler. It processes any and all tasks AS THEY COME IN. Meaning, as an operation is requested, so is it done. This scheduler also has a very unique attribute over deadline because noop can merge requests together and run them through the pipe at the same time. The only drawback to noop is in fact it's merging - performance can suffer when there is a lot going on because there is no priority given to this over that.
My experience has been that you cannot go wrong with either, but I personally prefer deadline and in some instances I have actually seen noop's weakness rear it's head through my interaction with the device, then switched to deadline and seen that scheduler handle that same set of tasks with less hiccups.
noop is also slighty (and by slightly I mean theoretically because I have never seen the difference in battery represented at the end of the day in my battery life) easier on the battery because of the merging function. It requires less CPU to process a merged task than it would two separate tasks. Theory of course...
I use deadline pretty religiously myself, and performance is what I am seeking with it. All the other hybrid frankenstein IO schedulers out there simply don't square up - sio, vr, bfq, cfq, fifo, lifo row... They all have some weird parameter that simply just lacks the logic to apply to flash memory applications, or android, etc.
Deadline is simple, straight forward, and extremely effective. That is all.

cun7 said:
On these devices, noop or deadline. Nothing else performs as optimally or logical for a device that does not having a "moving mechanism" disk for IO.
ROW seems to be one that I have seen popping into some kernel builds as of the last year or so. Why? I honestly don't know. This IO scheduler is terrible for a device that does read AND write operations regularly. Giving one a higher priority makes absolutely no sense. Performance suffers under heavy load where you have smaller read operations being given higher priority on the disk over a large write operations. As with anything, there needs to be balance, not just a one size fits only 1 when there are two more needing to be fitted, make sense?
Deadline in my opinion is the best overall because it makes an attempt to prioritize which operations get served first based upon their calculated "need", and services them accordingly - again here we see the time being the carefully calculated variable and not some other factor. deadline says "hey do this one over here, it is going to be the most taxing on CPU and is therefore more important to the user experience"...
noop is a solid one as well, and much simpler. It processes any and all tasks AS THEY COME IN. Meaning, as an operation is requested, so is it done. This scheduler also has a very unique attribute over deadline because noop can merge requests together and run them through the pipe at the same time. The only drawback to noop is in fact it's merging - performance can suffer when there is a lot going on because there is no priority given to this over that.
My experience has been that you cannot go wrong with either, but I personally prefer deadline and in some instances I have actually seen noop's weakness rear it's head through my interaction with the device, then switched to deadline and seen that scheduler handle that same set of tasks with less hiccups.
noop is also slighty (and by slightly I mean theoretically because I have never seen the difference in battery represented at the end of the day in my battery life) easier on the battery because of the merging function. It requires less CPU to process a merged task than it would two separate tasks. Theory of course...
I use deadline pretty religiously myself, and performance is what I am seeking with it. All the other hybrid frankenstein IO schedulers out there simply don't square up - sio, vr, bfq, cfq, fifo, lifo row... They all have some weird parameter that simply just lacks the logic to apply to flash memory applications, or android, etc.
Deadline is simple, straight forward, and extremely effective. That is all.
Click to expand...
Click to collapse
Great explanation. I am surprised you don't like sio though. Its basically noop when it comes to fcfs and request merging but adds deadlines for fairness helping cut down on those times where noop can be detrimental.

themichael said:
Great explanation. I am surprised you don't like sio though. Its basically noop when it comes to fcfs and request merging but adds deadlines for fairness helping cut down on those times where noop can be detrimental.
Click to expand...
Click to collapse
Actually, sio isn't bad. It is just kind of one of those frankenstein IO schedulers in my opinion. In this scheduler we have start service requests (a deadline function) but with no sorting of requests.... it's like noop with a timer, kind of a redundant scheduler because was is the point of setting a deadline on a task if the scheduler is still using a FCFS logic? You still can suffer on large operations because the scheduler has no ability to organize, it can only "rush from A to B" for lack of a better way to describe it. Analyze/organize/timer, execute, check timer, rinse and repeat... and none of those really have to be in that order for the deadline scheduler to be efficient!
sio is basically deadline without the ability to sort ques. Although I would put it equal to noop.
Also, deadline does have the ability to merge small sorted requests. It's just like... a 20 trick pony. That's why I use it pretty much exclusively.
When I was working on the Gingerbread project for the Nexus S, myself and 3 of my colleagues had a short discussion over some subway about which IO scheduler to set as default in the Nexus S kernel. Deadline made the most sense for Android at the time. It still does in my opinion, nothing has changed since then in terms of what else is available.
SIO is not bad, however. I would even say use it over noop, but you won't really see any real performance increase from it. The two are still =

cun7 said:
Actually, sio isn't bad. It is just kind of one of those frankenstein IO schedulers in my opinion. In this scheduler we have start service requests (a deadline function) but with no sorting of requests.... it's like noop with a timer, kind of a redundant scheduler because was is the point of setting a deadline on a task if the scheduler is still using a FCFS logic? You still can suffer on large operations because the scheduler has no ability to organize, it can only "rush from A to B" for lack of a better way to describe it. Analyze/organize/timer, execute, check timer, rinse and repeat... and none of those really have to be in that order for the deadline scheduler to be efficient!
sio is basically deadline without the ability to sort ques. Although I would put it equal to noop.
Also, deadline does have the ability to merge small sorted requests. It's just like... a 20 trick pony. That's why I use it pretty much exclusively.
When I was working on the Gingerbread project for the Nexus S, myself and 3 of my colleagues had a short discussion over some subway about which IO scheduler to set as default in the Nexus S kernel. Deadline made the most sense for Android at the time. It still does in my opinion, nothing has changed since then in terms of what else is available.
SIO is not bad, however. I would even say use it over noop, but you won't really see any real performance increase from it. The two are still =
Click to expand...
Click to collapse
Great, very convincing. My last question would be, what kind of overhead is required to sort the requests as deadline does. Is it still more desirable than the simplicity of FCFS.

themichael said:
Great, very convincing. My last question would be, what kind of overhead is required to sort the requests as deadline does. Is it still more desirable than the simplicity of FCFS.
Click to expand...
Click to collapse
The "sorting" is very minimal overhead. Basically deadline ques are sorted by their expiration time (their deadline) and their sector number. I'll try to explain this without making it sound too confusing...
Before a operation request is served it decides which queue needs attention first. Read requests by default actually have more priority but not ALL (this why ROW is weak) and are given a deadline of 500 ms versus 5 seconds for a write request.
What happens is the deadline scheduler checks if the FIRST request in the deadline queue has expired, if it has not, then it simply processes the sorted "sector batch".
Does that make sense? Basically what happens is each request is given a pre-defined deadline, and it simply checks to see if they are being processed in the time specified in the tunables write_expire and read_expire.
Too tell you what time it is without explaining how to build a clock, I'll just answer your question: Very little overhead is needed to operate this scheduler.

cun7 said:
The "sorting" is very minimal overhead. Basically deadline ques are sorted by their expiration time (their deadline) and their sector number. I'll try to explain this without making it sound too confusing...
Before a operation request is served it decides which queue needs attention first. Read requests by default actually have more priority but not ALL (this why ROW is weak) and are given a deadline of 500 ms versus 5 seconds for a write request.
What happens is the deadline scheduler checks if the FIRST request in the deadline queue has expired, if it has not, then it simply processes the sorted "sector batch".
Does that make sense? Basically what happens is each request is given a pre-defined deadline, and it simply checks to see if they are being processed in the time specified in the tunables write_expire and read_expire.
Too tell you what time it is without explaining how to build a clock, I'll just answer your question: Very little overhead is needed to operate this scheduler.
Click to expand...
Click to collapse
Great. Love it. I'll give this a try. I have always liked the philosophy behind deadline anyway.

Laying down some serious knowledge. . All this is so eloquently said.. Thank you
Sent from my SPH-L720 using Tapatalk

cun7 said:
The "sorting" is very minimal overhead. Basically deadline ques are sorted by their expiration time (their deadline) and their sector number. I'll try to explain this without making it sound too confusing...
Before a operation request is served it decides which queue needs attention first. Read requests by default actually have more priority but not ALL (this why ROW is weak) and are given a deadline of 500 ms versus 5 seconds for a write request.
What happens is the deadline scheduler checks if the FIRST request in the deadline queue has expired, if it has not, then it simply processes the sorted "sector batch".
Does that make sense? Basically what happens is each request is given a pre-defined deadline, and it simply checks to see if they are being processed in the time specified in the tunables write_expire and read_expire.
Too tell you what time it is without explaining how to build a clock, I'll just answer your question: Very little overhead is needed to operate this scheduler.
Click to expand...
Click to collapse
Dude awesome write up. Just learned a lot with this knowledge. 1 question what are your thoughts on Zen IO Scheduler
Sent from my SM-N900T using Tapatalk

Great observations.
Question:
What Rom/kernel combo do you have, currently?

flak0 - I don't know enough about "zen" to give you an opinion on it. Maybe find some technical info and post it here?
moSess - I am using Tweaked 2.0 with Beast Mode 2.35 Kernel
Sent from another galaxy

OP, what do you think about the multicore power saving option & MP-Descision? The multicore power saving option in the beast mode Kernel tries to group tasks on the least amount of cores to save battery. What I'm wondering is if it's actually worth it, because I'm not sure, but I think if tasks are being limited to 1 core than the cpu spends more time completing the task than if I left it off so isn't that worse for my battery life? & I've never really understood the whole MP-Descision thing, in the past I'd just disable it if the kernel had intelli-plug but should I leave it on if there's no intelli-plug option? I hope you clear some of this up for me, thanks!

@steezmyster
The multi core power saving option is useful, and yes it does save power overall despite the fact that you are loading 1 or 2 cores a little more. This is all the more reason to use the snappy interactive governor rather than ondemand. High CPU load is handled quicker by jumping to a mid or high frequency.
In my opinion the mpdecision deamon is useless. You will get better performance and more accurate load handling by simply allowing the CPU drivers to do their job. More responsive and less "spiking".
I have not been using mpdecision since I got my Note 3. I get great battery life and performance.
Keep it simple. Don't buy into all the buzz word hype mods that many throw around. They typically are more detrimental to performance than beneficial.
I'll add to this post later when I get back. I'm on the road now and talking to type out this reply.
Sent from another galaxy

Thanks for the reply, it was very insightful!