[Sprint Samsung Galaxy S III] mw86:
Hey buddy good to see you here. Maybe there can be a thread made on xda for you bro?

GS3 L710 4.2.1 AOSP Kt747 2.1Ghz ROW/Ktoonservative *Tapatalk

---------- Post added at 07:05 PM ---------- Previous post was at 07:04 PM ----------

Hey guys inposted this in yhread called ktweaker discussion last month. Ill paste its contents here :)

I was finding Zen good but isn't free of issue as the onky one i found was it can get stuttery on long term i/o transfers like prioritizing foreground process is causing slow down when backround important tasks are not finishing fast enough to support the foreground task enough under a fully utilized i/o state. Under less utilization like everday light use it likely will save juice due to it being of the Simple Scheduler family known to be good for solid state storage like our phones storage.

Using ROW which i need to find info on i clearly see the best read and write rates i have and repeatable consistent results. It may have to do with an algorithm much like ram is accessed in a matrix. Atleast thats what the tunables for ROW remind me of.

Edit: i found this info after search. ROW is similar to Zen that read is prioritized over write but Zen uses foreground and backround to decifer priority where ROW attempts to take on any read requedt made but filter in writes before they cause too much latency. All i/o have their uses and none are superior to all others especially since everyone is looking for a different feel or use of changing from default i/o.

http://permalink.gmane.org/gmane.linux.ports.arm.msm/2911

*the following is the info posted at the link.

ROW scheduling algorithm will be used in mobile devices as default

block layer IO scheduling algorithm. 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 lmdd read and write.

The tests were performed on:

kernel version: 3.4

Underline device driver: mmc

Host controller: msm-sdcc

Card:standard emmc NAND flash

--------------------------------------------------------------------------

Algorithm | Throughput [mb/sec] | Worst case Latency [msec] |

| READ | WRITE | READ | WRITE |

--------------------------------------------------------------------------

Algorithm

Noop |

Read Mb/sec

12.12 |

Write mb/sec

25.18 |

Read Latency

4407

Write Latency

4804 |

Deadline | 12.02 | 24.6 | 705 | 5130 |

CFQ | 20.81 | 15.23 | 230 | 9370 |

ROW | 27.75 | 15.34 | 85 | 12025 |

-------------------------------------------------------------------------

GS3 L710 4.2.1 AOSP Kt747 2.1Ghz ROW/Ktoonservative *Tapatalk