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. thanks, - Joel
