make_runnable()
{
...
/* need interlock here */
if (this_process.priority > highest_waiting_priority)
highest_waiting_priority = this_process.priority
...
}
pick_process()
{
...
queu_to_scan = runqueues[highest_waiting_priority]
<<scan down from there>>
/* if it's not possible for a process to leave a run queue without
being run, then no scan is necessary; highest_waiting_priority
is always the queue whose head process should be run. */
...
}
BTW, what would you like to use to help decide which process to run next?
> The problem is that interactive tasks tend to have higher priorities than
> CPU-bound ones. If you've got a machine with one or more CPU-bound processes,
> they spend all their time at relatively low priorities, which means your scan
> of the per-priority run-queues will tend to find them last.
It won't find them at all until there is no higher-priority work to do.
> This is exactly
> the wrong behaviour: if you're CPU-bound, you want to spend as much time as
> possible running in the process.
We always want to spend as much time as possible doing user work. But we
never want to wait until quantum-end to echo interactive typing, etc.
> Interactive processes (= mostly sleeping,
> higher priority), on the other hand, get the best response because they're near
> the top of the list of run-queues to scan. This is good, but there are better
> ways of dealing with it (like Linux now, for example).
Pray elucidate. Or direct me to a reference where I can get up to speed
on the current method.
Scheduling is always black magic and never satisfies everybody. Without
agreement on the notion of "fairness" to be implemented, one can't even
debate sensibly. (Imagine John D. Rockefeller and Karl Marx debating
"just compensation".)
> If I remember my history right, the multiple run-queue scheduler design
> appeared in BSD so they could use a particular Vax instruction to find the next
> useful run-queue. As it turned out, as with so many other Vax instructions, it
> wasn't such a performance win there, and it hasn't been that great since.
Probably a find-first-bit sort of instruction. I used a similar thing on
PDP10s and it probably didn't buy much then either.
-- Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu Some things are not improved when made "graphical". Imagine how crude Kilmer's "Trees" would be if reduced to comic-book form.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/