Hello, On Tue, 7 Nov 2023, Ankur Arora wrote: > With PREEMPTION being always-on, some configurations might prefer > the stronger forward-progress guarantees provided by PREEMPT_RCU=n > as compared to PREEMPT_RCU=y. > > So, select PREEMPT_RCU=n for PREEMPT_VOLUNTARY and PREEMPT_NONE and > enabling PREEMPT_RCU=y for PREEMPT or PREEMPT_RT. > > Note that the preemption model can be changed at runtime (modulo > configurations with ARCH_NO_PREEMPT), but the RCU configuration > is statically compiled. > > Cc: Simon Horman <horms@xxxxxxxxxxxx> > Cc: Julian Anastasov <ja@xxxxxx> > Cc: Alexei Starovoitov <ast@xxxxxxxxxx> > Cc: Daniel Borkmann <daniel@xxxxxxxxxxxxx> > Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > Signed-off-by: Ankur Arora <ankur.a.arora@xxxxxxxxxx> > > --- > CC-note: Paul had flagged some code that might be impacted > with the proposed RCU changes: > > 1. My guess is that the IPVS_EST_TICK_CHAINS heuristic remains > unchanged, but I must defer to the include/net/ip_vs.h people. Yes, IPVS_EST_TICK_CHAINS depends on the rcu_read_unlock() and rcu_read_lock() calls in cond_resched_rcu(), so just removing the cond_resched() call there is ok for us. Same for the other cond_resched() calls in ipvs/ Regards -- Julian Anastasov <ja@xxxxxx>
