On Sun, Aug 18, 2024 at 08:52:59PM GMT, Paul E. McKenney wrote: > On Sun, Aug 18, 2024 at 09:19:16PM -0400, Kent Overstreet wrote: > > On Sun, Aug 18, 2024 at 10:01:42AM GMT, Paul E. McKenney wrote: > > > But you only need one callback per live outstanding "cookie" returned > > > from get_state_synchronize_rcu*() or start_poll_synchronize_rcu(). > > > Or am I missing something here? > > > > Maybe I am? > > > > I've been assuming that if rcu callbacks are getting punted off to a > > kthread that we can't rely on them being completed in any particular > > timeframe - i.e. the number of grace periods with outstanding callbacks > > would be unbounded. > > Exactly, and that is why there is a check for expired cookies during the > addition of a new data element that needs to wait for a grace period. > The only purpose of that call_rcu() callback is to act as a fallback in > case there is a long period of time with no newly arriving data elements > that need to wait for a grace period. > > > You're saying that NUM_ACTIVE_RCU_POLL_FULL_OLDSTATE _does_ include > > grace periods with outstanding callbacks? Just want to be clear on that. > > No, it does not, but given the algorithm outlined in my previous > email, it doesn't need to. The point of the callbacks is *not* to > unconditionally drive things forward, but instead to provide a fallback > to do the necessary processing in the case nothing new arrives for an > extended period of time.
You can't use a fixed number of callback heads if there's going to be an unbounded number of callback heads outstanding.
