On Thu, Jun 10, 2021 at 6:00 AM Nicolas Saenz Julienne <nsaenzju@xxxxxxxxxx> wrote: > PREEMPT_RT systems defer most irq_work handling into the timer softirq. > This softirq is only triggered when a timer is expired, which adds some > delay to the irq_work handling. It's a price PREEMPT_RT systems are > willing to pay in exchange for less IRQ noise. > > This works fine for the majority of systems, but there's a catch. What > if no timer is ever armed after an irq_work is queued. This has been > observed on nohz_full CPUs while running oslat. The lack of armed timers > prevents a pending irq_work to run. Which in turn prevents the nohz code > from fully stopping the tick. In https://lore.kernel.org/linux-rt-users/162093721042.5649.1489711837264906533.git-patchwork-notify@xxxxxxxxxx/T/#u, Jakub Kicinski noted: > Another thing while I have your attention - ____napi_schedule() does > __raise_softirq_irqoff() which AFAIU does not wake the ksoftirq thread. > On non-RT we get occasional NOHZ warnings when drivers schedule napi > from process context, but on RT this is even more of a problem, right? > ksoftirqd won't run until something else actually wakes it up? It seems to me that Nicolas Saenz Julienne's solution which raises the TIMER softirq might result in the same problem, as doing so might not wake ksoftirqd and result in local_softirq_pending but for TIMER rather than NET_RX. Is this correct? Why NET_RX softirq shows up as 08 in local_softirq_pending is itself a bit unclear. It appears to derive from __ARCH_IRQ_STAT, which means that 08 is NET_RX on x86_64 but perhaps not on other processors. Is this correct? The naive expectation that the number printed by the message is in keeping with softirq_to_name[] is any event obviously wrong. Thanks, Alison Chaiken Aurora Innovation
