Re: [RFC patch 1/2] sched: dynamically adapt granularity with nr_running

Linus Torvalds
2010-09-11T20:53:30Z

On Sat, Sep 11, 2010 at 1:45 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Sat, 2010-09-11 at 22:36 +0200, Peter Zijlstra wrote:
>>
>> But if you want us to change the scheduler to be more latency sensitive
>> and trade in throughput for other benchmarks, we can do that.
>
> Really, just say "latency trumps throughput" and we'll make it so.

Nothing is ever that black-and-white.

But latency really _is_ important. And it's often overlooked, because
few benchmarks actually test it. So when somebody sends you actual
measured latency numbers, you shouldn't be so cavalier. And you
shouldn't say "trumps throughput", since it's clearly a matter of
balancing, and quite frankly, Mathieu's patch does seem to try to
balance things.

As mentioned, it does seem to make tons of conceptual sense to take
the number of running threads into account for the whole scheduling
granularity decision. After all, we already do that for the other
important numbers (the scheduling period and time slice).

So to me it looks like you're just being negative, without actually
looking at the patch and giving it some fair thought. That's what I'm
objecting to.

Linus