Re: yet another scheduling problem

Artur Skawina (skawina@geocities.com)
Sun, 12 Dec 1999 19:50:48 +0100

Borislav Deianov wrote:
>
> After a SCHED_FIFO task exhausts its initial timeslice, its counter is
> never reset. It then starts causing reschedules on every timer tick.
> This doesn't alter scheduling behavior but it slows things down
> noticeably.

Yes, that's exactly what happens. I guess your (presumably more complex)
scheduler made this more visible. It means threads using SCHED_FIFO are
currently a tiny bit slower than those using SCHED_RR, a bit counter
intuitive maybe, but not a big problem (the difference was under 1%). It
_does_ mean that the SCHED_FIFO thread looses control for much longer
than necessary on every timer interrupt. Here the numbers are 10us (4500
cycles) normally (SCHED_OTHER/SCHED_RR) and almost 100% more for
SCHED_FIFO (it depends a lot on the number of threads on the runqueue at
the time). I suspect the stock scheduler isn't much different wrt this.
Changing the timer interrupt to treat SCHED_FIFO differently eliminates
the problem - the interrupt cost remains constant for all policies. [1]

Thanks for pointing this out,

artur

[1] With something like this

--- ../linux-2.3.31/kernel/sched.c Tue Dec 7 21:35:39 1999
+++ kernel/sched.c Sun Dec 12 18:39:02 1999
@@ -1312,7 +1325,10 @@
p->counter -= ticks;
if (p->counter <= 0) {
p->counter = 0;
- p->need_resched = 1;
+ if (p->policy&SCHED_FIFO)
+ p->counter = p->priority; */
+ else
+ p->need_resched = 1;
}
if (p->priority < DEF_PRIORITY)
kstat.cpu_nice += user;

(plus the same in arch/smp.c), the timings, no matter which scheduling
policy is used, look like this:

(first number is the time the process was interrupted for,
second is delay before next interrupt. Both in microseconds.)

9.90 966.87
9.93 966.87
9.48 967.24
9.76 966.96
9.98 938.64
7.73 20.39
10.26 966.49
9.52 967.24
10.61 966.12
10.01 966.77
9.48 967.23
9.55 967.23
9.96 966.77
10.33 966.40
9.48 967.24
9.86 966.96
10.07 966.68
9.48 967.24
9.55 967.15
10.47 966.31
9.97 966.77
9.52 967.24
9.75 967.05
9.95 966.77
10.24 966.49
9.48 967.24

Note HZ is nonstd, but that shouldn't make any difference to the interrupt
cost (1st column). w/o the above patch the interrupts used to take ~20us.

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