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. 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 the forced threaded case. v2…v3 https://lore.kernel.org/all/20241024150413.518862-1-bigeasy@xxxxxxxxxxxxx/ - Redo the comment in interrupt.h. Make it more verbose and add more details. Frederick asked for it. - After updating the comment I convinced myself that it also makes sense to use this in the forced threaded case. - Merged raise_hrtimer_softirq() and raise_timer_softirq() into a single function since both use __raise_softirq_irqoff() in the alternative case. v1…v2 https://lore.kernel.org/all/20241004103842.131014-1-bigeasy@xxxxxxxxxxxxx/ Frederick's comments: - Use __raise_softirq_irqoff() to raise the softirq for !PREEMPT_RT. Also a lockdep test to ensure that this is always invoked from an IRQ. - Make raise_ktimers_thread() only OR the flag and nothing else to align with __raise_softirq_irqoff(). The wake happens on return from interrupt anyway. - A comment in timersd_setup() and interrupt.h - local_pending_timers() => local_timers_pending(). Sebastian
