Amazon Fire TV Stick vs Chromecast – XDA TV

There is no doubt that Amazon is a huge player in many markets, and they want to be a huge … more

Fight the Heat and Conserve Battery with EaseUS Coolphone

Memory hungry Android applications are often responsible for making our device … more

Battery Charged in 30 Seconds? Maybe in 2016

Phones and tablets are getting more and more power hungry with each passing generation. Their … more

ZArchive Manages Your File Archives

Today smartphones are quite powerful devices that can handle multiple processes at once. In fact, some of … more

Welcome to XDA

Search to go directly to your device's forum

Register an account

Unlock full posting privileges

Ask a question

No registration required
Post Reply

[SHARE] CPU Governors and I/O Schedulers Explained 12/23

OP jee'sgalaxy

22nd October 2012, 06:51 PM   |  #1  
OP Senior Member
Boston
Thanks Meter: 223
 
236 posts
Join Date:Joined: Sep 2012
More
Hey guys. Thanks to stealthware, -Grift- , and stempox for these information. However, I geared it so that it applies more to the SkyRocket users.

Thanks Appreciated!

CPU Governors Explained:
THE USUAL GOVERNORS
1- OnDemand
2- Interactive
3- Performance
4- Powersave
5- Conservative
6- Userspace

THE OTHER AWESOME GOVERNORS
1- OnDemandX
2- InteractiveX
3- Badass
4- Lagfree
5- Scary
6- Lazy
7- Lionheart
8- SmartassV2
9- Wheatley
10- Intellidemand
11- Lulzactive

I/O Scheduler explained in bottom part of post-

THE USUAL GOVERNORS

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 bitch 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: 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.

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.

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.


NOW THE OTHER AWESOME GOVERNORS

1: 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.

2: InteractiveX:

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.

3: Badass
Badass removes all of this "fast peaking" to the max frequency. On a typical system the cpu won't go above 1080Mhz and therefore use less power. To trigger a frequency increase, the system must run a bit @ 1080MHz with high load, then the frequency is bumped to 1350MHz. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 2-5 seconds, depending on the load your system is experiencing).

You can tweak the Phase 2 (1080MHz) and Phase 3 (1350MHz) via sysfs (if you don't know, then just leave it alone)

4: 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.

5: 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.

6: 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.

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

8: 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.

9: Wheatley:

in short words this govenor is build on “ondemand” but increases the C4 (the sleep state) state time of the CPU and doing so trying to save juice. So the results show that Wheatley works as intended and ensures that the C4 state is used whenever the task allows a proper efficient usage of the C4 state. For more demanding tasks which cause a large number of wakeups and prevent the efficient usage of the C4 state, the governor resorts to the next best power saving mechanism and scales down the frequency. So with the new highly-flexible Wheatley governor one can have the best of both worlds. Obviously, this governor is only available on multi-core devices.

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


I/O Schedulers Explained

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.


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.
Last edited by jee'sgalaxy; 23rd December 2012 at 04:13 PM.
The Following 49 Users Say Thank You to jee'sgalaxy For This Useful Post: [ View ]
23rd October 2012, 10:38 PM   |  #2  
ArcticFish's Avatar
Senior Member
Flag Orlando
Thanks Meter: 234
 
943 posts
Join Date:Joined: Jun 2012
More
Beats finding it in the other forum lol

Sent from my Paranoid SGH-T989
1st November 2012, 02:54 AM   |  #3  
Senior Member
Thanks Meter: 86
 
683 posts
Join Date:Joined: Jul 2012
More
Kernel updated with badass. Can that be added? Is it battery oriented? I know it's a popular choice and I've used it but never knew why

Sent from my SGH-I727 using Tapatalk 2
4th November 2012, 02:56 AM   |  #4  
Member
Thanks Meter: 26
 
55 posts
Join Date:Joined: Oct 2007
Quote:
Originally Posted by kchen96

Kernel updated with badass. Can that be added? Is it battery oriented? I know it's a popular choice and I've used it but never knew why

Sent from my SGH-I727 using Tapatalk 2

This is copied straight from InstigatorX's post.

Badass removes all of this "fast peaking" to the max frequency. On a typical system the cpu won't go above 1080Mhz and therefore use less power. To trigger a frequency increase, the system must run a bit @ 1080MHz with high load, then the frequency is bumped to 1350MHz. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 2-5 seconds, depending on the load your system is experiencing).
20th November 2012, 06:04 AM   |  #5  
crashpsycho's Avatar
Senior Member
Flag PHOENIX AZ
Thanks Meter: 319
 
1,219 posts
Join Date:Joined: Jun 2011
Donate to Me
More
Quote:
Originally Posted by jee'sgalaxy

Hey guys. Thanks to stealthware, -Grift- , and stempox for these information. However, I geared it so that it applies more to the SkyRocket users who has an AWESOME NEW KERNEL from DAGr8. I'm only relaying the information that applies to this kernel.

CPU Governors Explained:

THE USUAL GOVERNORS

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 bitch 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: 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).

