Date: Fri, 06 Jun 2025 19:12:04 +0200 From: Olivier Certner <olce@freebsd.org> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Soon committing the "256-queue runqueue" scheduler work Message-ID: <8236932.iDzAj6rjnq@ravel> In-Reply-To: <3n5or4pq-npos-7301-np11-46nqr1sroopr@yvfgf.mnoonqbm.arg> References: <2038652.ruP0FAUDoQ@ravel> <3n5or4pq-npos-7301-np11-46nqr1sroopr@yvfgf.mnoonqbm.arg>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] Hi Bjoern, > Can you tell us the 'why?' as well, as what this work is trying to > solve/improve? I am sure there was a reason to do all this? This was really to have this working: "- The 32 realtime priority levels, and the 32 idle priority ones, are now going to be really distinct. Previously, levels with the same quotient when divided by 4 were aliased (separately in each class)." for practical uses (I use idprio abundantly, e.g., for background compilation and other jobs) and for POSIX compliance, as software that wants to use real-time scheduling (generally for multimedia) expects the levels to be distinct (they generally choose one level, either hardcoded or obtained through sched_get_priority_min()/sched_get_priority_max(), and then increment/decrement from it, expecting that highest priorities will preempt lower ones, which they would not here; the problem is mitigated with enough cores depending on the software). We would like to promote the use of soft real-time software on FreeBSD, and in particular audio/video real-time processing. Another, longer-term reason was to get familiar with ULE and gather knowledge on where it works well, where it does not, and in which ways it could be extended (or perhaps even substantially reworked) for the future. In the process, some of the thread selection algorithms used have been fused and their performance in corner cases improved. Removing duplicate or very similar code both allowed to remove some bugs or quirks without positive effects and improve the overall understanding. Regards. -- Olivier Certner [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmhDIWQACgkQjKEwQJce JicgyxAAlwGPm8tt9JK37vOlJcS19NfyJ6u9FtK/Hbv+NWjwpHbXVMzyqtpVAj2K fxGSuMV5JdImqPOsNfeg1/8urzgRpggSVSWgLN6zcdQTOnksyrNjNErduE5Y1+xl a9iT1yk+7KVf7Dd/gQ5r+v6YfoAOUJfi7oJdT0UlLVZNO2fsgos/sitJfZoU8ncQ HUG3C4DOfNhwhI6XHXimlzALiEBOtdgbpF2fUt5WFUOdhP2Yc9AXuC81mNIdafOT Cl3cFggKO+IORxqsUhmVjQBN7dhu7m8u/Jnl1oJKoUnNfPEfrNEMCLFI6nokYaB8 ZQQTXUFXsFWJLam11hUWz8Z9RbdJ0lN8Fr0pl1nGRknPl14aLCBqRqIvDoO9F6w+ yRcMZYbysBAQz3Vs0Pj3IczgfONh0mQ2N+3gKItkJjLx1YJxUqCCiEa8KBUkuwVO X9q1RZl1zJ7USxt7hl6LEEEbfFlzMlDNh2w2xP4ohkHzZglb6RxgQDdgkmNJOfv8 lsX2/BpIsB0IQHHc6+VIJ5Z3gshGgE/BsiFE6s8lkMBOjvnSNUChRam5mSjmbKcr +XceKry5BNhe43/xalbEnjyhAzBihFLv6SHvKfMPDWYMNhfhwIMBpQ9J3HTaWe3F J85NLlg33lO/8ok8ktKl3oGjeMdq8O6P+pTt3u+T05tsjSOu+FA= =Fp+U -----END PGP SIGNATURE-----help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8236932.iDzAj6rjnq>
