Re: [PATCH v2] sched: set TIF_NEED_RESCHED before calling __trace_set_need_resched()

[Will Deacon]

On Wed, Jul 01, 2026 at 10:49:39AM +0200, Peter Zijlstra wrote:
> On Wed, Jul 01, 2026 at 01:39:23PM +0530, K Prateek Nayak wrote:
> > Hello Peter,
> > 
> > On 7/1/2026 12:24 PM, Peter Zijlstra wrote:
> > >> @@ -1204,16 +1217,16 @@ static void __resched_curr(struct rq *rq, int tif)
> > >>  	cpu = cpu_of(rq);
> > >>  
> > >>  	if (cpu == smp_processor_id()) {
> > >> -		set_ti_thread_flag(cti, tif);
> > >> +		int set = test_and_set_ti_thread_flag(cti, tif);
> > >> +
> > >> +		if (trace_sched_set_need_resched_tp_enabled() && !set)
> > >> +			trace_call__sched_set_need_resched_tp(curr, cpu, tif);
> > >>  		if (tif == TIF_NEED_RESCHED)
> > >>  			set_preempt_need_resched();
> > >> -		trace_sched_set_need_resched_tp(curr, cpu, tif);
> > >>  		return;
> > >>  	}
> > > 
> > > I can't help but notice that the local and !POLLING cases show
> > > remarkable similarity. Just not sure extracting that isn't going to make
> > > a mess.
> > > 
> > > Anyway, yes this looks about right.
> > 
> > If the fetch_or() based path is okay for !POLLING and local cases which
> > uses a slightly (vastly?) worse instruction to set the ti->flags, we can
> > instead do:
> > 
> 
> Tempting, but at least arm64 would have to agree I think. That said, I
> wonder why ARM64 doesn't use LDXR+WFE for idle, just like we have
> MONITOR+MWAIT.
>
> Probably too damn many idle flavours to deal with or somesuch.

I think the problem is a combination of:

  1. You probably want to enter a deeper sleep state after polling for a
     bit, but you might just get stuck in the WFE if you don't get an
     update.
  2. An IRQ doesn't wake WFE if IRQs are disabled (this is different to
     WFI).

The series to add timeout-based cond-waits fixes (1) for the cpuidle
polling loop:

https://lore.kernel.org/r/20260714073041.40250-13-ankur.a.arora@xxxxxxxxxx

Will