Messages in this thread Patch in this message | | | Date | Sun, 12 Dec 1999 19:50:48 +0100 | From | Artur Skawina <> | Subject | Re: yet another scheduling problem |
| |
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/
| |