[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
[dm-devel] Re: IO scheduler based IO controller V10
- From: Linus Torvalds <torvalds linux-foundation org>
- To: Jens Axboe <jens axboe oracle com>
- Cc: dhaval linux vnet ibm com, peterz infradead org, dm-devel redhat com, dpshah google com, agk redhat com, balbir linux vnet ibm com, paolo valente unimore it, jmarchan redhat com, fernando oss ntt co jp, Ulrich Lukas <stellplatz-nr 13a datenparkplatz de>, mikew google com, jmoyer redhat com, nauman google com, Ingo Molnar <mingo elte hu>, Vivek Goyal <vgoyal redhat com>, m-ikeda ds jp nec com, riel redhat com, lizf cn fujitsu com, fchecconi gmail com, containers lists linux-foundation org, Mike Galbraith <efault gmx de>, linux-kernel vger kernel org, akpm linux-foundation org, righi andrea gmail com
- Subject: [dm-devel] Re: IO scheduler based IO controller V10
- Date: Fri, 2 Oct 2009 07:24:41 -0700 (PDT)
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.
And Mike's patch didn't look big or complicated.
> You can't say it's black and white latency vs throughput issue,
Umm. Almost 1000% vs 30%. Forget latency vs throughput. That's pretty damn
black-and-white _regardless_ of what you're measuring. Plus you probably
made up the 30% - have you tested the patch?
And quite frankly, we get a _lot_ of complaints about latency. A LOT. It's
just harder to measure, so people seldom attach numbers to it. But that
again means that when people _are_ able to attach numbers to it, we should
take those numbers _more_ seriously rather than less.
So the 30% you threw out as a number is pretty much worthless.
Linus
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]