Hi, the following was in the PREEMPT_RT queue since last softirq rework. The result is that timer wake ups (hrtimer, timer_list) happens in hardirq processing them requires to wake ksoftirqd leading two: - ksoftirqd will consume all further softirqs. That means all soft interrupts that would be processed in the threaded interrupt will no be delayed to ksoftirqd. The threaded interrupt runs at higher priority than ksoftirqd. - ksoftirqd runs at SCHED_OTHER so it will compete for resources with all other tasks in the system, potentially delayed the processing further. The idea was to let the timers be processed by a dedicated thread running at low SCHED_FIFO priority. While looking at it again, it might make sense to have the pending_softirq flag per-thread to avoid threads with higher priority picking up softirqs from low-priority threads. This isn't yet a problem because adding softirqs for processing happens only from threaded interrupts. So the low-priority thread will wait until the high-priority thread is done. And the high-priority thread will PI-boost the low-priority thread until it is done. It would only make sense to make the flags per-thread once the BH lock is gone. The patch is limited to PREEMPT_RT. The ksoftirqd bullets from above apply also to !PREEMPT_RT +threadirqs. Would it make sense to restrict it to force_irqthreads() instead? Sebastian
