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/