On Tue, Dec 23, 2025 at 12:38:19PM -0500, Joel Fernandes wrote:
> Hello,
>
> 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?
> The other place I found this was when call_rcu_hurry() is called, but the GP
> thread takes a tick to wake up, but this isn't related to the timer per-se, it
> is just that we don't want to wake the GP thread too often. So we just wait
> for
> the next tick to notice callbacks before doing a wakeup.
>
> Heh, and this means synchronize_rcu() latencies will multiply when HZ < 1000.
> I
> wonder if this is also what caused Uladzislau to investigate it for mobile
> devices.
Quite possibly!
Back in the day, the theory was that lower HZ tended to imply less-capable
CPUs, and thus a need to lighten the load. So there might need to be
some adjustment for present-day hardware.
Thanx, Paul
