> 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