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

[Ionut Nechita (Sunlight Linux)]

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