Messages in this thread | | | Date | Thu, 01 Oct 1998 22:27:43 -0700 (PDT) | From | Jeremy Fitzhardinge <> | Subject | Re: a different approach to scheduling issues |
| |
On 02-Oct-98 Rik van Riel wrote: >> 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... > > Hmm. Although it is an interesting idea, it kinda conflicts > with the next part of your message...
How so?
>> 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. > > This is in my patch. It recalculates the importance of > only the running processes as soon as each process on > the runqueue has used up it's timeslice.
That's a little more often than I'm talking about. You divide your scheduler into two parts: one which makes sure processes get CPU at a certain rate, and another which assigns what rate processes should get CPU at. The former is a pretty simple procedure which can be implemented by controlling the placement of processes on the run-queue, and has to be performed whenever something gets put on the run-queue. The latter process can be done less frequently, and calculated based on the behaviour of the process since the last calculation (and other factors). By "less frequently", I mean somewhere in the order of .1-10 seconds, depending on what the nature of the machine's load is.
>> 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. > > Hey, I did that first! :-) This is in my patch > as well...
Well, yes, it was something that needed doing. I was pleased to see it in your patch.
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/
| |