linux-kernel - Re: [PATCH 1/1] tick/nohz: Add fast-path tick stopping for idle isolated cores

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-prev] [day] [month] [year] [list]

Message-ID: <aXjAOBKr6tbShb8C@localhost.localdomain>
Date: Tue, 27 Jan 2026 14:40:08 +0100
From: Frederic Weisbecker <frederic@...nel.org>
To: "Ionut Nechita (Sunlight Linux)" <sunlightlinux@...il.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...nel.org>,
	Anna-Maria Behnsen <anna-maria@...utronix.de>,
	Ionut Nechita <ionut_n2001@...oo.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] tick/nohz: Add fast-path tick stopping for idle
 isolated cores

Le Tue, Jan 06, 2026 at 05:36:48PM +0200, Ionut Nechita (Sunlight Linux) a écrit :
> From: Ionut Nechita <ionut_n2001@...oo.com>
> 
> When a CPU is configured as nohz_full and is running the idle task with
> no tick dependencies, we can skip expensive dependency checks and
> immediately allow the tick to stop. This significantly reduces timer
> interrupts on properly isolated cores.

Most of the idle code is under TS_FLAG_INIDLE, and the can_stop_full_tick()
path is then not taken.

> 
> The patch adds:
> 1. Prefetching of dependency structures for better cache locality
> 2. Fast-path optimization for idle isolated cores with no dependencies
> 
> This benefits real-time workloads and latency-sensitive applications
> by minimizing timer interrupt overhead on isolated CPUs.
> 
> Benchmark results show isolated CPUs can achieve <500 LOC (Local timer)
> interrupts with this optimization, compared to ~8K without it, with
> best-case scenarios achieving <125 LOC interrupts on well-configured
> systems.

I guess we could indeed optimize further outside the idle path. But I'm not
sure this is a good thing. After all, the point of nohz_full is to run things
with the tick stopped. The only part that should run with the tick is setup
and preparatory work, which doesn't really needs optimization.

I'm even tempted to say that the tick code is a slowpath on nohz_full.

Thanks.

-- 
Frederic Weisbecker
SUSE Labs