Messages in this thread | ![/](/images/icornerl.gif) | | Date | Sun, 27 Jul 1997 10:10:49 +0300 (EET DST) | From | Tuomas Heino <> | Subject | Re: [patch] QNX-style scheduling for Linux 2.0 |
| |
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?
| ![\](/images/icornerr.gif) |