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-=whVzwPwiQj5PdmZXA8G=9ZS2T-OUPm4VrM8TKTDQW3Dmw@mail.gmail.com>
Date: Sat, 1 Feb 2025 15:35:53 -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:18, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> 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.

Side note: we've messed with this before, exactly because people have
been confused about this before.

I have this dim memory of us having at one point decided to actively
ignore that "put me last" part of sched_yield because we had huge
performance problems with people misusing "sched_yield()".

I didn't actually check what current active schedulers do.  I would
not be in the least surprised if different schedulers end up having
very different behavior (particularly any RT scheduler).

But the moral of the story ends up being the same: don't use yield()
unless you are on some embedded platform and know exactly what the
scheduling pattern is - or if you really want to say "I don't want to
run now, do *anything* else, my performance doesn't matter".

A traditional (reasonable) situation might be "I started another task
or thread, I need for it to run first and initialized things, I'm
polling for that to be done but I don't want to busy-loop if there is
real work to be done".

Where it really is a complete hack: "my performance doesn't matter
because it's a one-time startup thing, and I couldn't be arsed to have
real locking".

In fact, the whole "I couldn't be arsed" is basically the tag-line for
"yield()". Maybe we should rename the system call.

             Linus