IO scheduler based IO controller V10
in [Kernel]
|
Prev: kernel : USB sound problem
Next: [PATCH 1/2] jsm: IRQ handlers doesn't need to have IRQ_DISABLED enabled
From: Jens Axboe on 3 Oct 2009 03:30 On Sat, Oct 03 2009, Ingo Molnar wrote: > > * Mike Galbraith <efault(a)gmx.de> wrote: > > > unsigned int cfq_desktop; > > + unsigned int cfq_desktop_dispatch; > > > - if (cfq_cfqq_idle_window(cfqq) && cfqd->rq_in_driver[BLK_RW_ASYNC]) > > + if (cfq_cfqq_idle_window(cfqq) && cfqd->rq_in_driver[BLK_RW_ASYNC]) { > > + cfqd->desktop_dispatch_ts = jiffies; > > return 0; > > + } > > btw., i hope all those desktop_ things will be named latency_ pretty > soon as the consensus seems to be - the word 'desktop' feels so wrong in > this context. > > 'desktop' is a form of use of computers and the implication of good > latencies goes far beyond that category of systems. I will rename it, for now it doesn't matter (lets not get bogged down in bike shed colors, please). Oh and Mike, I forgot to mention this in the previous email - no more tunables, please. We'll keep this under a single knob. -- Jens Axboe -- 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: Mike Galbraith on 3 Oct 2009 05:00 On Sat, 2009-10-03 at 09:25 +0200, Jens Axboe wrote: > On Sat, Oct 03 2009, Ingo Molnar wrote: > Oh and Mike, I forgot to mention this in the previous email - no more > tunables, please. We'll keep this under a single knob. OK. Since I don't seem to be competent to operate quilt this morning anyway, I won't send a fixed version yet. Anyone who wants to test can easily fix the rename booboo. With the knob in place, it's easier to see what load is affected by what change. Back to rummage/test. -Mike -- 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: Mike Galbraith on 3 Oct 2009 05:10 On Sat, 2009-10-03 at 09:24 +0200, Jens Axboe wrote: > After shutting down the computer yesterday, I was thinking a bit about > this issue and how to solve it without incurring too much delay. If we > add a stricter control of the depth, that may help. So instead of > allowing up to max_quantum (or larger) depths, only allow gradual build > up of that the farther we get away from a dispatch from the sync IO > queues. For example, when switching to an async or seeky sync queue, > initially allow just 1 in flight. For the next round, if there still > hasn't been sync activity, allow 2, then 4, etc. If we see sync IO queue > again, immediately drop to 1. > > It could tie in with (or partly replace) the overload feature. The key > to good latency and decent throughput is knowing when to allow queue > build up and when not to. Hm. Starting at 1 sounds a bit thin (like IDLE), multiple iterations to build/unleash any sizable IO, but that's just my gut talking. -Mike -- 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 3 Oct 2009 05:10 Hi Jens, On Sat, Oct 3, 2009 at 9:25 AM, Jens Axboe <jens.axboe(a)oracle.com> wrote: > On Sat, Oct 03 2009, Ingo Molnar wrote: >> >> * Mike Galbraith <efault(a)gmx.de> wrote: >> >> > unsigned int cfq_desktop; >> > + unsigned int cfq_desktop_dispatch; >> >> > - if (cfq_cfqq_idle_window(cfqq) && cfqd->rq_in_driver[BLK_RW_ASYNC]) >> > + if (cfq_cfqq_idle_window(cfqq) && cfqd->rq_in_driver[BLK_RW_ASYNC]) { >> > + cfqd->desktop_dispatch_ts = jiffies; >> > return 0; >> > + } >> >> btw., i hope all those desktop_ things will be named latency_ pretty >> soon as the consensus seems to be - the word 'desktop' feels so wrong in >> this context. >> >> 'desktop' is a form of use of computers and the implication of good >> latencies goes far beyond that category of systems. > > I will rename it, for now it doesn't matter (lets not get bogged down in > bike shed colors, please). > > Oh and Mike, I forgot to mention this in the previous email - no more > tunables, please. We'll keep this under a single knob. Did you have a look at my http://patchwork.kernel.org/patch/47750/ ? It already introduces a 'target_latency' tunable, expressed in ms. If we can quantify the benefits of each technique, we could enable them based on the target latency requested by that single tunable. Corrado > > -- > Jens Axboe > > -- > 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/ > -- __________________________________________________________________________ dott. Corrado Zoccolo mailto:czoccolo(a)gmail.com PhD - Department of Computer Science - University of Pisa, Italy -------------------------------------------------------------------------- -- 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 3 Oct 2009 05:20
Hi, On Sat, Oct 3, 2009 at 11:00 AM, Mike Galbraith <efault(a)gmx.de> wrote: > On Sat, 2009-10-03 at 09:24 +0200, Jens Axboe wrote: > >> After shutting down the computer yesterday, I was thinking a bit about >> this issue and how to solve it without incurring too much delay. If we >> add a stricter control of the depth, that may help. So instead of >> allowing up to max_quantum (or larger) depths, only allow gradual build >> up of that the farther we get away from a dispatch from the sync IO >> queues. For example, when switching to an async or seeky sync queue, >> initially allow just 1 in flight. For the next round, if there still >> hasn't been sync activity, allow 2, then 4, etc. If we see sync IO queue >> again, immediately drop to 1. >> I would limit just async I/O. Seeky sync queues are automatically throttled by being sync, and have already high latency, so we shouldn't increase it artificially. I think, instead, that we should send multiple seeky requests (possibly coming from different queues) at once. They will help especially with raid devices, where the seeks for requests going to different disks will happen in parallel. >> It could tie in with (or partly replace) the overload feature. The key >> to good latency and decent throughput is knowing when to allow queue >> build up and when not to. > > Hm. Starting at 1 sounds a bit thin (like IDLE), multiple iterations to > build/unleash any sizable IO, but that's just my gut talking. > On the other hand, sending 1 write first and then waiting it to complete before submitting new ones, will help performing more merges, so the subsequent requests will be bigger and thus more efficient. Corrado > -Mike > > -- > 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/ > -- __________________________________________________________________________ dott. Corrado Zoccolo mailto:czoccolo(a)gmail.com PhD - Department of Computer Science - University of Pisa, Italy -------------------------------------------------------------------------- -- 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/ |