Alan pointed out problems with that. Also, consider that there is an
installed base of hardware which isn't going to be replaced anytime
soon. At least not here. The way this place works is that funding for
purchasses and funding for personnel is quite separate, so funding the
effort to fit an application into available hardware is easier than
buying the hardware to fit the application.
I've hit my head against this brick wall more times than I care to
think about. It's fustrating, but it's life.
> : I don't claim to have all the answers. I have a number of ideas that
> : I'd like to test. The main claim I make is that I don't think it's
> : obvious which approach will be the best. At least I'm willing to code
> : something and test it. That seems more constructive than persistently
> : poo-pooing ideas
>
> Richard, it isn't the ideas that are the problem, it's the premise
> behind them. I want you to get a solution that makes you happy, I
> just don't want it at the expense of the generic kernel. A few
> points to consider:
Why do you keep saying that it's at the expense of the generic kernel?
I've explained time and time again how the current code (all that
special-casing for the RT scheduling class) is complex and fragile,
but you never respond directly to these points.
My changes are cost neutral at worst and improve the quality of the
scheduler code.
> 1) We don't know if there is a problem. You yourself have said that
> you just think there might be a problem and you want to "fix" it.
> That's cool, but given that you haven't defined what you are
> "fixing", it's sort of hard to justify the changes. Removing
> cache misses in a benchmark test case is a poor justification.
I've raised a number of points. It's all there in the document I wrote
last year: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html
and the mail archives.
> 2) The whole soft-RT stuff. I'd be a lot more supportive of your
> efforts if it sounded like you understood the tension between
> time sharing and RT. Can you explain why RT is not typically
> found in time sharing OS's, the goals of each design, why they
> conflict, etc. If you understood all that (maybe you do, but it
> sure doesn't sound like it from your postings) and /then/
> proposed your changes and explained how they actually made sense
> in spite of the time sharing/RT problem, that would be far more
> warmly received. At least by me.
Well, I do understand the issues, but I'm not going to waste my time
sitting your exam. If you look through the mail archives you can even
see where I've talked about the advantage of RT and non-RT scheduling
classes in a *single* application which is the only thing running on
the system. The clock application I mentioned is one example of it.
So don't present this as though I'm trying to push for RT applications
running perfectly on a time-sharing system. Even where I *have*
pointed out the benefits to a separate RT run queue for systems
sharing RT applications and normal user processes, I've taken pains to
mention that there are many other problems which have a greater effect
on latency.
When I say "this would help shared RT/normal systems", you should not
take that to mean "this will solve problems sharing RT and normal
jobs", nor even "this will solve the biggest problem...". I've even
said in the past that, in the context of sharing RT and normal jobs, a
separate RT run queue is one of the smaller issues.
But there are other issues, which is why I think it's worth
considering. Even the simple fact that it simplifies the scheduler
code and makes it less fragile is in my view sufficient justification,
even if there were no performance benefits at all.
> 3) Linux/RT. I really wish that you would get your friends to use
> this. If you need help with this, I'll beat on Viktor to help
> you. Did you know there is a company which produes a Linux/RT
> CD? Have you tried it? Have you worked as hard at solving your
Getting hold of RT-Linux is not a problem. They don't need a CD.
> problems in that space as you have worked on other approaches?
> If not, why not? Is Viktor being unresponsive? We'll fix that.
> Is there some feature that you need in the RT kernel that isn't
> there? Spec it, I'll find someone to do it. It would be so nice
> if you looked at this solution space in depth. It's a really
> elegant solution and keeps the RT stuff, that 99.99% of the users
> will never use, out of the kernel. I'd really like you to
> balance your proposed changes with the need - that's a tradition
> in Linux, and it is a good one. The road of operating systems is
> littered with carcasses of examples where people forgot that
> balance and ended up with and OS that suited noone.
I have no problem with the RT-Linux concept. I've said before I think
it's a fine idea. The reaction I've received from people is that it's
an incomplete programming environment (i.e. lack of semaphores). I've
actually argued against them on some of these issues, pointing out
that they could just use the RT pipes as a synchronisation
method. Remember I'm talking to people who aren't used to the Unix
way, so I've had to explain the Unix philosophy. It's hard work
convincing someone that a "missing feature" doesn't mean an OS is
lacking but rather that they've got the wrong mindset.
Where I do agree with the criticisms is that using RT-Linux is hard,
because it doesn't fit seamlessly into the Linux/Unix programming
environment. You can't take standard POSIX RT code and have the POSIX
RT threads be RT-Linux threads. You have to stuff around with loading
modules and separating your code into co-routines: separate
programmes. I'd like to see this changed.
Ideally, a thread could ask to become an RT-Linux thread (using
sched_setscheduler()). I acknowledge this is hard to achieve, but it's
what would make using RT-Linux so much easier. This is important for
people who have a certain reluctance in the first place. [*]
> I'm serious about being willing to help you if you are willing to
> explore other alternatives. I agree that the RT kernel that Viktor
> has isn't as rich a programming environment as the generic kernel.
> So lets fix that. Lets understand what it would take to solve your
> problem and beat on the Linux/RT folks to be responsive to your
> needs. If we can't get them to help you, then you have a really
> strong case for fixing your stuff in the generic kernel. But please
> give them a chance first.
Well, I've given some of my suggestions. Lets take that further. The
changes I proposed to the standard Linux scheduler do 2 things:
- improve RT performance by isolating the run queues
- improve robustness and maintainability of the code by
simplification.
If we ignore the first issue and just look at the second, let me
propose a perhaps radical idea: we *remove* SCHED_FIFO and SCHED_RR
from the standard Linux scheduler. This would also simplify the
scheduler, making it faster and more robust. All that special-casing
for POSIX RT would be removed.
Of course, we have to support the POSIX RT scheduling classes, so just
removing them isn't really an option. But suppose instead my (perhaps
unrealistic) idea mentioned above (*) was implemented so that a thread
which asked for RT scheduling got *real* RT? Now that would be nice.
Before you flame me, I'll say that I haven't thought out the problems
with implementing this. Take it is as a "wouldn't it be neat if...".
Assuming the above idea is dumb, please address the issue of the
current complexity and fragility of the standard scheduler. If there's
to be any hope of a productive debate, this issue needs to be
addressed.
I would be apprehensive in pushing a patch that added a separate RT
run queue *if it added complexity to the current code*, for the very
same reasons you have. I agree with the principle of reducing kernel
bloat (although it shouldn't be a straight-jacket). But my patch
*simplifies* the scheduler. This is why Linus was positive about it in
the first place, I believe. The patch just makes things so much
cleaner.
If you prefer the current complexity, at least explain *why*.
Regards,
Richard....
-
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/