linux-kernel - Minimal Scheduler vs Breakpoints (was low jitter, fair pay philosophy)

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 for Android: free password hash cracker in your pocket

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

Message-ID:
 <PAVP192MB21355D55EC51FD990147B3A1E941A@PAVP192MB2135.EURP192.PROD.OUTLOOK.COM>
Date: Tue, 1 Jul 2025 08:39:53 +0000
From: Ywe Cærlyn <ywec4rlyn@...look.com>
To: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Minimal Scheduler vs Breakpoints (was low jitter, fair pay
 philosophy)

I came to think of coding policies. Is it not better with a minimal scheduler, rather than breakpoints (/messy code)?

Is heuristic really rational in a scheduler, should one not rather accept correct use of priority, for what slice of cpu there is?

a 10 ms filter in sched.c is odd !

Some of these symbols seem to indicate a failure. Is billion dollar red hat industry a failure?

A more fair pay compliant coding policy is the above, a minimal scheduler (rather than breakpoints).

Ywe Cærlyn,
Bit Budi
https://bitology.eu/