On Fri, Oct 01, 2021 at 06:51:08PM +0100, Valentin Schneider wrote: > On 30/09/21 00:10, Frederic Weisbecker wrote: > > The current condition to limit the number of callbacks executed in a > > row checks the offloaded state of the rdp. Not only is it volatile > > but it is also misleading: the rcu_core() may well be executing > > callbacks concurrently with NOCB kthreads, and the offloaded state > > would then be verified on both cases. As a result the limit would > > spuriously not apply anymore on softirq while in the middle of > > (de-)offloading process. > > > > Another issue with the condition is that rcu_is_callbacks_kthread() > > doesn't check if we are actually running callbacks from rcuc itself or > > from a softirq interrupting rcuc. > > > > Doesn't rcutree.use_softirq imply rcuc is never woken, in which case > RCU_SOFTIRQ can't interrupt rcuc (e.g. while run atop an IRQ exit)? > I suppose during the (de)offload sequence we could have RCU_SOFTIRQ running > atop the NOCB CB kthread, but that's not something > rcu_is_callbacks_kthread() detects. Yes good point, I don't know if rcuc can be ever be interrupted by irq_exit() -> do_softirq() -> rcu_core() itself after all. Paul can probably confirm your point? > > Also, why is rcu_is_callbacks_kthread() hardcoded to false for > !CONFIG_RCU_BOOST? Isn't it relevant for do_rcu_batch() ratelimiting > regardless (at least before your patches)? I believe rcuc is only used on CONFIG_RCU_BOOST?
