Re: [RESEND PATCH] tick/nohz: Fix wrong NOHZ idle CPU state

[Frederic Weisbecker]

Le Thu, Feb 12, 2026 at 12:04:11PM -0800, Shubhang Kaushik a écrit :
> On Thu, 12 Feb 2026, Shubhang Kaushik wrote:
> 
> > >  Because you rely on dynamic placement of isolated tasks throughout
> > >  isolated
> > >  CPUs by the scheduler.
> > > 
> > >  But nohz_full is designed for running only one task per isolated CPU
> > >  without
> > >  any disturbance. And migration is a significant disturbance. This is why
> > >  nohz_full tries not to be too smart and assumes that task placement is
> > >  entirely
> > >  within the hands of the user.
> > > 
> > >  So I have to ask, what prevents you from using static task placement in
> > >  your
> > >  workload?
> > 
> > Actually, the llama-batched-bench results I shared already included
> > static affinity testing via numactl -C.
> 
> What I mean by that is even when tasks are strictly pinned to individual
> cores, the performance gap remains.
> 
> IIUC, the current implementation assumes tick-stop and idle-entry are
> coupled. While this holds for standard NOHZ, nohz_full decouples them,
> causing idle CPUs to be omitted from nohz.idle_cpus_mask.
> 
> This hides idle capacity from  the NOHZ idle balancer, forcing housekeeping
> tasks onto active cores. By decoupling these transitions in the code, we
> ensure accurate state accounting.

You mean housekeeping tasks are moved to isolated CPUs? With proper
isolation setting (ie: domain + nohz_full) this shouldn't happen.

Thanks.

-- 
Frederic Weisbecker
SUSE Labs