The "normal" IPC that people are used to (message queues, semaphores
and so on) are not available in RT-Linux. I've been advocating people
here switch to Linux for their RT systems, and this is one of the
complaints they raised.
Another problem with RT-Linux is that an RT task is in fact a kernel
module. So you can't do fork/exec/setRT. It's running in a different
environment.
Don't get me wrong, I think RT-Linux is a good thing. I just think it
would be even better for standard Linux to be able to provide better
RT performance. It would certainly make my advocacy job easier ;-)
> >and the change I proposed would not
> > "muck up" the Linux scheduler. It's actually quite a simple change.
>
> If you are trying to control an instrument, you want hard RT
> response. But hard RT response is exactly what the Linux scheduler
> is not designed to provide. Note the terrible "RT" performance on
> VMS, Solaris and other OS's that try to mix RT and interactive
> scheduling. The reason for this problem is that they are trying to
> make the scheduler optimize two incompatible objectives. The reason
> that RTLinux works so well is that it lets Linux do its job and lets
> the RT subsystem work at a different plane.
I've been looking at the Linux scheduler code path, and it's actually
quite good. I haven't seen other OS's scheduler implementations, so I
don't know why they loose. Apart from run queue length issues, the
Linux scheduler works great.
If Linux were to have a separate run queue for RT tasks, I don't see
why that would slow down other aspects of the kernel.
> I'm not sure what the correct answer is for soft-rt tasks on
> Linux. They are indeed useful, but perhaps it is simpler for such a
> task to just increase the scheduling rate whenever it enters the
> runq.
That doesn't help the wake-up latency. I've said right from the start
that I want to get this latency down.
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/