linux-kernel - Re: [RFC][PATCH 1/2] sched: Extended scheduler time slice

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: <CAHk-=wgTWVF6+dKPff-mhVwngFwBu_G9+fwOTF2Ds+YPj3xkeQ@mail.gmail.com>
Date: Sat, 1 Feb 2025 15:18:15 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, linux-kernel@...r.kernel.org, 
	linux-trace-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>, 
	Peter Zijlstra <peterz@...radead.org>, Ankur Arora <ankur.a.arora@...cle.com>, linux-mm@...ck.org, 
	x86@...nel.org, akpm@...ux-foundation.org, luto@...nel.org, bp@...en8.de, 
	dave.hansen@...ux.intel.com, hpa@...or.com, juri.lelli@...hat.com, 
	vincent.guittot@...aro.org, willy@...radead.org, mgorman@...e.de, 
	jon.grimm@....com, bharata@....com, raghavendra.kt@....com, 
	boris.ostrovsky@...cle.com, konrad.wilk@...cle.com, jgross@...e.com, 
	andrew.cooper3@...rix.com, Joel Fernandes <joel@...lfernandes.org>, 
	Vineeth Pillai <vineethrp@...gle.com>, Suleiman Souhlal <suleiman@...gle.com>, 
	Ingo Molnar <mingo@...nel.org>, Clark Williams <clark.williams@...il.com>, bigeasy@...utronix.de, 
	daniel.wagner@...e.com, joseph.salisbury@...cle.com, broonie@...il.com
Subject: Re: [RFC][PATCH 1/2] sched: Extended scheduler time slice

On Sat, 1 Feb 2025 at 15:08, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> No it doesn't need to be yield. That just seemed like the obvious
> system call to use. But any system call would force a schedule. We
> could just optimize yield() though.

No, "optimizing" yield is not on the table.

Why? 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".

That may sound like a good thing, but it's ABSOLUTELY NOT what you
should actually do unless you know *exactly* what the system behavior
is.

For example, maybe the reason the kernel set NEED_RESCHED_LAZY is that
a higher-priority process is ready to run. You haven't used up your
time slice yet, but something more important needs the CPU.

If you call "sched_yield()", sure, you'll run that higher priority
thing. So far so good.

But you *also* are literally telling the scheduler to put you at the
back of the queue, despite the fact that maybe you are still in line
to be run for *your* priority level. So now your performance will
absolutely suck, because you just told the scheduler that you are not
important, and other processes in your priority level should get
priority.

So no. "yield()" does not mean "just reschedule". It rally means
"yield my position in the scheduling queue".

You are literally better off using absolutely *ANY* other system call.

The fact that you are confused about this kind of very basic issue
does imply that this patch should absolutely be handled by somebody
who knows the scheduler better.

               Linus