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.Changelog updated in v5:
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/
https://lore.kernel.org/all/20260127031602.1907377-1-wangyang.guo@xxxxxxxxx/
BR
Wangyang