rcu_softirq_qs_periodic(9)

📦 version 7.3.1, in nixpkgs unstable

💅 rcu_softirq_qs_periodic(9) — a Kernel API Manual moment

okay bestie, so this one's from the Kernel API Manual, and it's literally the glow-up your long-running softirq handler has been waiting for ✨

🌸 NAME 🌸

rcu_softirq_qs_periodic — reports RCU and RCU-Tasks quiescent states 💖

🎀 SYNOPSIS 🎀

rcu_softirq_qs_periodic (old_ts );

🦋 ARGUMENTS 🦋

  • old_ts — the jiffies at the start of processing. that's it, that's the vibe 🫶

⭐ DESCRIPTION ⭐

so this helper is specifically for long-running softirq handlers, like NAPI threads in networking — the ones that just keep going and going 🌀 the caller should initialize the variable passed in as old_ts at the beginning of the softirq handler, no cap. then, when it gets invoked frequently, this macro will invoke rcu_softirq_qs every 100 milliseconds thereafter, which hands you both RCU and RCU-Tasks quiescent states. iconic behavior honestly 👑

⚠️ heads up: this macro modifies its old_ts argument. so don't be out here assuming it's gonna stay the same value, because it will not 💀

because regions of code that have disabled softirq act as RCU read-side critical sections, this macro should be invoked with softirq (and preemption) enabled. like, that's the whole vibe check it needs to pass ✅

the macro is not needed when CONFIG_PREEMPT_RT is defined 🙅‍♀️ RT kernels would have more chance to invoke schedule calls and provide the necessary quiescent states, so they're already covered. as a contrast, calling cond_resched only won't achieve the same effect — because cond_resched does not provide RCU-Tasks quiescent states. ngl that's kind of the whole point of the distinction 🔥

🌈 SEE ALSO 🌈

kernel file ./include/linux/rcupdate.h plus this absolute squad of related calls, fr fr:

and that's the whole page, bestie 🧚 this one lives in ./include/linux and it's dated October 2026 — so like, future vibes only 💜 mwah, go forth and report those quiescent states 💅✨

📦 where this page comes from