Messages in this thread | | | Date | Sat, 17 Mar 2007 17:34:34 +0100 | From | Ingo Molnar <> | Subject | Re: is RSDL an "unfair" scheduler too? |
| |
* Con Kolivas <kernel@kolivas.org> wrote:
> Ok but please look at how it appears from my end (illness aside).
( i really think we should continue this debate after you get better. Everything looks much darker when you are ill! )
> You initially said you were pleased with this design.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |