Messages in this thread | | | From | (Larry McVoy) | Subject | Re: Interesting scheduling times - NOT | Date | Thu, 24 Sep 1998 23:51:40 -0600 |
| |
Richard Gooch <rgooch@atnf.csiro.au>: : IIRC over 50 man-years has already been put into this project. It is : far too late to change something this fundamental to the design.
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/
| |