Linux (or other *nix): Attaching an interrupt to userspace

Question

I'm trying to make sure that a unique user process executes as soon as possible after a particular hardware interrupt occurs.

One mechanism I'm aware of for doing this is to write a small kernel module that exports a device while sleeping inside the read handler. The module also registers an irq handler, which does nothing but wake the process. Then from the user's perspective, reads to that device block until the relevant interrupt occurs.

(1) On a modern CPU with a mainline kernel, can you reliably expect sub millisecond latency between the kernel seeing the interrupt and the user process regaining control with this?

(2) Are there any lower latency mechanisms on a mainline kernel?

Your approach seems to be OK. I am unsure about sub-milisecond latency, but it is probably reachable with "light" kernels (you can always test that on your machine). But reliability is a property of real-time systems. Non-RT OSes don't provide any garantees about response time. — Tsyvarev
for sub milisecond may be hard to achieve, but in any case you'll need RT patches rt.wiki.kernel.org/index.php/Main_Page — OznOg
Sorry, edited to clarify that I'm trying to understand how to get this latency down as low as possible on a non realtime oriented kernel. Are there any other tricks to that or is this the best that can be done? — Alex

Claudio Claudio · Accepted Answer · 2015-12-04T11:07:58

Apply the PREEMPT_RT patch to the kernel and compile it configuring full preemptability through make menuconfig.

This will allow you to have threaded interrupts (i.e., interrupt handlers executed as kernel threads). Then, you can assign maximum priority (i.e., RT prio > 50) to your specific interrupt handler (check its PID using ps aux) and to your specific process, and a lower priority to anything else.

Linux (or other *nix): Attaching an interrupt to userspace

1 Answers