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. >
| |