RE: [patch] QNX-style scheduling for Linux 2.0

Adam McKee (amckee@poboxes.com)
Mon, 28 Jul 1997 12:51:57 -0600 (CST)


Actually I did reverse the 0/31 priorities. QNX has run-queue 31 as the
highest priority, run-queue 0 as the lowest. I reversed this because it
doesn't affect performance/behaviour, and I found it a little nicer to
have run-queue 0 the highest priority.

Also, it is *not* possible for a process to get promoted beyond its base
priority unless root decides to re-nice it... If a process's base
priority is too low, it can definitely starve...

It looks like VMS's scheduler and QNX's scheduler have a lot in common. I
wonder who invented the adaptive scheduling technique? It's quite simple
and effective.

-- Adam

On Mon, 28 Jul 1997, Mark H. Wood wrote:

> On Sun, 27 Jul 1997, Adam McKee wrote:
>
> > Hi there.
> >
> > It does not do real-time in any way. It only implements the QNX scheduler
> > as described by a couple of different sources. I should probably make it
> > clear in the README that the patch does *not* do real-time, since the
> > "QNX" name might imply that it does real-time.
>
> OpenVMS has a scheduling scheme that is quite similar to QNX Adaptive,
> except that (a) higher priorities are numerically greater, not less, and
> (b) a process is never demoted past its base priority, which appears to
> be possible in QNX. VMS was supposed to be somewhat suitable for
> realtime as well as general timesharing, so they rigged the scheduler to
> always do strict round-robin scheduling within queues of priority 16 and
> higher (that is, the highest-priority queues) with no time-slicing. 15
> and below will move between queues, get pre-empted at quantum-end, etc.
>
> Mark H. Wood, Lead System Programmer MWOOD@INDYVAX.IUPUI.EDU
> Those who will not learn from history are doomed to reimplement it.
>