Messages in this thread | | | Date | Sat, 14 Aug 1999 14:52:32 -0600 | From | Richard Gooch <> | Subject | Re: low priority soft RT? |
| |
yodaiken@chelm.cs.nmt.edu writes: > On Wed, Jul 28, 1999 at 07:09:32AM +1000, Richard Gooch wrote: > > So SCHED_IDLE shouldn't be lambasted for making a deadlock possible, > > because SCHED_OTHER (in the presence of RT processes) can do the > > same. > > Sure. But another way of seeing it is: SCHED_FIFO/RR introduces the > possibility of deadlocks and makes it seem more reasonable to > introduce other scheduling classes that are not any worse. So the > original mistake has a snowball effect. The problem is that > SCHED_RR/FIFO is incorrectly implemented as the highest priority > class. What is needed is a priority class switch that makes sure > SCHED_OTHER gets some percentage of the cpu time. As I understand > the POSIX specs, there is no specification of the interaction > between scheduling policies. So it is POSIX compliant to give some > time to SCHED_OTHER processes even when SCHED_RR processes are ready > to run.
Unfortunately I don't have my POSIX.4 book handy (it's still in transit), but I recall that it states that the highest RT process on the run queue will get the CPU. That means SCHED_OTHER has to wait until the RT process blocks.
> >Which is why I support moving !SCHED_OTHER processes to > > SCHED_OTHER when they call schedule(), and moving them back when > > schedule() returns. > > Doesn't that defeat the purpose of the soft-rt? There is no > point in being SCHED_RR only when you own the processor. > Or maybe I misunderstand your idea?
If you're running in kernel mode, then being RT isn't a great help. But if you're in user mode, then it most certainly makes a difference :-)
The reason I suggest dropping RT when calling schedule() is: - it ensures lower priority processes in the kernel can make progress - there is no effective loss, as devices won't run any faster for RT processes :-) (unless you prioritise I/O, which is the wrong approach anyway).
Regards,
Richard.... Old: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca
- 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/
| |