[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091002092409.GA19529@elte.hu>
Date: Fri, 2 Oct 2009 11:24:09 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Jens Axboe <jens.axboe@...cle.com>
Cc: Mike Galbraith <efault@....de>, Vivek Goyal <vgoyal@...hat.com>,
Ulrich Lukas <stellplatz-nr.13a@...enparkplatz.de>,
linux-kernel@...r.kernel.org,
containers@...ts.linux-foundation.org, dm-devel@...hat.com,
nauman@...gle.com, dpshah@...gle.com, lizf@...fujitsu.com,
mikew@...gle.com, fchecconi@...il.com, paolo.valente@...more.it,
ryov@...inux.co.jp, fernando@....ntt.co.jp, jmoyer@...hat.com,
dhaval@...ux.vnet.ibm.com, balbir@...ux.vnet.ibm.com,
righi.andrea@...il.com, m-ikeda@...jp.nec.com, agk@...hat.com,
akpm@...ux-foundation.org, peterz@...radead.org,
jmarchan@...hat.com, torvalds@...ux-foundation.org, riel@...hat.com
Subject: Re: IO scheduler based IO controller V10
* Jens Axboe <jens.axboe@...cle.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.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists