用户态驱动下UIO中断的可靠有序处理方案问询

Great question—this is a common pain point when dealing with high-frequency UIO interrupts, especially with the default CFS scheduler that can introduce variable wakeup latency leading to batched interrupt events. Let’s break down the solutions, alternatives, and whether this is an inherent limitation of non-realtime Linux.

Why poll/select/epoll Can’t Give Interrupt Order #

First, it’s important to clarify: the core issue isn’t CFS itself—it’s the design of poll-style APIs. These interfaces only tell you which file descriptors are "ready" (i.e., have pending interrupts), not the order in which those interrupts occurred. The ready set is constructed based on the order of your input fds, not the timing of the underlying events. Even with a realtime scheduler, poll/select/epoll still won’t expose event sequencing—they’re simply not built for that.

Reliable Ways to Process UIO Interrupts in Order #

If you need strict ordering, you have two primary paths to solve this, depending on whether you can modify the UIO kernel driver:

1. Kernel-Side Event Timestamping & Ring Buffers (Best for High Frequency) #

If you control the UIO driver’s kernel code, add a shared memory ring buffer that records every interrupt event with a high-resolution timestamp (use ktime_get_real_ns() or similar) and any relevant metadata (like interrupt source ID).

• Map this ring buffer into user space using the UIO framework’s memory mapping mechanism (via /dev/uioX).
• When your user-space process is woken by poll, instead of just acknowledging the interrupt, read the entire ring buffer to pull all pending events.
• Sort these events by their timestamps (or rely on the ring buffer’s FIFO order, if you write events sequentially) before processing.

This approach is the most reliable because it captures interrupt order at the source, before any scheduling delays can scramble things. Even if CFS delays your process, the kernel is still recording events in the correct order.

2. User-Space Batch Reading & Sorting (No Kernel Modifications) #

If you can’t modify the kernel driver, you can work around this by:

• After poll returns, repeatedly read the UIO device (e.g., read /dev/uioX to get interrupt counts or event data) until no new data is available.
• For each read operation, record a user-space timestamp (use clock_gettime(CLOCK_MONOTONIC, ...) for accuracy) alongside the interrupt data.
• Sort the collected events by their timestamps before processing.

Note: This is less ideal than the kernel-side method because user-space timestamps are taken after the interrupt has already been processed by the kernel, but it’s a viable workaround if kernel changes aren’t an option. Just be aware that if interrupts are extremely frequent, you might still miss some granularity (but UIO should buffer pending interrupts for you).

Better Alternative APIs #

Poll-style APIs aren’t the only game in town. Here’s what else you can use:

io_uring #

io_uring is a modern I/O interface that can provide more granular event ordering compared to poll. Instead of using poll to wait for readiness, you can submit multiple asynchronous read operations to your UIO devices. The Completion Queue Entries (CQEs) returned by io_uring will be ordered based on when the read operations completed—which corresponds to when the interrupts were processed by the kernel.

This avoids the "batch ready set" problem of poll, as each interrupt triggers a separate completion event. Just make sure you configure io_uring with sufficient queue depth to handle your interrupt frequency.

Avoid signalfd #

You might be tempted to use signalfd with UIO’s signal-based interrupt notification (via /sys/class/uio/uioX/irq/signal), but this is not reliable for ordering. The kernel can merge multiple identical signals, so you’ll lose count of individual interrupts and have no way to determine their order.

Is This an Inherent Limitation of Non-Realtime Linux? #

No—this is not a limitation specific to CFS or non-realtime kernels. Even with a realtime scheduler (like SCHED_FIFO or SCHED_RR), poll/select/epoll still won’t expose interrupt order. The realtime scheduler only reduces the latency between interrupt occurrence and your process being woken, which can reduce the number of batched events—but it doesn’t change how poll-style APIs report readiness.

The core limitation is the design of those legacy I/O interfaces, which prioritize telling you what is ready over when events happened.

内容的提问来源于stack exchange，提问作者Woodrow Barlow