Messages in this thread | | | Date | Thu, 1 Oct 1998 14:22:44 +0200 (CEST) | From | Rik van Riel <> | Subject | Re: a different approach to scheduling issues |
| |
On Thu, 1 Oct 1998, Etienne Lorrain wrote:
> It is nice to optimise the scheduler, but maybe > having a "run" queue to parse is the main problem. > How about having an "ordered" queue, where the > next active process is the head of the queue, and > deciding to reorder the queue when an event is > signaled ?
I've thought about it, but it looks as if this solution will be more expensive than just scanning the queue. The main reasons for this are: - processes are often added to the queue for one shot of CPU power (eg. your mailreader when you read this) and sorting each time is expensive - the priorities change quite often (the running process' priority is decreased every jiffie) - with Richard's RT_queue patch, goodness() has become a little more efficient - the run queue is very short most of the time, walking it is about as expensive as sorting each time
What _is_ a problem interfering with RT latency too is the task priority recalculation (it is done with the task_lock held!).
If fixed that with a scheduler patch of my own, you can get it in the linux-kernel archives... My patch has the added advantage of better user responsiveness and better 'control' over I/O bound, niced tasks.
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/
| |