User-Space Interrupts (2021)

Keep in mind it doesn&#x27;t magically wake up descheduled tasks. So it&#x27;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&#x27;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&#x27;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&#x27;s a real shame because this kind of innovation seems valuable.<p>[0]: <a href="https:&#x2F;&#x2F;www.phoronix.com&#x2F;news&#x2F;Linux-SPR-Intel-User-Interrupts" rel="nofollow">https:&#x2F;&#x2F;www.phoronix.com&#x2F;news&#x2F;Linux-SPR-Intel-User-Interrupt...</a><p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;intel&#x2F;uintr-linux-kernel">https:&#x2F;&#x2F;github.com&#x2F;intel&#x2F;uintr-linux-kernel</a>

About the SENDUIPI instruction: <a href="https:&#x2F;&#x2F;www.felixcloutier.com&#x2F;x86&#x2F;senduipi" rel="nofollow">https:&#x2F;&#x2F;www.felixcloutier.com&#x2F;x86&#x2F;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&#x27;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.)