Paul Barton-Davis writes:
> >What you are not reading/hearing/understanding is that your
> >requirement for "scheduler real time response guarantees" has far
> >reaching implications into the other subsystems that you keep
> >insisting aren't important to you. What you don't seem to realize is
> >that the scheduler is just fine, it just isn't getting called when
> >you want it to get called.
>
> I realize this perfectly well. Thanks for the OS101, Larry.
>From the way you've been arguing, this wasn't clear.
> > In order to make it get called, each and
> >*every* one of those subsystems that you keep saying aren't important
> >are going to have to be modified so that they call the scheduler when
> >you want it to be called. Doing that is part of (a *big* part of)
> >what needs to be done to make an OS have RT behaviour.
>
> OK, I am quite willing to listen to this POV. I am more than willing
> to believe it. I just want to see enough people say that this is
> true so that there is no reasonable room for doubt.
A vote?!?
> I respect your views on this, but they are not the only ones. If the
> bulk of the seasoned kernel developers all agree that getting the
> scheduling response to occur withing XXXusecs involves deep fixes on
> all the subsystems, thats fine. I will accept that it can't be done
> cleanly at this time, and we'll have to maintain a parallel version
> of a patch that just uses preemption points "all over the place".
So far, I've not seen any core developers coming out in favour of
this. Even Ingo stated much of the low-latency code/ideas weren't a
good idea.
> Thats not an ideal solution for people doing real-time audio+MIDI,
> but like you, I'd rather not see Linux cluttered and botched with
> stupid solutions. I just want to know for sure that the preemption
> point approach is "stupid". Or whatever.
So what will convince you? Is it up to Larry to extract statements
from the top 10 developers that it's a bad idea? Or, is it up to you
to extract statements (at least one) that it's a good idea?
> The only thing that bothers me about this is that I fear that it
> will relieve some of the pressure on the mainstream kernel to pay
> attention to this stuff. But that may be ungrounded: Linus has said
> himself that he is interested in improving latency performance. If
> this letter and the responses do nothing else except make that issue
> a big more high profile, it will have served some purpose.
Linus has shown he's receptive to patches that make sense in a broader
context and are clearly correct/worthwhile, even if a bit "tasteless".
I wouldn't worry about the mainstream kernel getting slower due to an
"easy" option of using RTLinux. It seems to me the kernel keeps
getting faster in many areas. Kernel hackers are speed freaks. It's a
matter of pride to keep the kernel fast (yet still elegant).
Remember that keeping reasonable control over latencies is good for
the general case as well. So these issues won't be ignored.
> >The really frustrating part is that you keep implying that it is just a few
> >changes here and there and 100% of the prior work in the field says that
> >you are completely wrong.
>
> Not 100%. We have at least two other OS's (IRIX and BeOS) that don't
> constitute RTOS's, and yet have roughly the desired scheduling
> characteristics. The fact that you hate IRIX is useful information,
> but doesn't invalidate the point that a totally preemptive kernel
> represents another approach to this problem.
The issue is not whether IRIX is preemtive or not. The issue is the
cost of that preemption.
> You then say that as long as "it works 99% of
> >the time" you are happy, which is also complete nonsense. As soon as it
> >works 99% of the time, you'll be back to say "we are so bloody close to
> >be perfect, can we add a few more ``small changes'' to get the last 1%".
>
> I would be happier if you didn't try to second guess my behaviour.
You or someone else. Doesn't matter who. I simply don't believe that
once we have 99% "perfection", some people won't start clamouring for
the last 1%. I can imagine some mis-guided vendor cracking under the
pressure and forking the kernel, because "it's now so easy to get that
last 1%" (even though it won't be).
> I am also *flabbergasted* that the guy I think of as most
> responsible for serious benchmarking of Linux, and someone who I
> think of as tending to insist on actually measuring things rather
> than working with subjective assessments, is ready to jump on a
> couple of reports that "BeOS feels slower than it used to". If
> somebody said that about Linux and it got taken up as evidence of
> what was going on with our kernel, you'd be all over them in an
> instant with a variety of very legitimate questions and points. BeOS
> *may* be getting slower, I don't know that since I don't use it.
Well, from what I've noticed of Larry's debating style, he probably
figures since you're the one wanting to make a change, it's up to you
to demonstrate why it's justified and measure what the costs are.
The position of do nothing requires no justification. Yes, that can be
frustrating, but that seems to be how things work around here. I've
seen it from both sides :-/
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:09 EST