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 13:20 On Fri, Oct 02 2009, Ray Lee wrote: > On Fri, Oct 2, 2009 at 7:56 AM, Jens Axboe <jens.axboe(a)oracle.com> wrote: > > In some cases I wish we had a server vs desktop switch, since it would > > decisions on this easier. I know you say that servers care about > > latency, but not at all to the extent that desktops do. Most desktop > > users would gladly give away the top of the performance for latency, > > that's not true of most server users. Depends on what the server does, > > of course. > > If most of the I/O on a system exhibits seeky tendencies, couldn't the > schedulers notice that and use that as the hint for what to optimize? > > I mean, there's no switch better than the actual I/O behavior itself. Heuristics like that have a tendency to fail. What's the cut-off point? Additionally, heuristics based on past process/system behaviour also has a tendency to be suboptimal, since things aren't static. We already look at seekiness of individual processes or groups. IIRC, as-iosched also keeps a per-queue tracking. -- 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: Jens Axboe on 2 Oct 2009 13:20 On Fri, Oct 02 2009, Linus Torvalds wrote: > > > On Fri, 2 Oct 2009, Jens Axboe wrote: > > > > Mostly they care about throughput, and when they come running because > > some their favorite app/benchmark/etc is now 2% slower, I get to hear > > about it all the time. So yes, latency is not ignored, but mostly they > > yack about throughput. > > The reason they yack about it is that they can measure it. > > Give them the benchmark where it goes the other way, and tell them why > they see a 2% deprovement. Give them some button they can tweak, because > they will. To some extent that's true, and I didn't want to generalize. If they are adament that the benchmark models their real life, then no amount of pointing in the other direction will change that. Your point about tuning is definitely true, these people are used to tuning things. For the desktop we care a lot more about working out of the box. > But make the default be low-latency. Because everybody cares about low > latency, and the people who do so are _not_ the people who you give > buttons to tweak things with. Totally agree. > > I agree, we can easily make CFQ be very about about latency. If you > > think that is fine, then lets just do that. Then we'll get to fix the > > server side up when the next RHEL/SLES/whatever cycle is honing in on a > > kernel, hopefully we wont have to start over when that happens. > > I really think we should do latency first, and throughput second. > > It's _easy_ to get throughput. The people who care just about throughput > can always just disable all the work we do for latency. If they really > care about just throughput, they won't want fairness either - none of that > complex stuff. It's not _that_ easy, it depends a lot on the access patterns. A good example of that is actually the idling that we already do. Say you have two applications, each starting up. If you start them both at the same time and just care for the dumb low latency, then you'll do one IO from each of them in turn. Latency will be good, but throughput will be aweful. And this means that in 20s they are both started, while with the slice idling and priority disk access that CFQ does, you'd hopefully have both up and running in 2s. So latency is good, definitely, but sometimes you have to worry about the bigger picture too. Latency is more than single IOs, it's often for complete operation which may involve lots of IOs. Single IO latency is a benchmark thing, it's not a real life issue. And that's where it becomes complex and not so black and white. Mike's test is a really good example of that. -- 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: Jens Axboe on 2 Oct 2009 13:30 On Fri, Oct 02 2009, Ingo Molnar wrote: > > * Jens Axboe <jens.axboe(a)oracle.com> wrote: > > > It's not _that_ easy, it depends a lot on the access patterns. A good > > example of that is actually the idling that we already do. Say you > > have two applications, each starting up. If you start them both at the > > same time and just care for the dumb low latency, then you'll do one > > IO from each of them in turn. Latency will be good, but throughput > > will be aweful. And this means that in 20s they are both started, > > while with the slice idling and priority disk access that CFQ does, > > you'd hopefully have both up and running in 2s. > > > > So latency is good, definitely, but sometimes you have to worry about > > the bigger picture too. Latency is more than single IOs, it's often > > for complete operation which may involve lots of IOs. Single IO > > latency is a benchmark thing, it's not a real life issue. And that's > > where it becomes complex and not so black and white. Mike's test is a > > really good example of that. > > To the extent of you arguing that Mike's test is artificial (i'm not > sure you are arguing that) - Mike certainly did not do an artificial > test - he tested 'konsole' cache-cold startup latency, such as: [snip] I was saying the exact opposite, that Mike's test is a good example of a valid test. It's not measuring single IO latencies, it's doing a sequence of valid events and looking at the latency for those. It's benchmarking the bigger picture, not a microbenchmark. -- 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: Ingo Molnar on 2 Oct 2009 13:30 * Jens Axboe <jens.axboe(a)oracle.com> wrote: > It's not _that_ easy, it depends a lot on the access patterns. A good > example of that is actually the idling that we already do. Say you > have two applications, each starting up. If you start them both at the > same time and just care for the dumb low latency, then you'll do one > IO from each of them in turn. Latency will be good, but throughput > will be aweful. And this means that in 20s they are both started, > while with the slice idling and priority disk access that CFQ does, > you'd hopefully have both up and running in 2s. > > So latency is good, definitely, but sometimes you have to worry about > the bigger picture too. Latency is more than single IOs, it's often > for complete operation which may involve lots of IOs. Single IO > latency is a benchmark thing, it's not a real life issue. And that's > where it becomes complex and not so black and white. Mike's test is a > really good example of that. To the extent of you arguing that Mike's test is artificial (i'm not sure you are arguing that) - Mike certainly did not do an artificial test - he tested 'konsole' cache-cold startup latency, such as: sh -c "perf stat -- konsole -e exit" 2>&1|tee -a $LOGFILE against a streaming dd. That is a _very_ relevant benchmark IMHO and konsole's cache footprint is far from trivial. (In fact i'd argue it's one of the most important IO benchmarks on a desktop system - how does your desktop hold up to something doing streaming IO.) Ingo -- 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: Ingo Molnar on 2 Oct 2009 13:30
* Jens Axboe <jens.axboe(a)oracle.com> wrote: > On Fri, Oct 02 2009, Ingo Molnar wrote: > > > > * Jens Axboe <jens.axboe(a)oracle.com> wrote: > > > > > It's not _that_ easy, it depends a lot on the access patterns. A > > > good example of that is actually the idling that we already do. > > > Say you have two applications, each starting up. If you start them > > > both at the same time and just care for the dumb low latency, then > > > you'll do one IO from each of them in turn. Latency will be good, > > > but throughput will be aweful. And this means that in 20s they are > > > both started, while with the slice idling and priority disk access > > > that CFQ does, you'd hopefully have both up and running in 2s. > > > > > > So latency is good, definitely, but sometimes you have to worry > > > about the bigger picture too. Latency is more than single IOs, > > > it's often for complete operation which may involve lots of IOs. > > > Single IO latency is a benchmark thing, it's not a real life > > > issue. And that's where it becomes complex and not so black and > > > white. Mike's test is a really good example of that. > > > > To the extent of you arguing that Mike's test is artificial (i'm not > > sure you are arguing that) - Mike certainly did not do an artificial > > test - he tested 'konsole' cache-cold startup latency, such as: > > [snip] > > I was saying the exact opposite, that Mike's test is a good example of > a valid test. It's not measuring single IO latencies, it's doing a > sequence of valid events and looking at the latency for those. It's > benchmarking the bigger picture, not a microbenchmark. Good, so we are in violent agreement :-) Ingo -- 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/ |