On Tue, Jul 04, 2023 at 04:26:15PM +0800, Zqiang wrote: > When invoke synchronize_srcu(), in the srcu_might_be_idle(), the current > CPU's sdp->lock will be acquired to check whether there are pending > callbacks in the sdp->srcu_cblist, if there are no pending callbacks, > probabilistically probe global state to decide whether to convert to > synchronize_srcu_expedited() call. however, for the rcupdate.rcu_normal=1 > kernels and after the rcu_set_runtime_mode() is called, invoke the > rcu_gp_is_normal() is always return true, this mean that invoke the > synchronize_srcu_expedited() always fall back to synchronize_srcu(), > so there is no need to acquire sdp->lock to check sdp->srcu_cblist and > probe global state in srcu_might_be_idle(). > > This commit therefore make srcu_might_be_idle() return immediately if the > rcu_gp_is_normal() return true. > > Signed-off-by: Zqiang <qiang.zhang1211@xxxxxxxxx> > --- > kernel/rcu/srcutree.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c > index 20d7a238d675..aea49cb60a45 100644 > --- a/kernel/rcu/srcutree.c > +++ b/kernel/rcu/srcutree.c > @@ -1172,6 +1172,8 @@ static bool srcu_might_be_idle(struct srcu_struct *ssp) > unsigned long tlast; > > check_init_srcu_struct(ssp); > + if (rcu_gp_is_normal()) > + return false; Again, thank you for looking into SRCU! I am not at all enthusiastic about this one. With this change, the name srcu_might_be_idle() is no longer accurate. Yes, the name could change, but any name would be longer and more confusing. So unless there is a measureable benefit to this one on a production workload, I cannot justify taking it. Is there a measureable benefit? Thanx, Paul > /* If the local srcu_data structure has callbacks, not idle. */ > sdp = raw_cpu_ptr(ssp->sda); > spin_lock_irqsave_rcu_node(sdp, flags); > -- > 2.17.1 >
