>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.
> 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.
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".
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.
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.
>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.
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.
>And I notice that you are neatly avoiding addressing someone else's point
>that BeOS used to be really zippy and is slowing down over time. Why is
>that, do you suppose? Could it be all the grot they have to do to get
>that realtime performance? Nahhhhhhh.
The problem here is that I have a source inside BeOS who doesn't want
to be part of this discussion. That source doesn't agree in any way
with your characterization of what is going on with their OS, either
in terms of its visible performance characteristics, or whats
happening with the code. Who should I believe ?
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.
--p
-
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