lkml.org 
[lkml]   [1998]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.085 / U:1.704 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site