You know, I've heard that a lot before and yet when the app doesn't
perform the way people want it to perform, somehow they magically discover
that it is possible to change it.
: There are a few things in Linux which would prevent a happy
: co-existence between an RT application and this data reduction
: application. One of those things is run queue length costs in RT
: wakeup latencies. That is what I'm addressing at the moment.
Have you ever considered that maybe you're worrying about a problem that
doesn't exist? In all of this fuss, you've never started out by saying
"we have throughput problems" or "we are dropping events because we can't
respond fast enough". Instead, it's all "I think this is going to be
too slow and here's some (questionable) numbers which show how slow".
When I've asked you to code up your simple change and test your system,
you have refused. Why? Wouldn't the easiest thing be to show that
your application can actually see some difference from these changes
that you are making such a fuss over? When David pointed out that he
had already tried all this and it made no difference, wouldn't that be
a good time to show up with your application data that shows that your
changes do indeed make a difference?
You're spending a lot of time arguing about a benchmark and you have the
real benchmark (the app) at your finger tips. So measure the effect of
your proposed change. I'll happily agree with you when you can show
that it indeed makes so much as a 10% difference to your application's
throughput or event rate.
: I think you need the focus. The variance is pointing to something
: interesting/unexpected going on. Should I consider lmbench results
: meaningless too, because they also yield variance?
Yup, if I showed up and said "let's change the scheduler, I think it is
broken and lmbench proves it" and lmbench actually varies more than than
the magnitude of the change in the scheduler, you bet you should ignore
lmbench results. The difference here is that I'm not trying to change
the scheduler (I did that years ago when it needed it). If I had what you
saw as flawed reasoning for changing the scheduler, it would be completely
reasonable for you to say "Hey, Larry, that benchmark is broken - it varys
2 usecs and you are trying to measure a .2 usec change, that's nuts".
: > 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.
:
: It will add a small amount of code in a couple of places and will
: simplify the code in other places.
That's great, I love it. Except you haven't shown that it makes a
difference to any application other than a benchmark (yours, mine,
whatever, they are still benchmarks and applications are what count).
: This is a list where people can and should discuss ideas and put forth
: results. This is also a place where people can (and many times have)
: presented a problem or a result and asked for help. Asking is not
: demanding. I didn't put my results up and say "I require people to
: analyse my code".
No, you put up your results and said "we need to change the scheduler".
And I said "Not based on those results, we don't".
: I'll say it again. Maybe it will eventually penetrate: I don't mind if
: you disagree with me. Just keep it polite and respectful.
OK, Richard. I disagree with your assessment that the scheduler is
a problem. I think your benchmark varies too much to be used as a
justification for changing the scheduler. I think that your benchmark
wouldn't be a justification for changing the scheduler even if it didn't
vary at all. I think the only justification for improving the scheduler
is to show that (a) there are important applications which would benefit
from said change, and (b) said change does not hurt any other applications
or system performance, reliability or maintainability. I respectfully
suggest that you stop worrying about your benchmark, or my benchmark, or
any benchmark, until you can show that your application will actually
benefit from the changes you suggest. At that point. having an accurate
benchmark which can quantify the change would be most helpful.
: No, your position makes no sense. Your problem is:
[I'm just a worthless jerk]
I'm sure you missed quite a few of my other flaws. I fart too much,
I sometimes chew with my mouth open, I waste too much time arguing with
people that don't listen, I'm too thin, my hair's too long, etc.
I'd love to spend more time discussing my flaws, I'm sure you have more
valuable insights, but this isn't the discuss-larry alias.
: > : 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.
:
: Ultimately, yes. But until the problem cause(s) is exposed, it remains
: unexplained.
Not ultimately, before you use those results as a basis for changing a
fundemental part of the operating system. That, Richard, is the whole
problem. You have no evidence that these changes are needed, you have
a benchmark that is pretty useless for measuring these changes, and yet
you insist that the kernel gets changed. No, no, no, no. That's not
engineering, that's voodoo.
: I have not told you to go away because you disagree. I've told you to
: stop the mantra that by benchmark is "broken" simply because I've
Richard, focus on the point. I don't care if your benchmark works or not
until you use it as justification for a change to an important part of
the operating system. At that point, you need to have rock solid results
and evidence that those results have some bearing on the real world.
As far as I can see, you have neither. You keep insisting that the
kernel should change and I keep telling you "not based on that broken
benchmark". Then you say "well you're benchmark is almost as broken".
Yeah, so what if it is? I'm not using it to try and make this sort of
change to the kernel.
In fact, if you shoed up with lmbench results that varied 30% (or about
2 usecs) and tried to use them to justify a change that made a .2 usec
difference, I'd say exactly what I have been saying all along: those
benchmark results are useless for the purpose of justifying this change.
I'm not saying that you don't have a point. You could be absolutely
right. You just haven't proved it. You could easily do so by making
your change and showing the substantial difference this makes to your
application. If you do that, you'll find that I am very supportive of
your work.
-
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/