3: Powersave Governor:

The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.

4: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.

5: 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: 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.


NOW THE OTHER AWESOME GOVERNORS

1: Badass
Badass removes all of this "fast peaking" to the max frequency. On a typical system the cpu won't go above 1080Mhz and therefore use less power. To trigger a frequency increase, the system must run a bit @ 1080MHz with high load, then the frequency is bumped to 1350MHz. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 2-5 seconds, depending on the load your system is experiencing).

You can tweak the Phase 2 (1080MHz) and Phase 3 (1350MHz) via sysfs (if you don't know, then just leave it alone)

2: InteractiveX:

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.


3: 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.

4: 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.

5: 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.

6: 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.

7: Wheatley:

in short words this govenor is build on “ondemand” but increases the C4 state time of the CPU and doing so trying to save juice. So the results show that Wheatley works as intended and ensures that the C4 state is used whenever the task allows a proper efficient usage of the C4 state. For more demanding tasks which cause a large number of wakeups and prevent the efficient usage of the C4 state, the governor resorts to the next best power saving mechanism and scales down the frequency. So with the new highly-flexible Wheatley governor one can have the best of both worlds. Obviously, this governor is only available on multi-core devices.

8: 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.

9: 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.

I/O Schedulers Explained

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.


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.

Thank alot for this info it really helped with my overheating,
The Following User Says Thank You to crashpsycho For This Useful Post: [ View ]
20th November 2012, 05:55 PM   |  #6  
OP Senior Member
Boston
Thanks Meter: 223
 
236 posts
Join Date:Joined: Sep 2012
More
Quote:
Originally Posted by crashpsycho

Thank alot for this info it really helped with my overheating,

Glad to have helped man!
21st December 2012, 04:09 AM   |  #7  
bps119's Avatar
Senior Member
Flag Louisville
Thanks Meter: 2,287
 
2,543 posts
Join Date:Joined: Jul 2009
More
Found some extra info you might want to add to the op here... http://forum.xda-developers.com/show....php?t=1767797

Sent from my SAMSUNG-SGH-I727 using Tapatalk 2
23rd December 2012, 04:13 PM   |  #8  
OP Senior Member
Boston
Thanks Meter: 223
 
236 posts
Join Date:Joined: Sep 2012
More
Quote:
Originally Posted by bps119

Found some extra info you might want to add to the op here... http://forum.xda-developers.com/show....php?t=1767797

Sent from my SAMSUNG-SGH-I727 using Tapatalk 2

Thanks. Updated OP
27th March 2013, 07:04 PM   |  #9  
Bleedos's Avatar
Senior Member
Flag Montreal
Thanks Meter: 129
 
339 posts
Join Date:Joined: Mar 2013
More
What about 'row' scheduler?
First post ever!

What bout the row I/O scheduler? I saw it on every CM10.1 based ROM I tried.

Thank you.
18th July 2013, 03:38 AM   |  #10  
Junior Member
Thanks Meter: 6
 
10 posts
Join Date:Joined: Apr 2010
More
Quote:
Originally Posted by Bleedos

First post ever!

What bout the row I/O scheduler? I saw it on every CM10.1 based ROM I tried.

Thank you.

Bit more information on different schedulers, including ROW:

http://forum.xda-developers.com/show...php?p=23885668

The Following 2 Users Say Thank You to silverrose For This Useful Post: [ View ]
Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes