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

[K Prateek Nayak]

Hello Will,

On 7/16/2026 8:39 PM, Will Deacon wrote:
> 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.

But you can idle with scheduler tick enabled with WFE and that should
allow you to retrospect and go deeper at the next tick if needed, no?
>   2. An IRQ doesn't wake WFE if IRQs are disabled (this is different to
>      WFI).

I'm out of my depths here but the on x86 side mwait_idle() does an
MWAIT with interrupts enabled.

The polling flag being set is simply an optimization for the IPI sender
to set RESCHED bit instead of sending a physical IPI - an external
interrupt is still possible and will break out of idle.

Also, the other question on the thread was: Is try_cmpxchg() much
worse than a test_and_set_ti_thread_flag() (which uses
test_and_set_bit()) on ARM64?

The full diff in
https://lore.kernel.org/lkml/14abaec8-05ca-4034-b153-b993ed60a1fb@xxxxxxx/
replaces a test_and_set_ti_thread_flag() path with a try_cmpxchg()
one and we were wondering if the code unification is worth the
performance lost.

-- 
Thanks and Regards,
Prateek