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: Mike Galbraith on 2 Oct 2009 12:10 On Fri, 2009-10-02 at 11:40 -0400, Vivek Goyal wrote: > On Fri, Oct 02, 2009 at 05:32:00PM +0200, Mike Galbraith wrote: > > On Fri, 2009-10-02 at 17:27 +0200, Corrado Zoccolo wrote: > > > On Fri, Oct 2, 2009 at 2:49 PM, Vivek Goyal <vgoyal(a)redhat.com> wrote: > > > > On Fri, Oct 02, 2009 at 12:55:25PM +0200, Corrado Zoccolo wrote: > > > > > > > > Actually I am not touching this code. Looking at the V10, I have not > > > > changed anything here in idling code. > > > > > > I based my analisys on the original patch: > > > http://lkml.indiana.edu/hypermail/linux/kernel/0907.1/01793.html > > > > > > Mike, can you confirm which version of the fairness patch did you use > > > in your tests? > > > > That would be this one-liner. > > > > Ok. Thanks. Sorry, I got confused and thought that you are using "io > controller patches" with fairness=1. > > In that case, Corrado's suggestion of refining it further and disabling idling > for seeky process only on non-rotational media (SSD and hardware RAID), makes > sense to me. One thing that might help with that is to have new tasks start out life meeting the seeky criteria. If there's anything going on, they will be. -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: jim owens on 2 Oct 2009 12:20 Linus Torvalds wrote: > > I really think we should do latency first, and throughput second. Agree. > It's _easy_ to get throughput. The people who care just about throughput > can always just disable all the work we do for latency. But in my experience it is not that simple... The argument latency vs throughput or desktop vs server is wrong. I/O can never keep up with the ability of CPUs to dirty data. On desktops and servers (really many-user-desktops) we want minimum latency but the enemy is dirty VM. If we ignore the need for throughput to flush dirty pages, VM gets angry and forced VM page cleaning I/O is bad I/O. We want min latency with low dirty page percent but need to switch to max write throughput at some high dirty page percent. We can not prevent the cliff we fall off where the system chokes because the dirty page load is too high, but if we only worry about latency, we bring that choke point cliff in so it happens with a lower load. A 10% lower overload point might be fine to get 100% better latency, but would desktop users accept a 50% lower overload point where running one more application makes the system appear hung? Even desktop users commonly measure "how much work can I do before the system becomes unresponsive". jim -- 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 12:30 * Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > On Fri, 2 Oct 2009, Jens Axboe wrote: > > > > It's really not that simple, if we go and do easy latency bits, then > > throughput drops 30% or more. > > Well, if we're talking 500-950% improvement vs 30% deprovement, I > think it's pretty clear, though. Even the server people do care about > latencies. > > Often they care quite a bit, in fact. The other thing is that latency is basically a given property in any system - as an app writer you have to live with it, there's not much you can do to improve it. Bandwidth on the other hand is a lot more engineerable, as it tends to be about batching things and you can batch in user-space too. Batching is often easier to do than getting good latencies. Then there's also the fact that the range of apps that care about bandwidth is a lot smaller than the range of apps which care about latencies. The default should help more apps - i.e. latencies. 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: Ray Lee on 2 Oct 2009 12:40 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. -- 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 12:40
* Mike Galbraith <efault(a)gmx.de> wrote: > On Fri, 2009-10-02 at 11:24 +0200, Ingo Molnar wrote: > > * Jens Axboe <jens.axboe(a)oracle.com> wrote: > > > > > It's not hard to make the latency good, the hard bit is making sure we > > > also perform well for all other scenarios. > > > > Looking at the numbers from Mike: > > > > | dd competing against perf stat -- konsole -e exec timings, 5 back to > > | back runs > > | Avg > > | before 9.15 14.51 9.39 15.06 9.90 11.6 > > | after [+patch] 1.76 1.54 1.93 1.88 1.56 1.7 > > > > _PLEASE_ make read latencies this good - the numbers are _vastly_ > > better. We'll worry about the 'other' things _after_ we've reached good > > latencies. > > > > I thought this principle was a well established basic rule of Linux > > IO scheduling. Why do we have to have a 'latency vs. bandwidth' > > discussion again and again? I thought latency won hands down. > > Just a note: In the testing I've done so far, we're better off today > than ever, [...] Definitely so, and a couple of months ago i've sung praises of that progress on the IO/fs latencies front: http://lkml.org/lkml/2009/4/9/461 .... but we are greedy bastards and dont define excellence by how far down we have come from but by how high we can still climb ;-) 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/ |