The "math part" is important if you're doing a thesis defense, but
demonstrating better behavior under some realistic load would probably
be a better starting point. Maybe Ingo missed something in your math,
and maybe he just didn't find a benefit.
The ck and sd schedulers developed over a long time of public use and
redefinition of goals. The cfs developed faster, but still had months of
testing and the benefit of rt experience. Your scheduler is more of a
virgin birth, no slow public discussion before, no time yet for people
to run it under real loads, you're seeing first impressions.
You dropped this on the world two days before a major US holiday, at the
end of the summer when those of us not on vacation may be covering for
those who are, did you expect Ingo to drop his regular work to look at
your stuff? And do you think there are many people who can look at your
math, and look at your code, and then have any clue how well it works in
practice? I bet there aren't ten people in the world who would even
claim to do that, and half of them are kidding themselves.
So give people a few weeks to see if the rounding errors you eliminated
mean anything in practice. Faster context is nice, but it's not
something most people count as their major problem. I did a *lot* of cfs
vs. sd testing, not just all the glitch1 tests I posted here, lots of
stuff I just send to Ingo, and lots of tests like IPCbench and NNTP
server loading showed nothing. (That's good, it means cfs isn't worse
than the old scheduler for those loads.) I played with the tuning, I
even diddled the code a bit, without finding meaningful improvement, so
your possibly better math may not change the overall behavior much.
I will wait until I post actual test results before I say any more.
--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
-
