Paul, "Paul E. McKenney" <[email protected]> writes: > On Thu, Aug 06, 2020 at 01:45:45PM +0200, [email protected] wrote: >> The safety thing is concerned with RT tasks. It doesn't pretend to help >> with runnaway IRQs, never has, never will. > > Getting into the time machine back to the 1990s... > > DYNIX/ptx had a discretionary mechanism to deal with excessive interrupts. > There was a function that long-running interrupt handlers were supposed > to call periodically that would return false if the system felt that > the CPU had done enough interrupts for the time being. In that case, > the interrupt handler was supposed to schedule itself for a later time, > but leave the interrupt unacknowledged in order to prevent retriggering > in the meantime. > > Of course, this mechanism would be rather less helpful in Linux. > > For one, Linux has way more device drivers and way more oddball devices. > In contrast, the few devices that DYNIX/ptx supported were carefully > selected, and the selection criteria included being able to put up > with this sort of thing. Also, the fact that there was but a handful > of device drivers meant that changes like this could be more easily > propagated through all drivers.
We could do that completely at the core interrupt handling level. > Also, Linux supports way more workloads. In contrast, DYNIX/ptx could > pick a small percentage of each CPU that would be permitted to be used > by hardware interrupt handlers. As in there are probably Linux workloads > that run >90% of some poor CPU within hardware interrupt handlers. Yet another tunable. /me runs
