linux-kernel - Re: [PATCHSET v6] sched: Implement BPF extensible scheduler class

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]

Date: Thu, 20 Jun 2024 12:20:25 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Tejun Heo <tj@...nel.org>, mingo@...hat.com, peterz@...radead.org, 
	juri.lelli@...hat.com, vincent.guittot@...aro.org, dietmar.eggemann@....com, 
	rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de, bristot@...hat.com, 
	vschneid@...hat.com, ast@...nel.org, daniel@...earbox.net, andrii@...nel.org, 
	martin.lau@...nel.org, joshdon@...gle.com, brho@...gle.com, pjt@...gle.com, 
	derkling@...gle.com, haoluo@...gle.com, dvernet@...a.com, 
	dschatzberg@...a.com, dskarlat@...cmu.edu, riel@...riel.com, 
	changwoo@...lia.com, himadrics@...ia.fr, memxor@...il.com, 
	andrea.righi@...onical.com, joel@...lfernandes.org, 
	linux-kernel@...r.kernel.org, bpf@...r.kernel.org, kernel-team@...a.com
Subject: Re: [PATCHSET v6] sched: Implement BPF extensible scheduler class

On Thu, 20 Jun 2024 at 11:47, Thomas Gleixner <tglx@...utronix.de> wrote:
>
> But wait a moment, that can't happen as pluggable schedulers have been
> rejected in the past:
>
>   "I absolutely *detest* pluggable schedulers."
>
> Guess which famous programmer said that.

I'e also said that I find schedulers in general boring. I think CPU
scheduling is just not very interesting.

Look at the 0.01 scheduler, and the comment above it:

 *  'schedule()' is the scheduler function. This is GOOD CODE! There
 * probably won't be any reason to change this, as it should work well
 * in all circumstances (ie gives IO-bound processes good response etc).
 * The one thing you might take a look at is the signal-handler code here.

Which shows just how much I knew (or cared).

Things change. Back then, you could have a maximum of 63 processes
(plus the idle task).

And the "I detest pluggabnle schedulers" has been long superseded by
"I detest people who complain about our one scheduler because they
have special loads that only they care about".

> > But I get the very strong feeling that people wanted to limit the
> > amount of changes they made to the core scheduler code.
>
> Which is exactly the point.

But Thomas - that's *MY* point.

If this code stays out of tree, the goal is always that "don't
integrate, make the patch easy to apply".

This whole "keep things out until they are perfect" is a DISEASE.

It's a disease because it's counter-productive. First off, things will
never be "perfect" because you have people with different goals in the
first place.,

But secondly, the "keep things out" is itself counter-productive.

             Linus