[...]
> Well i just tested 2.0.30 with the QNX-style scheduler (1.05) and
> found it to handle 50 looping bash-scripts, 1 gnuchess and a simple
> X-Session (Server, xterm, fvwm2) and still reacting instantaneous to
> input on another virtual terminal. The load was >56. Not bad for a
> Pentium-100... I am now giving it a try on my old 4 MB 386 and my
> 233MHz Multia, to see how much load they can handle... This time i will
> use the program you posted.
>
> The adaptive scheduling of the new scheduler is really a neat feature.
i dont think there is any justification to 'punish' a process, just
because it does no system calls ... it might be a database server.
if any heuristics are used, then it should be user-definable, just like
now. I dont think we want to end up with complaints like this: 'hey our
number-cruncher is getting so slow when the web server is running'. Or
solutions will show up that do a fake system call every now and then, to
'pump up' the effective priority ...
Every thread has it's right to it's full quantum, and the OS has to
provide this. So i think adaptive scheduling is nice, but should not be at
all the default scheduling policy.
the only heuristics i think would be useful, is to give _human sourced
interrupts_ some 'priority quantum', which they carry and transfer to
processes ;) This would be attached to my keyboard and my mouse ;) We now
get the same effect in a very indirect way: human interrupts are by nature
very long-intervalled, thus processes depending on these interrupts and
doing short action are able to accumulate dynamic priority usually. Also,
NT's 'foreground priority' concept is an alternative (but quite broken ;)
way to provide the same effect.
-- mingo