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 2 Oct 2009 14:30 On Fri, Oct 02 2009, Mike Galbraith wrote: > On Fri, 2009-10-02 at 20:04 +0200, Jens Axboe wrote: > > > I'm not too crazy about it either. How about just using 'desktop' since > > this is obviously what we are really targetting? 'latency' isn't fully > > descriptive either, since it may not necessarily provide the best single > > IO latency (noop would). > > Grin. "Perfect is the enemy of good" :) > Avg > 16.24 175.82 154.38 228.97 147.16 144.5 noop > 43.23 57.39 96.13 148.25 180.09 105.0 deadline Yep, that's where it falls down. Noop basically fails here because it treats all IO as equal, which obviously isn't true for most people. But even for pure read workloads (is the above the mixed read/write, or just read?), latency would be excellent with noop but the desktop experience would not. -- 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 2 Oct 2009 14:30 On Fri, 2009-10-02 at 20:04 +0200, Jens Axboe wrote: > I'm not too crazy about it either. How about just using 'desktop' since > this is obviously what we are really targetting? 'latency' isn't fully > descriptive either, since it may not necessarily provide the best single > IO latency (noop would). Grin. "Perfect is the enemy of good" :) Avg 16.24 175.82 154.38 228.97 147.16 144.5 noop 43.23 57.39 96.13 148.25 180.09 105.0 deadline -- 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: Jens Axboe on 2 Oct 2009 14:40 On Fri, Oct 02 2009, Mike Galbraith wrote: > On Fri, 2009-10-02 at 20:08 +0200, Jens Axboe wrote: > > On Thu, Oct 01 2009, Mike Galbraith wrote: > > > max_dispatch = cfqd->cfq_quantum; > > > if (cfq_class_idle(cfqq)) > > > max_dispatch = 1; > > > > > > + if (cfqd->busy_queues > 1) > > > + cfqd->od_stamp = jiffies; > > > + > > > > ->busy_queues > 1 just means that they have requests ready for dispatch, > > not that they are dispatched. > > But we're not alone, somebody else is using disk. I'm trying to make > sure we don't have someone _about_ to come back.. like a reader, so when > there's another player, stamp to give him some time to wake up/submit > before putting the pedal to the metal. OK, then the check does what you want. It'll tell you that you have a pending request, and at least one other queue has one too. And that could dispatch right after you finish yours, depending on idling etc. Note that this _only_ applies to queues that have requests still sitting in CFQ, as soon as they are on the dispatch list in the block layer they will only be counted as busy if they still have sorted IO waiting. But that should be OK already, since I switched CFQ to dispatch single requests a few revisions ago. So we should not run into that anymore. -- 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 2 Oct 2009 14:40 On Fri, 2009-10-02 at 20:08 +0200, Jens Axboe wrote: > On Thu, Oct 01 2009, Mike Galbraith wrote: > > max_dispatch = cfqd->cfq_quantum; > > if (cfq_class_idle(cfqq)) > > max_dispatch = 1; > > > > + if (cfqd->busy_queues > 1) > > + cfqd->od_stamp = jiffies; > > + > > ->busy_queues > 1 just means that they have requests ready for dispatch, > not that they are dispatched. But we're not alone, somebody else is using disk. I'm trying to make sure we don't have someone _about_ to come back.. like a reader, so when there's another player, stamp to give him some time to wake up/submit before putting the pedal to the metal. -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: Theodore Tso on 2 Oct 2009 14:40
On Fri, Oct 02, 2009 at 08:04:37PM +0200, Jens Axboe wrote: > > i'd say 'latency' describes it even better. 'interactivity' as a term is > > a bit overladen. > > I'm not too crazy about it either. How about just using 'desktop' since > this is obviously what we are really targetting? 'latency' isn't fully > descriptive either, since it may not necessarily provide the best single > IO latency (noop would). As Linus has already pointed out, it's not necessarily "desktop" versus "server". There will be certain high frequency transaction database workloads (for example) that will very much care about latency. I think "low_latency" may be the best term to use. - Ted -- 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/ |