Linked by Thom Holwerda on Sat 28th Jul 2007 09:04 UTC
"People who think SD was 'perfect' were simply ignoring reality," Linus Torvalds began in a succinct explanation as to why he chose the CFS scheduler written by Ingo Molnar instead of the SD scheduler written by Con Kolivas. He continued, "sadly, that seemed to include Con too, which was one of the main reasons that I never [entertained] the notion of merging SD for very long at all: Con ended up arguing against people who reported problems, rather than trying to work with them." He went on to stress the importance of working toward a solution that is good for everyone, "that was where the SD patches fell down. They didn't have a maintainer that I could trust to actually care about any other issues than his own." Update: OSNews user superstoned pointed us to the other side of the story.
Permalink for comment 258925
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2005-07-08
Part of being a maintainer is saying no. In fact, good maintainers might say no a lot more than they say yes. When they're two competing solutions to the same problem, the maintainer certainly has to say no to a least one of them. The goal is not to hurt anyone's feelings, but to keep the project moving in the right direction for most users.
This isn't grade school. Just because you spend a whole bunch of time toiling unpaid on some code doesn't imply that you're entitled to get your code merged. You don't get brownie points for being a good guy or trying really hard. Code doesn't get merged on the grounds that everybody deserves a chance to contribute.
Code gets rejected all the time, and developers almost always take it in stride. Sometimes they make a fuss, and you can't have that in a mature project. If the developer won't stop complaining, the maintainer might have to take them down a peg in order to put out the flames.
The maintainers of Subversion did an excellent talk on people management in open-source projects where they stressed the importance of removing poisonous personalities from your project. Sometimes you have show good developers the door if they can't work appropriately in the context of the project as a whole. At the end of the day, the project is more important than any single developer, however productive and talented they might be.
Maybe SD is better in some respects while CFS is more consistent overall. But the primary reason why Linus chose CFS is because Ingo is a very reliable and experienced maintainer who's had at least twice as much code rejected than Con has ever submitted. He won't take his ball and go home, whereas CK apparently will.
Finally, plugsched is a bad idea because scheduler proliferation is evil. There wouldn't be just two or three schedulers, there would be ten, each one representing a major configuration that needs to be tested. Anyone can write a scheduler that's optimized for a particular workload, but that defeats the purpose. The scheduler should perform consistently in a variety of workloads.
I hope that SD lives on as a patchset for those workloads that benefit from it. But one solid scheduler is all we need in the mainline kernel. CFS is the right choice for the long haul. We'll all benefit from the improvement over the O(1) scheduler, so we should be happy.