4 ms·
You need CPU time to evaluate the priority of the event. This can't happen until after you've interrupted whatever process is currently on the CPU. And so the h
by btilly 2y ago
You need CPU time to evaluate the priority of the event. This can't happen until after you've interrupted whatever process is currently on the CPU. And so the highest possible priority an event can happen is limited by how short a time slice a program gets before it has to go through a context switch.
To stand ready to reliably respond to any one kind of event with low latency, every CPU intensive program must suffer a performance penalty all the time. And this is true no matter how rare those events may be.
- zeusk 2y agoThat is not true of quite a few multi-core systems. A lot of them, especially those that really care about performance will strap all interrupts to core 0 and only interrupt other cores via IPI when necessary.
- xedrac 2y agoI learned this when I pegged core 0 with an intensive process on a little quad core arm device, and all of my interrupts started behaving erratically.
- btilly 2y agoThis strategy minimizes the impact by making one core less necessary. But it does not eliminate it.
- zeusk 2y agoSure which is a perfectly fine trade off; almost all recent CPUs have enough multicore capacity that make this trade favorable.
- Someone 2y ago> You need CPU time to evaluate the priority of the event. Not necessarily. The CPU can do it in hardware. As a simple example, the 6502 had separate “interrupt request” (IRQ) and “non-maskable interrupts (NMI) pins, supporting two interrupt levels. The former could be disabled; the latter could not. A programmable interrupt controller (https://en.wikipedia.org/wiki/Programmable_interrupt_controller https://en.wikipedia.org/wiki/Programmable_interrupt_control...) also could ‘know’ that it need not immediately handle some interrupts.
- themulticaster 2y agoThe user you replied to likely means something different: The priority of the event often depends on the exact contents on the event and not the hardware event source. For example, say you receive a "read request completed" interrupt from a storage device. The kernel now needs to pass on the data to the process which originally requested it. In order to know how urgent the original request and thus the handling of the interrupt is, the kernel needs to check which sector was read and associate it with a process. Merely knowing that it came from a specific storage device is not sufficient. By the way, NMI still exist on x86 to this day, but AFAIK they're only used for serious machine-level issues and watchdog timeouts.
- wizzwizz4 2y agoThis, too, can be done in hardware (if nothing else, with a small coprocessor).
- refulgentis 2y agoThis doesn't shed light Generally, any given software can be done in hardware. Specifically, we could attach small custom coprocessors to everything for the Linux kernel, and Linux could require them to do any sort of multitasking. In practice, software allows us to customize these things and upgrade them and change them without tightly coupling us to a specific kernel and hardware design.
- wizzwizz4 2y agoWe already have specialised hardware for register mapping (which could be done in software, by the compiler, but generally isn't) and resolving instruction dependency graphs (which again, could be done by a compiler). Mapping interrupts to a hardware priority level feels like the same sort of task, to me.
- sroussey 2y ago> We already have specialised hardware for register mapping (which could be done in software, by the compiler, but generally isn't) Wait, what? I’ve been out of compiler design for a couple decades, but that definitely used to be a thing.
- amluto 2y agoLinux runs actual C code when an event occurs — this is how it queues up a wake up of the target task and optionally triggers preemption.