Yes.
: There are at least two separate discussions going on here. One is
: about the cost of extra processes on the run queue. I've demonstrated
: similar numbers for this with lmbench and my code. It see we have
: provisional agreement on this cost. The discussion now is whether the
: cost is significant.
Which has been my other point all along. I don't think you have a
system that is well tuned enough that you are going to notice the extra
2us per context switch. And if you do have such a system, I claim that
the author of that system could trivially modify the application to get
rid of that overhead.
: The other discussion regards the variance I have measured. Here you
: persist in saying my test is flawed, and yet so far not a single one
: of your suggestions as to why it may be flawed has stood up to the
: test.
Yo, Richard. Go back and find a posting that starts out "Hmm, I've
debugged Richard's code and here's why it varies". You won't because
there isn't one. I'm not saying I know what the cause of your problems
is and I don't really care what the cause of your problems is. I am
saying that your benchmark results are meaningless given the variance
and no explanation of the variance. That's all. Focus.
: Now, I agree in principle that you should fix broken applications
: rather than fix the OS. But it doesn't always work this way.
Yes it does. That's the difference between Linux and BloatOS. We don't
have to cater to your application, you aren't paying us to do so.
So unless you can prove that it is worthwhile to add more code to the
kernel, it doesn't happen.
: No, I'm not asking you to debug it. All I ask is that you don't feel
: like being constructive, at least don't be destructive. Constructive
: criticism is welcome. Finger pointing, abuse and agression are not.
Come on, Richard. Do you want there to be no standards for kernel hackers?
What do you suggest we do when people show up with no experience and want
to check in their favorite thing to the kernel? I'm sorry, but the answer
isn't "that's nice, have fun". If you can't stand the heat...
You have one fatal flaw in your logic: you think my arguments are not
constructive because they aren't helping /you/. I could care less about
you, you aren't the point. This isn't the richard-gooch-helpers list,
this is the linux-kernel list. The focus here is what is good for the
linux kernel, not anything else. Think about that and reconsider my
position - makes a little more sense, no?
: Unexpected results don't automatically invalidate the results.
s/Unexpect/Unexpect and unexplained/ and the statement is absolutely correct
in the engineering world. You have to be able to explain your results.
: I want to expose the problem and track it down.
Great! That's what I've been asking you to do since message #1. So go do
it.
: BTW: your comment about "deferring" betrays an underlying arrogance.
Nah, it shows that I think I've done a hell of lot more homework than you
have.
: So, if you're not willing to be constructive, or willing to admit that
: your code may be flawed because it's *insensitive* to the effect(s),
: just go away and let me get on with tracking down the problem.
Richard, it's you that insists on having this public argument and
debugging session. When Linus tried to take it private, and I concurred,
you dragged it out on the list again. If you want to have a public
argument, you aren't going to get anywhere by telling people that
disagree with you to go away. You're going to get somewhere by doing
your homework and showing us the right answer. I'm sure you can do it,
you're smart, so go do it.
-
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/