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". ;-)
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.
Thanx, Paul
