Re: [PATCH v4] sched/clock: Avoid false sharing for sched_clock_irqtime

From: Guo, Wangyang

Date: Mon Jan 26 2026 - 22:25:05 EST


On 1/27/2026 2:45 AM, Shrikanth Hegde wrote:
Hi Wangyang.

On 1/26/26 7:44 AM, Wangyang Guo wrote:
Read-mostly sched_clock_irqtime may share the same cacheline with
frequently updated nohz struct. Make it as static_key to avoid
false sharing issue.

Details:
In kernel 6.14, we observed ~3% cycles hotspots in irqtime_account_irq
when running SPECjbb2015 in a 2-sockets system. Most of cycles spent
in reading sched_clock_irqtime, which is a read-mostly var.


IMHO, this changelog is meant for latest sched/core. having 6.14 data won't be
that relevant.

Also, changelog should be mentioning essence of calling disable in
sched_clock_init_late which was in v3 discussions.

perf c2c (cachelien view) shows it has false sharing with nohz struct:
      Num RmtHitm LclHitm  Offset records             Symbol
    6.25%   0.00%   0.00%   0x0       4   [k] _nohz_idle_balance.isra.0
   18.75% 100.00%   0.00%   0x8      14   [k] nohz_balance_exit_idle
    6.25%   0.00%   0.00%   0x8       8   [k] nohz_balance_enter_idle
    6.25%   0.00%   0.00%   0xc       8   [k] sched_balance_newidle
    6.25%   0.00%   0.00%  0x10      31   [k] nohz_balancer_kick
    6.25%   0.00%   0.00%  0x20      16   [k] sched_balance_newidle
   37.50%   0.00%   0.00%  0x38      50   [k] irqtime_account_irq
    6.25%   0.00%   0.00%  0x38      47   [k] account_process_tick
    6.25%   0.00%   0.00%  0x38      12   [k] account_idle_ticks

Offsets:
*  0x0 -- nohz.idle_cpu_mask (r)
*  0x8 -- nohz.nr_cpus (w)
* 0x38 -- sched_clock_irqtime (r), not in nohz, but share cacheline

The layout in /proc/kallsyms can also confirm that:
ffffffff88600d40 b nohz
ffffffff88600d68 B arch_needs_tick_broadcast
ffffffff88600d6c b __key.264
ffffffff88600d6c b __key.265
ffffffff88600d70 b dl_generation
ffffffff88600d78 b sched_clock_irqtime

With the patch applied, irqtime_account_irq hotspot disappear.

---

Please dont put a --- here.

git am will strip everything after this and actual diff. So the your
signed-off-by and other details won't be captured.

If the intention was keep version history, put it after the signed-off-by
for example:
https://lore.kernel.org/lkml/20260120113246.27987-2-kprateek.nayak@xxxxxxx/
Changelog updated in v5:

https://lore.kernel.org/all/20260127031602.1907377-1-wangyang.guo@xxxxxxxxx/

BR
Wangyang