( i really think we should continue this debate after you get better.
Everything looks much darker when you are ill! )
I said that 2 years ago about the staircase scheduler and i am still
saying this about RSDL today. That doesnt make my position automatically
correct though :-) For example i wrote and maintained the 4g:4g patchset
for over 2 years and still that was no guarantee of it making sense
upstream ;) And it was a hell of a lot of work (much uglier and nastier
work than any scheduler hacking and tuning, believe me), and it was
thrown away as a cute but unnecessary complication we dont need. So
what? To me what matters is the path you walk, not the destination you
reach.
in terms of RSDL design, i like it, still i'm kind of asking myself
'couldnt something in this direction be done in a much simpler and less
revolutionary way'? For example couldnt we introduce per-priority level
timeslice quotas in the current scheme as well, instead of the very
simplistic and crude STARVATION_LIMIT approach? Furthermore, couldnt we
make the timeslices become smaller as the runqueue length increases, to
make starvation less of a problem? It seems like the problem cases with
the current scheduler arent so much centered around the interactivity
estimator, it is more that timeslices get distributed too coarsely,
while RSDL distributes timeslices in a more finegrained way and is thus
less suspect to starvation under certain workloads.
in any case, regardless the technical picture, i do get nervous when a
group of people tries to out-shout clearly valid feedback like Mike's,
and i'll try to balance such effects out a bit. _Of course_ those people
that are not happy with the current scheduler have a higher likelyhood
to try out another scheduler and be happy about it - but we should not
allow that natural bias (which, btw., could easily be the _truth_, so
i'm not assuming anything) to stand in the way of critical thinking. I
also get slightly nervous about what appears to be dubious technical
claims like "this is X's fault and if you rewrite X it will work much
better so go away and do not stand in the way of progress" or "this new
scheduler does away with all those ugly heuristics". I'm almost getting
a reiser4 de ja vu :-/
we should really let this sit through in -mm for at least one more
kernel iteration, let more folks be exposed to it and keep an eye on
regression reports. [ An _eye_, not a machine gun ;-) ]
Ingo
-
