Messages in this thread |  | | | Date | Mon, 28 Jul 1997 12:51:57 -0600 (CST) | | From | Adam McKee <> | | Subject | RE: [patch] QNX-style scheduling for Linux 2.0 | |
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.
>
|  |