* Rene Herman <[EMAIL PROTECTED]> wrote: > To me, the example rather serves as confirmation of what Kolivas has > been saying; endlessly tweaking the tweaks isn't going anywhere.
but ... SD clearly regresses in some areas, so by that logic SD isnt going anywhere either? note that i still like the basic idea about SD, that it is an experiment that if the only conceptual focus is on "scheduling fairness", we'll get a better scheduler. But for that to work out two things have to be done i think: - the code actually has to match that stated goal. Right now it diverges from it (it is not a "fair" scheduler), and it's not clear why. note that SD at the moment produces ~10% more code in sched.o, and the reason is that SD is more complex than the vanilla scheduler. People tend to get the impression that SD is simpler, partly because it is a net linecount win in sched.c, but many of the removed lines are comments. this "provide fairness" goal is quite important, because if SD's code is not only about providing fairness, what is the rest of the logic doing? Are they "tweaks", to achieve interactivity? If yes, why are they not marked as such? I.e. will we go down the _same_ road again, but this time with a much less clearly defined rule for what a "tweak" is? note that under the interactivity estimator it is not that hard to achieve forced "fairness". So _if_ we accept that scheduling must include a fair dose of heuristics (which i tend to think it has to), we are perhaps better off with an interactivity design that _accepts_ this fundamental fact and separates heuristics from core scheduling. Right now i dont see the SD proponents even _accepting_ that even the current SD code does include heuristics. the other one is: - the code has to demonstrate that it can flexibly react to various complaints of regressions. (I identified a few problem workloads that we tend to care about and i havent seen much progress with them - but i really reserve judgement about that, given Con's medical condition.) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/