On Fri, Aug 16, 2024 at 01:33:30PM GMT, Paul E. McKenney wrote: > On Thu, Aug 15, 2024 at 11:20:09AM -0400, Kent Overstreet wrote: > > On Thu, Aug 15, 2024 at 08:13:10AM GMT, Paul E. McKenney wrote: > > > On Thu, Aug 15, 2024 at 10:58:37AM -0400, Kent Overstreet wrote: > > > > start_poll_synchronize_rcu_common() requires that irqs are enabled > > > > > > > > that doesn't match call_rcu() requirements, so - can we lift that > > > > requirement? I need to be able to make sure the grace period is > > > > started... > > > > > > I have to awaken the grace-period kthread, and wakeups are no longer > > > possible when interrrupts are hard-disabled. > > > > Err, what? How do we get anything done when IRQs are hard disabled, > > then? > > Good point, I was confused. I will try it and see what happens. > Perhaps you have already done so?
>From a cursory glance at the test dashboard, it looks good :) I was hesitant at first because... that's not a normal wakeup, but I read through it more and I think it's safe. > Hey, you are the one who sent me a private query while I am on vacation! > Kidding aside, CCing [email protected] gives others in a variety > of timezones a chance to help out. > > > > Another approach is to replace that start_poll_synchronize_rcu() or > > > start_poll_synchronize_rcu_full() with a get_state_synchronize_rcu() > > > followed by a "throw-away" call_rcu(), that is, one whose callback > > > function does nothing. Would that work for you? > > > > Maybe? If call_rcu() then skips adding the entry to the list of pending > > callbacks (which it would have to, we're not going to get the > > notification when the rcu_head is completed) so that we can reuse it > > right away for the next gp, then that should work... > > OK, OK, "does almost nothing". ;-) > > Yes, you would need a small state machine to rearm if there was a > subsequent start-poll call and so on. > > But does your (almost) unconditionally rearming callback have some > purpose other than to work around start_poll_synchronize_rcu_common() > currently giving lockdep splats when invoked with irqs disabled? Yes, processing pending items - so it would be ideal to get a callback for every grace period we have items for, though not strictly necessary for a v1. But as mentioned previously, the issue is that since RCU callbacks may be punted to a kthread (correct?) - we'd need memory for an unbounded number of pending callbacks, which doesn't work here; we don't have a way of handling that allocation failure. Long term, I think it would be a worthy goal if this code could be used for tracking RCU callbacks, so as to eliminate the linked lists overhead in processing them. For that to happen, we'd need a different way of getting notified when grace periods elapse, so maybe we could kill two birds with one stone on that one.
