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

Tuomas Heino (tbittih@xgw.fi)
Sun, 27 Jul 1997 10:10:49 +0300 (EET DST)


On Sat, 26 Jul 1997, Adam McKee wrote:

> QNX-style Scheduling v1.00 for Linux 2.0
[snip]
> THE QNX SCHEDULER
>
> My understanding of the QNX scheduler is based entirely on a short blurb I
> read about it, so I would not be surprised to find that the following
> discussion contains errors and/or omissions. However, please do read
> on... :-)

well it does contain some "errors" ;)

> There are 32 separate run-queues, numbered 0-31. When the scheduler is
> looking for a task to run, it will select a task from the lowest-numbered
> run-queue that has a runnable task on it. This means that, for example, a
> task on run-queue 1 will *not* run until there are no task on run-queue 0 that
> want to run. The init task has a minimum run-queue of 10. Newly created
> tasks inherit their minimum run-queue from their parent.

In qnx [as of 4.23A] the idle loop runs on queue 0 and kernel on 31...
so there're more "more important than default" run-queues than "less
important" ones... so run-queue 0 won't run if any task on [1-31] wants to ;)

[snip]

> Here are the rules for adaptive scheduling:
>
> o Each task has a 'minimum run-queue' attribute that tells the
> scheduler the lowest-numbered run-queue the task can be on.
> "Normal" tasks have minimum run-queue = 10.
>
> o When a task is initially started, it is placed on its minimum
> run-queue.
>
> o If a task blocks (does not use all of its timeslice), it will
> be placed on its minimum run-queue when it becomes runnable again.
>
> o If a task uses up all of its timeslice, and there is at least one
> other task on the same run-queue that wants to run, its run-queue
> will be incremented ("demotion").
>
> o If a task has been starving for one second, and its current run-queue
> is greater than its minimum run-queue, its run-queue will be
> decremented ("promotion").
>
> The result of applying these rules is that tasks with heavy CPU requirements
> will tend to migrate to higher-numbered run-queues, whereas tasks with light
> CPU requirements will tend to stay on lower-numbered run-queues. This is
> *good* for interactive performance!
>
if you reverse 0/31 then demotion/promotion need that too ;)
also combining the linux and qnx schedulers might be a good idea...
... like use (re)nice as usually in linux and some other(s) for qnx scheduling?