> 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/