Messages in this thread | | | From | Linus Torvalds <> | Date | Sat, 11 Sep 2010 13:52:40 -0700 | Subject | Re: [RFC patch 1/2] sched: dynamically adapt granularity with nr_running |
| |
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
| |