cfq-iosced: Implement IOPS mode and group_idle tunable V3
in [Kernel]
|
Prev: fix warning: us_to_pm_timer_ticks defined but not used
Next: [PATCH wq#for-next] fscache: fix build on !CONFIG_SYSCTL
From: Corrado Zoccolo on 24 Jul 2010 05:10 On Sat, Jul 24, 2010 at 10:51 AM, Christoph Hellwig <hch(a)infradead.org> wrote: > To me this sounds like slice_idle=0 is the right default then, as it > gives useful behaviour for all systems linux runs on. No, it will give bad performance on single disks, possibly worse than deadline (deadline at least sorts the requests between different queues, while CFQ with slice_idle=0 doesn't even do this for readers). Setting slice_idle to 0 should be considered only when a single sequential reader cannot saturate the disk bandwidth, and this happens only on smart enough hardware with large number of spindles. > Setups with > more than a few spindles are for sure more common than setups making > use of cgroups. Especially given that cgroups are more of a high end > feature you'd rarely use on a single SATA spindle anyway. So setting > a paramter to make this useful sounds like the much better option. > > Especially given that the block cgroup code doesn't work particularly > well in presence of barriers, which are on for any kind of real life > production setup anyway. > > -- __________________________________________________________________________ dott. Corrado Zoccolo mailto:czoccolo(a)gmail.com PhD - Department of Computer Science - University of Pisa, Italy -------------------------------------------------------------------------- The self-confidence of a warrior is not the self-confidence of the average man. The average man seeks certainty in the eyes of the onlooker and calls that self-confidence. The warrior seeks impeccability in his own eyes and calls that humbleness. Tales of Power - C. Castaneda -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Corrado Zoccolo on 29 Jul 2010 16:00
On Mon, Jul 26, 2010 at 4:33 PM, Vivek Goyal <vgoyal(a)redhat.com> wrote: > On Sat, Jul 24, 2010 at 11:07:07AM +0200, Corrado Zoccolo wrote: >> On Sat, Jul 24, 2010 at 10:51 AM, Christoph Hellwig <hch(a)infradead.org> wrote: >> > To me this sounds like slice_idle=0 is the right default then, as it >> > gives useful behaviour for all systems linux runs on. >> No, it will give bad performance on single disks, possibly worse than >> deadline (deadline at least sorts the requests between different >> queues, while CFQ with slice_idle=0 doesn't even do this for readers). > > Not sure if CFQ will be worse than deadline with slice_idle=0. CFQ has > some inbuilt things which should help. > > - Readers preempt Writers > - All writers go in one single queue (at one prio level), readers get > their individual queues and can outnumber writers. > > So I guess CFQ with slice_idle=0 should not be worse than deadline in terms > of read latencies. I was thinking more to the fact that read requests are not sorted: they will basically be serviced in FIFO order, while deadline will sort them and possibly increase locality. In the reader vs writer case, cfq may have a small edge. Basically, they will severely underperform vs. cfq with slice != 0, though. > > Vivek > -- __________________________________________________________________________ dott. Corrado Zoccolo mailto:czoccolo(a)gmail.com PhD - Department of Computer Science - University of Pisa, Italy -------------------------------------------------------------------------- The self-confidence of a warrior is not the self-confidence of the average man. The average man seeks certainty in the eyes of the onlooker and calls that self-confidence. The warrior seeks impeccability in his own eyes and calls that humbleness. Tales of Power - C. Castaneda -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |