And now that I hope I believe I understand the process adequately I have a suggestion.
Why not unify the CPU hotplug and "dyntick suspend" status tracking by using the same counter as dyntick for both?
If the CPU offline / online advanced the (now renamed rcu_cpu_awake ( with the LBS matching CPU state)) counter, the even / odd state will satisfy both scenarios.
And I am not advocating this solely for the purpose of reducing the state variables and reducing code (if not complexity):
Conceptually, an offline CPU (a powered down engine which cannot receive interrupts ) is equivalent to a dyntick CPU (powered down state) that receives no interrupts in the grace period.
I realize there are, of course, other reasons to track online/offline CPUs, that the offline check is immediately available.
However, the unification would allow a simpler "no off line" option to the this intended "dyntick replacement" to CLASSIC RCU.
And a simpler "no NO_HZ" option that would be useful for virtual CPUs.
I know - "show me the code!".
OK reading your posts
"v6 scalable classic RCU implementation" "Tue, 23 Sep 2008 16:53:40 -0700"
indicate the magnitude of code that is present to handle a CPU offline activity.
Concerns like moving outstanding rcu work from the "forced" offline CPU to the current CPU, make the offlining distinct.
However, it appears to be performed (at least in this version of the code) just before sending the tardy CPUs the IPI reschedule. Which, back to the schematic, makes it part of the "GP too long" path?
And reading your further post "rcu-state" "Mon, 27 Oct 2008 20:52:01 +0100"
It looks like this version is using a unifying indicator "rcu_cpumode" - still with 2 distinct substates, that are separate from RCU_CPUMODE_PERIODIC which requires the notifications each Grace Period.