arch_in_rcu_eqs(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… arch_in_rcu_eqs(9) β€” the Kernel API Manual, bestie edition πŸŽ€

okay so welcome to arch_in_rcu_eqs(9), a page from the Kernel API Manual ✨ and honestly? it's giving "small function, huge responsibility" energy. it's a little arch-specific vibe check for RCU extended quiescent states, and we're gonna get into it 🫢


🌸 NAME 🌸

arch_in_rcu_eqs β€” an architecture-specific check for RCU extended quiescent states, no cap πŸ’…


✨ SYNOPSIS ✨

bool arch_in_rcu_eqs (void );

literally just that. one function, zero drama πŸ¦‹


πŸŽ€ ARGUMENTS πŸŽ€

  • void β€” no arguments, bestie. nothing goes in. it's a clean slate, main character energy only πŸ‘‘

⭐ RETURN ⭐

  • true if the CPU is potentially in an RCU EQS
  • false otherwise

that's it, that's the whole return contract πŸ“


πŸ’– DESCRIPTION πŸ’–

so here's the tea β˜• β€” architectures only need to define this if threads other than the idle thread may have an interruptible EQS. this does not need to handle idle threads. got it? good, write that down πŸ“

and the way that over-estimating is completely fine?? yesss β€” it's safe to over-estimate, it just costs you redundant RCU management work. so like, being a little extra is allowed here, you just pay for it in vibes (and CPU cycles) πŸ”₯

it's invoked from irqentry_enter β€” that's the call site, iykyk πŸ’«


πŸ‘‘ SEE ALSO πŸ‘‘

the kernel file that lives here: ./include/linux/irq-entry-common.h πŸ“‚

and the whole friend group, because this function is never alone:

like, the entire irqentry cinematic universe πŸŒˆπŸ’€ go read them, they ate πŸ’…


ngl bestie, if you're touching this one you're already deep in arch + irqentry territory β€” so like, respect, and also please be careful πŸ§šπŸ’œ

and that's the page!! source lives in ./include/linux and the timestamp on this bad boy is October 2026 β€” go off, you're officially educated on RCU EQS now πŸ”₯πŸ‘‘βœ¨

πŸ“¦ where this page comes from