Re: [PATCH] scheduler patch, faster still

Richard Gooch (rgooch@atnf.csiro.au)
Tue, 29 Sep 1998 15:42:01 +1000


Theodore Y. Ts'o writes:
> Date: Mon, 28 Sep 1998 19:07:51 -0400
> From: Dennis Grant <dg50@chrysler.com>
>
> Firstly, I feel that you and your partner in ill manners
> yodaiken@chelm.cs.nmt.edu are being way too hard on this guy. It's one
> thing if he's mistaken and you're trying to help him see his error - but
> I don't see that.
>
> Actually, I think Larry and Victor have been remarkably restrained,
> in the face of some of Mr. Gooch's mail to this list. Larry and
> Victor both have a lot of experience in this area, and quite frankly
> their opinions carry a lot more weight with me at least than
> Mr. Gooch.

No, Ted. Larry in particular has been rude and aggressive, and even
Victor has swayed that way. I have *not* been rude or aggressive.
I have a different point of view on the technical issues which I am
entitled to. In absolutely no way does that make me rude. I have
listened to their arguments and frankly I'm not convinced.

> Sometimes mathematicians get fed up when people repeatedly make
> claims that they can square the circle, and demand that their proofs
> must be right unless they can spot the error in the proof. While
> said mathematicians may end up being brusque dealing with such
> claims on sci.math, it doesn't change the fact that the
> mathematicians are right. (It's amsuing to see these folks claim
> that there must be a conspiracy to suppress their "wonderful"
> discovery --- and no, mathematicians aren't the only ones who get
> these kinds of claims. Physists get it all the time with perpetual
> motion machines.)

On the other hand, for days Larry was saying that my code was broken
because I measured larger variances than he did. After a few days of
this, combined with his abuse, I finally got two important results:

- I found variances in lmbench far higher than what Larry has ever
claimed
- I found that lmbench showed lower variances because it polluted the
FPU, which pushed up the median values for lmbench. This showed that
my code was not broken.

This showed that two points Larry was consistently flaming me for:

- my "broken" benchmark
- that large variances (30% or more) were impossible

turned out to be incorrect. Larry was wrong and I was right. Larry has
not apologised or even acknowledged these results.

So, on the basis of this, and Larry's abusive and aggressive behaviour,
I don't think he has an awful lot of credibility in this argument.

> He thinks it provides benefit, let him prove it. You and your fellow
> flamer feel it does not, then disprove it.
>
> Mr. Gooch is the one who has the burden of proof, since he's the one
> that wants to add the additional complexity to the kernel. He has
> been claiming that he has met this standard of proof. In the
> judgement of Larry, Victor, as well as myself, he has not.

I raised this point many times before, but for some reason it gets
overlooked. The change I'm proposing would simplify some code paths.

As for the "burden of proof" argument, let me point out that I *am*
working to provide hard numbers.

> In any case, we have more important fish to fry as we try to get the
> last of the polishing done before we release Linux 2.2. Can we put
> aside flames about whether we should be making changes to the Linux
> scheduler until after 2.2 goes out the door? Surely I hope most
> people agree this is not the time to add a destablizing change to
> the kernel!

I have no interest in a flamewar. I'd rather talk about the technical
issues. If people don't agree with me, that's fine. I just go away and
investigate some more, if appropriate.

Again, something else I've said again and again: I raised the separate
RT run queue as something to consider for 2.3. I don't know why people
keep implying I'm pushing for changes to 2.1.x. Not once have I
advocated that.

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/