Messages in this thread | | | Date | Thu, 24 Sep 1998 13:53:02 +1000 | From | Richard Gooch <> | Subject | Re: Interesting scheduling times |
| |
yodaiken@chelm.cs.nmt.edu writes: > On Thu, Sep 24, 1998 at 09:50:04AM +1000, Richard Gooch wrote: > > yodaiken@chelm.cs.nmt.edu writes: > > > On Sat, Sep 19, 1998 at 07:47:28AM +1000, Richard Gooch wrote: > > > > I'd agree with you if the heavily loaded system was just doing > > > > bog-standard time sharing. My concern is that if you are also trying > > > > to control an instrument at the same time, the schedule/wakeup times > > > > of the RT processes doesn't suffer because of the long run queue. > > > > > > The correct solution is RT-Linux or some variation, > > > not mucking up the Linux interactive scheduler. > > > > RT-Linux has it's own problems. > > I'm near tears here. But do you have a substantive point?
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/
| |