Messages in this thread | | | Date | Thu, 01 Oct 1998 12:17:12 -0700 (PDT) | From | Jeremy Fitzhardinge <> | Subject | Re: a different approach to scheduling issues |
| |
On 01-Oct-98 Rik van Riel wrote: > The main problem is that the scheduling code is very > time critical. It is one of the main performance > loopholes for every Unix in existance, so we need to > make it as fast as possible.
Actually, scheduling isn't especially time-critical, but context switching is.
It's quite common for systems to only recalculate priorities every second or so, even if they're switching contexts much more rapidly. This allows you to do more interesting/complex scheduling decisions without everything bogging down. Maybe you could even run the scheduler in user-mode as an RT task...
The way I'd do it is have "schedule()" not control priorities at all, but simply maintain accurate and precise info (and I mean *accurate* and *precise* - use the cycle counter to measure how much of a time-slice was used, if that's an option) on what each process has done. Every now and then (a tunable which depends on how responsive you need your dynamic priorities to be) you go through and recalculate the relative importance of your running processes.
RT processes, of course, never have their priorities changed, so the scheduler is essentially a no-op. Sleeping processes never need their priorities adjusted until they actually become runnable.
Ideally you'd get rid of the idea of a priority number too, and just have the scheduler decide on the relative importance of two processes, which would control ordering on the run queue. This gets rid of all kinds of problems which affect more complex schedulers which can't easily map process importance into a limited integer range.
So, yeah, I think a carefully designed scheduler interface has the potential to be both very flexible and efficient.
J
- 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/
| |