Messages in this thread | | | Date | Tue, 16 Sep 1997 09:08:15 -0600 (CST) | From | Adam McKee <> | Subject | Re: QNX scheduler |
| |
On Tue, 16 Sep 1997, Pavel Machek wrote:
> Thanks for using NetForward! > http://www.netforward.com > v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v > > Hi! > > I was looking at your QNX scheduler, and have some questions: > > 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"). > > So, assume that you 30 tasks at rq = 15, and one 'background' on tq = > 20. Ok? All tasks are number crunching, i.e. never sleep. What will > happen? Task that should stay in foreground (so that background job > will not compete with them) will force eatch other down into > 'background' priority, so background task competes with them. Bad.
Try it out. My guess is that none of the 30 "cpu crunching" tasks would make it all the way down to run_q 20. However, if this *was* a problem, you could use the 'max_run_q' setting to fix that. This scheduler is not perfect - it does pretty well, but for the absolute best results you need to intervene and set scheduling parameters yourself (hence 'qsched').
> > 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"). Something I have added: a task cannot > be promoted back to its min-run-queue because of starvation -- it > must block (for at least 100ms) to get back to its > min-run-queue.
> Why is this?
The idea here is that if a task has been demoted and waiting to run for a long time, it should be given a chance to run. Suppose you start two number-crunching tasks - they each start out on run_q 15. The 1st task uses its entire timeslice, then gets demoted because there is 1 other task that wants to run. Now the 2nd task runs, but it does not get demoted at the end of its timeslice because it's alone on run_q 15 (we moved the 1st task to run_q 16). So the 2nd task gets to feast on CPU while the 1st task starves... We don't let it starve forever - so we promote it. We put it at the end of run_q 15. The 2nd task finishes another timeslice, but now there *is* another task on the run_q so it's demoted. Now it's the 2nd task's turn to starve for a whole second! The two tasks will take turns starving, instead of 1 task being totally victimized by the scheduler. The same type of thing happens with larger numbers of tasks.
-- Adam
| |