Re: [PATCH V7 02/11] sched: Indicate if thread got rescheduled

[Prakash Sangappa <prakash.sangappa@oracle.com>]

> On Aug 7, 2025, at 6:06 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> On Thu, Jul 24 2025 at 16:16, Prakash Sangappa wrote:
> 
> Indicate this to whom? Can you please write descriptive subject lines
> which summarize the change in a way that is comprehensible?
> 
>> +void rseq_delay_resched_clear(struct task_struct *tsk)
>> +{
>> + u32 flags;
>> +
>> + if (tsk->rseq_delay_resched == RSEQ_RESCHED_DELAY_REQUESTED) {
>> + tsk->rseq_delay_resched = RSEQ_RESCHED_DELAY_PROBE;
>> + if (copy_from_user_nofault(&flags, &tsk->rseq->flags, sizeof(flags)))
>> +                        return;
>> +                flags |= RSEQ_CS_FLAG_RESCHEDULED;
>> +                copy_to_user_nofault(&tsk->rseq->flags, &flags, sizeof(flags));
>> + }
>> +}
>> #endif /* CONFIG_RSEQ_RESCHED_DELAY */
>> 
>> #ifdef CONFIG_DEBUG_RSEQ
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index e75ecbb2c1f7..ba1e4f6981cd 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -6752,9 +6752,8 @@ static void __sched notrace __schedule(int sched_mode)
>> picked:
>> clear_tsk_need_resched(prev);
>> clear_preempt_need_resched();
>> - if (IS_ENABLED(CONFIG_RSEQ_RESCHED_DELAY) &&
>> -    prev->rseq_delay_resched == RSEQ_RESCHED_DELAY_REQUESTED)
>> - prev->rseq_delay_resched = RSEQ_RESCHED_DELAY_PROBE;
>> + if(IS_ENABLED(CONFIG_RSEQ_RESCHED_DELAY))
>> + rseq_delay_resched_clear(prev);
> 
> Yet another unconditional function call for the sake of something which
> is only used by special applications. This is the scheduler hotpath and
> not a dump ground for random functionality, which is even completely
> redundant. Why redundant?
> 
> The kernel already handles in rseq, that a task was scheduled out:
> 
>    schedule()
>       prepare_task_switch()
>         rseq_preempt()
> 
> rseq_preempt() sets RSEQ_EVENT_PREEMPT_BIT and TIF_NOTIFY_RESUME, which
> causes exit to userspace to invoke __rseq_handle_notify_resume(). That's
> the obvious place to handle this instead of inflicting it into the
> scheduler hotpath.
> 
> No?

Sure, I will look at moving rseq_delay_resched_clear() call to __rseq_handle_notify_resume().
-Prakash

> 
> Thanks,
> 
>        tglx