From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: IO scheduler based IO controller V10
Date: Fri, 02 Oct 2009 14:26:24 UTC
Message-ID: <fa.smdm7D7QVSXQdHBA8nBVvktgNuQ@ifi.uio.no>

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

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: IO scheduler based IO controller V10
Date: Fri, 02 Oct 2009 15:16:44 UTC
Message-ID: <fa.FYKaAd9KnbXkA83NHkup64ZjSQE@ifi.uio.no>

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.

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.

> 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.

			Linus