synchronize_rcu_expedited(9)

💅 synchronize_rcu_expedited(9) 💅

okay bestie, welcome to the Kernel API Manual page for synchronize_rcu_expedited(9) — this one is giving “brute-force grace period” energy, and we’re gonna get into it ✨

---

🌸 NAME 🌸

• synchronize_rcu_expedited — Brute-force RCU grace period 🫶

---

🦋 SYNOPSIS 🦋

void synchronize_rcu_expedited (void );

---

💅 ARGUMENTS 💅

• void — no arguments. Zero. Nada. It takes no arguments, periodt 💀

---

🔥 DESCRIPTION 🔥

So the whole vibe is: wait for an RCU grace period, but expedite it. The basic idea is to IPI all non-idle non-nohz online CPUs. The IPI handler checks whether the CPU is in an RCU critical section, and if so, it sets a flag that causes the outermost rcu_read_unlock to report the quiescent state for RCU-preempt or asks the scheduler for help for RCU-sched. On the other hand, if the CPU is not in an RCU read-side critical section, the IPI handler reports the quiescent state immediately 👑

And like, yes, this is a great improvement over previous expedited implementations. But it is still unfriendly to real-time workloads, so it is thus not recommended for any sort of common-case code. In fact, if you are using synchronize_rcu_expedited in a loop, please restructure your code to batch your updates, and then use a single synchronize_rcu instead 🙈

bestie, this has the same semantics as (but is more brutal than) synchronize_rcu. Not me warning you dramatically, but also yes, literally warning you dramatically 💀

---

👑 SEE ALSO 👑

• Kernel file: ./kernel/rcu/tree_exp.h
• start_poll_synchronize_rcu_expedited(9)
• start_poll_synchronize_rcu_expedited_full(9)
• cond_synchronize_rcu_expedited(9)
• cond_synchronize_rcu_expedited_full(9)

---

okay that’s the page, bestie 💖 cute little sign-off: source/version is ./kernel/rcu, dated October 2026, for synchronize_rcu_expedited(9) — mwah 💋