linux-kernel - Re: [PATCH V4 1/6] Sched: Scheduler time slice extension

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3EF0AA39-2C51-4E70-975C-CF8BBF27DAE4@oracle.com>
Date: Tue, 20 May 2025 16:52:20 +0000
From: Prakash Sangappa <prakash.sangappa@...cle.com>
To: Steven Rostedt <rostedt@...dmis.org>
CC: Madadi Vineeth Reddy <vineethr@...ux.ibm.com>,
        "peterz@...radead.org"
	<peterz@...radead.org>,
        "mathieu.desnoyers@...icios.com"
	<mathieu.desnoyers@...icios.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "bigeasy@...utronix.de" <bigeasy@...utronix.de>,
        "kprateek.nayak@....com"
	<kprateek.nayak@....com>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V4 1/6] Sched: Scheduler time slice extension



> On May 15, 2025, at 2:01 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> On Wed, 14 May 2025 23:12:26 +0000
> Prakash Sangappa <prakash.sangappa@...cle.com> wrote:
> 
>>> As mentioned in previous versions, does this not change the semantics for
>>> sched_yield()? Why is this necessary to immediately call schedule() and skip
>>> going through do_sched_yield()?  
>> 
>> Expectation is that the user thread/application yield the cpu once it is done executing
>> any critical section in the extra time granted. Question was which system
>> call should it call, and yield seems appropriate.  It could call any system call actually.
>> 
>> Since thread is just yielding the cpu it should retain its position in the queue. So it does 
>> not have to go thru do_sched_yield() as that would put the task at and of the queue.
> 
> If it was granted an extension, from the POV of user space, it actually
> shouldn't keep it's place in the queue, because it's place is currently
> "promoted" and according to the scheduler, it shouldn't be running in
> the first place. But in the kernel, we are just dealing with
> implementation details. Going back to user space should cause it to be
> scheduled out otherwise it shouldn't be extended in the first place.

But the thread has to make the sched_yied() call. The behavior of which
will be different if called in the extended time vs not. Assume this is ok.

-Prakash



> 
> -- Steve