Pre-empting SCHED_FIFO and SCHED_RR processes

Richard Gooch (rgooch@atnf.CSIRO.AU)
Sun, 14 Sep 1997 11:32:14 +1000

Hi, all. I've been taking a cursory look at the way the Linux
scheduler works, in order to determine when a SCHED_FIFO or
SCHED_RR ("realtime") process which has the highest priority is woken
up inside an interrupt handler starts running. It appears that such a
process will begin running at the end of the current time quantum.
Is this correct? If so, I wonder if there are any plans to change

I imagine it could be possible to check if need_resched is set when
interrupt handlers (registered with request_irq() and friends) return
and we are about to return from the interrupt. If need_resched is set
we could do a further test to see if there are any realtime processes
waiting to be run, and if so do a schedule() (and take out that
"interesting" goto in schedule(), of course). This would make the
response to interrupts much better. I assume that a realtime process
would lock all its current and future pages.

I'll admit I haven't looked closely to see what the problems would be
in doing this, but perhaps someone more knowledgeable could give some
insight? Yes, I know about RT/Linux, but I was wondering if it would
be feasible to do it within the existing framework.