Keep in mind it doesn't magically wake up descheduled tasks. So it's necessary to go through the kernel if the destination task is not currently running on a CPU. The latency in that case will be similar to what we have today.<p>And in cases where you can guarantee that the destination task is running you can already uses shared memory for low-latency communication today (polling or mwait).<p>I'm not saying userspace interrupts are useless but they are not as convincing as it seems at first glance. I think more proof of concepts (enabling real applications) and benchmarking are needed to demonstrate the advantages.
AFAICT Intel has given up on supporting this in the kernel.<p>They've been silent about the patch since at least January 2023[0], and archived the repo for their kernel fork[1] in April.<p>It's a real shame because this kind of innovation seems valuable.<p>[0]: <a href="https://www.phoronix.com/news/Linux-SPR-Intel-User-Interrupts" rel="nofollow">https://www.phoronix.com/news/Linux-SPR-Intel-User-Interrupt...</a><p>[1]: <a href="https://github.com/intel/uintr-linux-kernel">https://github.com/intel/uintr-linux-kernel</a>
About the SENDUIPI instruction: <a href="https://www.felixcloutier.com/x86/senduipi" rel="nofollow">https://www.felixcloutier.com/x86/senduipi</a><p>It seems to require the kernel to set the IA32_UINTR_TT MSR before it does anything, so at least you can't send random IPIs to other processes from userspace.<p>I wonder about the cost of supporting these unused features in Intel chips. Will Intel keep including it forever even if no one adopts it? Drop it? (It is controlled by a CPUID feature flag so that is possible.)