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?
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/

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