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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
