> Andrew J. Anderson wrote:
> > "quantum expiration policy" that reduces your CPU window if
> > you get an involuntary context switch -- this keeps CPU hogs from choking
> > the machine.
>
> My scheduler will move a process onto a higher run-queue if it consumes
> its entire timeslice without blocking, but it doesn't change the process's
> timeslice length -- I'm not really sure if I should do that.
It will reduce the VM load that niced processes cause. If
you have 5 huge background processes running, it might be
nice to give them 1 minute timeslices...
> > "sleep return priority" that is generally higher than the current priorty
> > (this keeps interactive performance good) -- the idea being that the
> > process blocked on IO and is now ready to do something.
>
> My scheduler does reward processes for blocking, though probably in a
> slightly different way.
Your way (the QNX-sched way) is probably better.
> > "long wait priority" that handles nice'd processes to make sure that they
> > get some CPU time. This is roughly double the maximum wait by default.
>
> I think it has the basic feedback elements you mention, but does allow
> starvation to happen. I'm hoping to fix that within a few weeks.
Starvation is the _only_ remaining true problem with
QNX-sched. The other things are very minor compared
to that, and can be fixed easily.
Also, when a process starves and gets promoted, it might
be nice to halve the systemwide timeslice length for 5
seconds, so no other process will suffer starvation.
This might be nice in high-load-multi-user systems.
Rik.
+-----------------------------+------------------------------+
| For Linux mm-patches, go to | "I'm busy managing memory.." |
| my homepage (via LinuxHQ). | H.H.vanRiel@fys.ruu.nl |
| ...submissions welcome... | http://www.fys.ruu.nl/~riel/ |
+-----------------------------+------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu