> I seem to remember various people bringing up the idea of changing the way
> that the scheduler works, and it being shot down quite a while back. I
> have been looking at the QNX-style scheduler patches for 2.0.x, and I
> would like to know what the feeling is about touching the scheduling code.
It would be good to change the scheduler code. The current
scheduler might be 'bug-free', but it suffers from poor
response at high loads and doesn't do per-user CPU accounting
(useful in some situations) or tree-based scheduling (which
enhances thread_yield performance).
> I seem to remember that the main objections at the time (this was before
> the QNX-style patches) were that the proposed changes were too complex,
> and broke the KISS rule. Would a multilevel-feedback scheduler still be
> considered too complex for the kernel? Would SMP support benefit from
> this? Could real-time applications benefit?
It would be good to have a changed QNX scheduler in the
kernel. It should at least be changed to prevent starvation
in _all_ situations. I've got some ideas about this, but
I think that's better suited for private e-mail.
> What I'm after is a scheduler that works well under all loading
> conditions. I have had a machine up to a load of 178 before, and it took
> 3 days to get it back to normal. I know a bit of this was due to
> swapping, which is being addressed already, but I'd like to work with the
> scheduler to see if that would also help matters.
We should also implement proces suspension in case of a
low memory situation.
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