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: <20260128072658.6925-2-sunlightlinux@gmail.com>
Date: Wed, 28 Jan 2026 09:26:57 +0200
From: "Ionut Nechita (Sunlight Linux)" <sunlightlinux@...il.com>
To: frederic@...nel.org
Cc: anna-maria@...utronix.de,
	ionut_n2001@...oo.com,
	linux-kernel@...r.kernel.org,
	mingo@...nel.org,
	sunlightlinux@...il.com,
	tglx@...utronix.de
Subject: Re: [PATCH 1/1] tick/nohz: Add fast-path tick stopping for idle isolated cores

On Tue, Jan 27, 2026 at 02:40:08PM +0100, Frederic Weisbecker wrote:
> Le Tue, Jan 06, 2026 at 05:36:48PM +0200, Ionut Nechita (Sunlight Linux) a écrit :
> > 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.
>
> Most of the idle code is under TS_FLAG_INIDLE, and the can_stop_full_tick()
> path is then not taken.

You're absolutely right about the TS_FLAG_INIDLE observation. Looking at
tick_nohz_irq_exit(), when TS_FLAG_INIDLE is set, the code path goes to
tick_nohz_start_idle() and can_stop_full_tick() is not called at all.

I need to clarify: the benchmark results showing the reduction from 8K to
<500 LOC interrupts were measured with *workloads running* on the isolated
CPUs, not with idle CPUs. The optimization was helping in the non-idle path
where can_stop_full_tick() is actually called via tick_nohz_full_update_tick().

The commit message was misleading by focusing on "idle isolated cores" when
the actual benefit was for nohz_full CPUs running workloads.

> 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.

Thomas suggested a cleaner approach that optimizes check_tick_dependency()
directly by returning early when tracepoints are disabled:

    if (likely(!tracepoint_enabled(tick_stop)))
        return !val;

This is more general and benefits all contexts, not just nohz_full. It avoids
the per-bit iteration when tracing is disabled, which is the common case.

Thanks for pointing out the idle path issue - it helped clarify where the
actual optimization was occurring.

Thanks,
Ionut