On Fri, Jan 21, 2022 at 09:30:19PM -0800, Paul E. McKenney wrote: > On Fri, Jan 21, 2022 at 01:33:46PM -0500, Brian Foster wrote: [ . . . ] > > My previous experiments on a teardown grace period had me thinking > > batching would occur, but I don't recall which RCU call I was using at > > the time so I'd probably have to throw a tracepoint in there to dump > > some of the grace period values and double check to be sure. (If this is > > not the case, that might be a good reason to tweak things as discussed > > above). > > An RCU grace period typically takes some milliseconds to complete, so a > great many inodes would end up being tagged for the same grace period. > For example, if "rm -rf" could delete one file per microsecond, the > first few thousand files would be tagged with one grace period, > the next few thousand with the next grace period, and so on. > > In the unlikely event that RCU was totally idle when the "rm -rf" > started, the very first file might get its own grace period, but > they would batch in the thousands thereafter. > > On start_poll_synchronize_rcu() vs. get_state_synchronize_rcu(), if > there is always other RCU update activity, get_state_synchronize_rcu() > is just fine. So if XFS does a call_rcu() or synchronize_rcu() every > so often, all you need here is get_state_synchronize_rcu()(). > > Another approach is to do a start_poll_synchronize_rcu() every 1,000 > events, and use get_state_synchronize_rcu() otherwise. And there are > a lot of possible variations on that theme. > > But why not just try always doing start_poll_synchronize_rcu() and > only bother with get_state_synchronize_rcu() if that turns out to > be too slow? Plus there are a few optimizations I could apply that would speed up get_state_synchronize_rcu(), for example, reducing lock contention. But I would of course have to see a need before increasing complexity. Thanx, Paul
