linux-kernel - [RFC] jiffies_till_first

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <1efce983-639b-430d-a613-03baef81c416@nvidia.com>
Date: Tue, 23 Dec 2025 12:38:19 -0500
From: Joel Fernandes <joelagnelf@...dia.com>
To: rcu <rcu@...r.kernel.org>
Cc: Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org,
 Davidlohr Bueso <dave@...olabs.net>, Josh Triplett <josh@...htriplett.org>,
 Frederic Weisbecker <frederic@...nel.org>,
 Neeraj Upadhyay <neeraj.upadhyay@...nel.org>,
 Boqun Feng <boqun.feng@...il.com>, Uladzislau Rezki <urezki@...il.com>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Lai Jiangshan <jiangshanlai@...il.com>, Zqiang <qiang.zhang@...ux.dev>,
 rcu@...r.kernel.org
Subject: [RFC] jiffies_till_first_fqs off by 1

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.

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.

 - Joel