Messages in this thread | | | Date | Sat, 14 Aug 1999 17:09:04 -0600 | From | yodaiken@chelm ... | Subject | Re: low priority soft RT? |
| |
On Sat, Aug 14, 1999 at 02:52:32PM -0600, Richard Gooch wrote: > yodaiken@chelm.cs.nmt.edu writes: > > 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.
According the the single unix spec Each process is controlled by an associated scheduling policy and priority. Associated with each policy is a priority range. Each policy definition specifies the minimum priority range for that policy. The priority ranges for each policy may overlap the priority ranges of other policies.
> > > >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/
| |