Re: [PATCH] scheduler patch, faster still

Larry McVoy (lm@bitmover.com)
Tue, 29 Sep 1998 19:40:17 -0600


Felix von Leitner <leitner@math.fu-berlin.de>:
: Thus spake Larry McVoy (lm@bitmover.com):
: > Remember to step back and consider what would happen to the system if
: > everything was changed just a little for some application.
:
: His numbers did not look like it was just one application.

Really? What were the other applications?

: I got the impression that he made the common case faster.

The only thing his patch does that could make the common case faster is
the removeal of

if (policy != SCHED_OTHER)
return 1000 + p->rt_priority;

in the goodness() function. If rt_priority is off in isolation in the
task struct, then that could save you a cache miss/process, or about
120ns. On the other hand, if you were really concerned about that cache
miss, then put the rt_priority field next to some other field that you
know will be referenced and now you're down to to a 10-20 ns for the
compare & test & branch delay.

On the other hand, we now have more cache foot print in the scheduler
code path for every single context switch. The extra queue turns into
extra globals and locals as well as an extra while loop that gets run
every time. Kiss the 10-20 ns savings good bye, they are gone.

So to claim that Mr Gooch made the common case faster is neither proven
due to cycle counter results or obvious from code inspection. In fact,
the opposite is true.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/