Messages in this thread | | | Date | Sun, 14 Sep 1997 11:32:14 +1000 | From | Richard Gooch <> | Subject | Pre-empting SCHED_FIFO and SCHED_RR processes |
| |
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 this?
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.
Regards,
Richard....
| |