On Monday 2012-08-06 18:35, Jeff Moyer wrote: >Tatyana Brokhman writes: > >> This patch adds the implementation of a new scheduling algorithm - ROW. >> The policy of this algorithm is to prioritize READ requests over WRITE >> as much as possible without starving the WRITE requests. > >Perhaps you could start off by describing the workload, and describing >why the existing I/O schedulers do not perform well.
My setup is a 1 GB RAM Atom N450 netbook, combined with the use of dm-crypt for the 5400 rpm disk, which limits the effective write throughput to somewhere around 20–26 MB/s. Now try this: ddrescue /dev/zero ~/bluntfile (or) (remote)# >nullfile (remote)# truncate -s 10G nullfile (local)# rsync -HPavz remote:nullfile . The transfer rates of ddrescue/rsync first show 50–60 MB/s. Wait until writeout is forced - which is after ~700–800 MB in my case when all buffers are full. The transfer rates then drop to the aforementioned 20–26 MB/s. In the so-loaded system, try to start an xterm (preferably by the use of a shortcut, or starting one from another xterm). The wait time for the shell prompt to appear is then the measure for interactivity, with lower being better. I have casually observed that ROW has 1/4th of the wait time in this heavy disk write scenario (around 5 s) for the shell to start up than with CFQ (20–21 s). "Casual" meaning I had a clock with 1.0 s granularity beside me and ran this for like 3 times for each scheduler, averaging it out. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
