[lkml]   [1999]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: low priority soft RT?
On Sat, Aug 14, 1999 at 02:52:32PM -0600, Richard Gooch wrote:
> 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:
> Current:

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:53    [W:0.059 / U:6.312 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site