lkml.org 
[lkml]   [1999]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

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