Andre Hedrick writes:
> On Mon, 3 Jul 2000, Richard Gooch wrote:
>
> > Let me point out a couple of examples which show just how difficult
> > this "fast scheduling" business is, and why we should leave these
> > things to RTLinux instead:
> >
> > - some (broken) motherboard/IDE chipsets will lock up hard if you take
> > another interrupt while servicing the IDE interrupt. Hence, the
> > default IDE driver does/did disable IRQs in its interrupt
> > handler. This doesn't just foul up process latencies, it can kill
>
> You then walk away form onboard host and use the three offboards that can
> now parse interrupts. The chipsets allow quick test and get out if it is
> not our interrupt.
And if it is our interrupt, we have to spend time servicing it. Even
with the best busmaster DMA, we have to spend time walking buffer
lists, locking (waiting!) and unlocking, moving list pointers around
and stuff like that. During this time:
- other interrupts may be disabled (to cope with broken hardware)
- rescheduling is prevented (no way around that).
Sure, with good hardware, we don't have to disable interrupts in our
ISR. But since there are people running broken hardware, we have to be
conservative by default. Because Linux is a general-purpose OS.
RTLinux doesn't have to be conservative this way. It doesn't have to
work around broken hardware ("Oh, it hangs? Go use decent hardware").
This is a key point I'm finding difficult to get across.
And RTLinux can also keep rescheduling RT tasks, which is important
even if you have decent hardware.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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:16 EST