Re: [PATCH V3 1/4] Sched: Scheduler time slice extension

[Prakash Sangappa]

> On May 2, 2025, at 6:06 AM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> 
> On Fri, 2 May 2025 11:05:29 +0200
> Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> 
>>> diff --git a/kernel/sched/syscalls.c b/kernel/sched/syscalls.c
>>> index cd38f4e9899d..1b2b64fe0fb1 100644
>>> --- a/kernel/sched/syscalls.c
>>> +++ b/kernel/sched/syscalls.c
>>> @@ -1378,6 +1378,11 @@ static void do_sched_yield(void)
>>>  */
>>> SYSCALL_DEFINE0(sched_yield)
>>> {
>>> + if (IS_ENABLED(CONFIG_RSEQ) && current->sched_time_delay) {
>>> + schedule();
>>> + return 0;
>>> + }
>>> +
>>> do_sched_yield();
>>> return 0;
>>> }  
>> 
>> Multiple people, very much including Linus, have already said this
>> 'cute' hack isn't going to fly. Why is it still here?
> 
> Who was against this?
> 
> Linus objected to "optimizing yield" because it has *semantics* that
> people depend on because it has historical meaning. Things like "move
> the process to the end of the scheduling queue of that priority".
> 
>  https://lore.kernel.org/linux-trace-kernel/CAHk-=wgTWVF6+dKPff-mhVwngFwBu_G9+fwOTF2Ds+YPj3xkeQ@xxxxxxxxxxxxxx/
> 
> I countered that this "optimization" would only affect those that use
> the extended time slice and would not cause any issues with current
> applications that depend on its current semantics.

Still wouldn’t  that affect performance of the application using the extended time slice optimization?
A sched_yield()  could end up in do_sched_yield(), if ‘shed_time_delay' is not set as the thread had been rescheduled.

> 
> Linus never replied to that.
> 
> Or did Linus reply to this someplace else too that I missed?
> 
> If we don't do this, what would be the system call to use to tell the
> kernel that the task no longer needs extra time?

Yes, need a system call to recommend. 

> 
> -- Steve