Messages in this thread | | | Date | Sun, 27 Sep 1998 12:46:56 +0200 (CEST) | From | Rik van Riel <> | Subject | Re: Scheduling Times --- Revisited |
| |
On Sun, 27 Sep 1998, Richard Gooch wrote:
> The separate run queues idea isn't going to bloat the kernel either, > before you raise that argument. Some code paths will in fact be > simplified and made more robust. The bug in goodness() is a classic > case of this.
In case you (both of you) haven't noticed, we already _have_ a separate runqueue, it's called the bottom half list...
Adding another one for RT tasks won't be a problem, all we have to do is make sure that the highest-priority RT task is up front (this shouldn't be hard as a proper RT system doesn't have more than 1 RT task on the queue, because of that the overhead will be absolutely minimal).
> To get to your other point: general improvements to the scheduler, I'm > not sure what you have in mind. It looks pretty good already. Apart > from the RT/long run queue latency issue, the only things that > occurred to me is the recalculation of counters. This walks the entire > process table. It would be nice to be able to avoid that.
We need to change 3 things in order to implement that: - add a sleep_time to the task struct, upon removal from the run queue, a p->sleep_time = jiffies is performed - add_to_runqueue() has to be modified in order to give the process back one priority point for each jiffie it slept, up to a maximum of p->priority (maybe this should be divided by the system load or by DEF_PRIORITY/p->priority???) - the recalculation stuff has to be changed to only recalculate the tasks on the run queue.
Once we've agreed on the answer to the question the second point raises, I'll be happy to code up the patch... I've looked into this a long time ago, there shouldn't be any problems implementing it. Btw, the point of dividing the number of added points by DEF_PRIORITY/p->priority is meant to favour interactive (non-niced) tasks so that it will become less obvious when one's workstation has been rigged up to form the local Beowulf cluster. Once we get to the point where people don't notice a running Beowulf task in the background, Linux might become somewhat more popular with compute-power-hungry folks...
Rik. +-------------------------------------------------------------------+ | Linux memory management tour guide. H.H.vanRiel@phys.uu.nl | | Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ | +-------------------------------------------------------------------+
- 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/
| |