I'm near tears here. But do you have a substantive point?
>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'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.
>
> Regards,
>
> Richard....
----------------------------------- Victor Yodaiken Department of Computer Science New Mexico Institute of Mining and Technology Socorro NM 87801 Homepage http://www.cs.nmt.edu/~yodaiken PowerPC Linux page http://linuxppc.cs.nmt.edu Real-Time Page http://rtlinux.org
- 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/