On Thu, Dec 25, 2025 at 10:54:20AM -0800, Paul E. McKenney wrote: > On Tue, Dec 23, 2025 at 09:06:19PM -0500, Joel Fernandes wrote: > > Hi Paul, > > > > On Tue, Dec 23, 2025 at 03:53:23PM -0800, Paul E. McKenney wrote: > > > On Tue, Dec 23, 2025 at 12:38:19PM -0500, Joel Fernandes wrote: > > > > During studying some synchronize_rcu() latencies, I found that the > > > > jiffies_till_first_fqs value passed to the timer tick subsystem does is > > > > always > > > > off by one. This is natural due to calc_index() rounding up. > > > > > > > > For example, jiffies_till_first_fqs=3 means the "Jiffies till first > > > > FQS" delay > > > > is actually 4ms. And same for the next FQS. In fact, in testing it > > > > shows it can > > > > never ever be 3ms for HZ=1000. And in rare cases, it will go to 5ms > > > > probably due > > > > to interrupts. > > > > > > > > Considering this, I think it is better to reduce the > > > > jiffies_till_first_fqs by 1 > > > > before passing it to the wait APIs. > > > > > > > > But before I wanted to send a patch, I wanted to get everyone's > > > > thoughts. > > > > Considering this the RFC. > > > > > > Inadvertent passing of the value zero? > > > > This should not be an issue because at the moment, even a value of > > jiffies_till_first_fqs == 0 waits for ~1 jiffie due to schedule_timeout(0). > > > > But you raise a good point, we should cap the minimum allowed jiffie value > > for the fqs parameters to 1 so that we don't pass schedule_timeout() with > > negative values when/if we do the reduce-by-one approach. > > There is a potential use case for jiffies_till_first_fqs=0 and no wait, > which would be systems that want to scan for idle CPUs immediately after > the grace period has been initialized. Note the word "potential". ;-)
Sure, we could add support for that but that would be new behavior that is not in the existing code. So jiffies_till_first_fqs=0 today, I think it is not 'working as intended' because it will never not wait I think. So we should fix that too? Or maybe it can be a patch separate from this (that I can work on). I think no harming in allowing that mode, at least it will be more in line with the expected outcome. > > If we want to support this, then perhaps we would need to avoid that > schedule_timeout(0). Or rcu_gp_fqs_check_wake(), as the case may be. True. thanks, - Joel
