Messages in this thread | | | Date | Wed, 11 Jul 2007 15:09:28 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: x86 status was Re: -mm merge plans for 2.6.23 |
| |
On Wed, 11 Jul 2007, Andrea Arcangeli wrote: > > I'm going to change topic big time because your sentence above > perfectly applies to the O(1) scheduler too.
I disagree to a large degree.
We almost never have problems with code you can "think about".
Sure, bugs happen, but code that everybody runs the same generally doesn't break. So a CPU scheduler doesn't worry me all that much. CPU schedulers are "easy".
What worries me is interfaces to hardware that we know looks different for different people. That means that any testing that one person has done doesn't necessarily translate to anything at *all* on another persons machine.
The timer problems we had when merging the stuff in 2.6.21 just scarred me. I'd _really_ hate to have to go through that again. And no, the "gradual" thing where the patch that actually *enables* something isn't very gradual at all, so that's the absolutely worst kind of thing, because then people can "git bisect" to the point where it got enabled and tell us that's where things broke, but that doesn't actually say anything at all about the patch that actually implements the new behaviour.
So the "enable" kind of patch is actually the worst of the lot, when it comes to hardware.
When it comes to pure software algorithms, and things like schedulers, you'll still obviously have timing issues and tuning, but generally things *work*, which makes it a lot easier to debug and describe.
Linus - 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/
| |