Re: [PATCH v2 2/3] xen/rcu: simplify RCU implementation

["Alejandro Vallejo" <alejandro.garciavallejo@amd.com>]

On Fri Sep 25, 2026 at 6:30 PM CEST, Roger Pau Monne wrote:
> The current implementation has two shortcomings for certain Xen usages:
>
>  * When using the null scheduler it's possible for a CPU to never enter Xen
>    context.  A CPU not entering Xen context can block other CPUs from
>    executing RCU callbacks, as there will be no quiescent state observed if
>    the CPU doesn't enter Xen context.
>
>  * If a certain amount of callbacks are pending, RCU will try to force a
>    quiescent state, by sending an IPI to remote CPUs.  This causes unwanted
>    interference.
>
> Keep track of the RCU epoch when a callback was added, and only execute it
> once all CPUs are either outside of RCU critical regions, or any CPUs
> inside of RCU critical regions have entered such past the epoch when the
> callback was queued.  Knowing whether a CPU is inside a RCU critical region
> is done based on the CPU rcu_lock_cnt value.
>
> This removes the grace/quiescent period state tracking entirely: the
> control block, the per-CPU quiescent bookkeeping, the batch lists and the
> forced-quiescent-state IPI all go away.  As a result no RCU-driven IPIs are
> sent to remote CPUs, and callback progress no longer depends on every CPU
> passing through Xen context.
>
> Signed-off-by: Roger Pau Monné <roger@xenproject.org>

All review I already did on this was on the applied patch. I find the
diff a bit too unwieldy. Perhaps it might be good to add the new logic
on top first, and then remove the prior logic.

Something like:

#define RCU_USES_EPOCH 1

#ifdef RCU_USES_EPOCH
<old rcu specifics>
#else
<new rcu specifics>
#endif

... then have a last patch that drops old RCU code. Structs, older
functions, etc can stay until then, because they'll be removed later.
It's just a means of shrinking the diff in order to make it tractable.

My .02, anyway. Perhaps you already tried and it's terrible anyhow.

Cheers,
Alejandro