git: 43c126c9f5 - main - status: 2024Q3: Scheduling Priorities: 256-queue Runqueues Sub-Project

The branch main has been updated by olce:

URL: https://cgit.FreeBSD.org/doc/commit/?id=43c126c9f55567843b20e8978a50b971ec8f8277

commit 43c126c9f55567843b20e8978a50b971ec8f8277
Author:     Olivier Certner <olce@FreeBSD.org>
AuthorDate: 2024-10-09 14:10:21 +0000
Commit:     Olivier Certner <olce@FreeBSD.org>
CommitDate: 2024-10-09 16:53:46 +0000

    status: 2024Q3: Scheduling Priorities: 256-queue Runqueues Sub-Project
    
    Reviewed by:    salvadore
    Approved by:    emaste (mentor)
    Differential Revision:  https://reviews.freebsd.org/D47026
---
 .../sched_prio-256_queue_runqueue.adoc             | 25 ++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/website/content/en/status/report-2024-07-2024-09/sched_prio-256_queue_runqueue.adoc b/website/content/en/status/report-2024-07-2024-09/sched_prio-256_queue_runqueue.adoc
new file mode 100644
index 0000000000..3e39a9163b
--- /dev/null
+++ b/website/content/en/status/report-2024-07-2024-09/sched_prio-256_queue_runqueue.adoc
@@ -0,0 +1,25 @@
+=== Scheduling Priorities: 256-queue Runqueues Sub-Project
+
+Contact: Olivier Certner <olce.freebsd.statusreports@certner.fr>
+
+The goal of the 256-queue runqueues sub-project is to fix FreeBSD's POSIX compliance in that different priority levels in the `SCHED_FIFO` or `SCHED_RR` scheduling classes must lead to immediate preemption by threads having higher priority.
+It is part of the bigger scheduling priorities revamp project aiming at rationalizing FreeBSD scheduling interfaces, including having consistent man:rtprio[2] and POSIX interface behaviors (where it makes sense), enhancing POSIX compliance, removing duplicate code and fixing existing bugs, and enhancing the non-standard parts both for better control and security.
+Expected benefits are increased usage of FreeBSD as a soft real-time platform, e.g., for video and audio processing in casual desktop uses to professional settings.
+Readers interested in this topic are invited to consult link:https://papers.freebsd.org/2024/asiabsdcon/certner-Scheduling_priorities_in_FreeBSD.files/AsiaBSDCon2024-Certner-Scheduling_priorities_in_FreeBSD-Article.pdf[AsiaBSDCon 2024's paper] and link:https://papers.freebsd.org/2024/eurobsdcon/certner-Scheduling_Priorities_and_FreeBSD.files/EuroBSDCon2024-Certner-Scheduling_Priorities_and_FreeBSD.pdf[EuroBSDCon 2024's slides] for a wider view, and to contact me for questions, feedbacks or discussions.
+
+Currently, priority levels specified either through the `prio` field of `struct rtprio` (man:rtprio[2] interface) or the `sched_priority` one of `struct sched_param`, for real-time scheduling classes (`RTP_PRIO_FIFO` and `RTP_PRIO_REALTIME` for the former, `SCHED_FIFO` and `SCHED_RR` for the latter) as well as idle-time ones (`RTP_PRIO_IDLE`), are conflated as follows: Each priority level that has the same quotient when divided by 4 is internally treated the same.
+In particular, threads being in the same such equivalence class but having higher priority will not preempt other threads in the same class, violating POSIX expectations for `SCHED_FIFO` and `SCHED_RR`.
+
+To remedy this situation, we have chosen an impacting internal change on the number of queues per runqueue, and defer to the above-mentioned EuroBSDCon 2024's slides for more details.
+
+The switch to 256-queue runqueues having non-trivial impacts on the ULE scheduler, we have been analyzing it and tuning the scheduler to preserve its previous behavior with respect to anti-starvation and the effect of nice values.
+With the goal to perform further testing, we have revived Jeff Roberson's initial ULE's test tool, called `late` (currently available on link:https://github.com/OlCe2/late[GitHub]).
+
+All the modifications made as part of this sub-project are currently under review, starting with Phabricator's link:https://reviews.freebsd.org/D45387[review D45387] (click on the "Stack" tab to see the full series of reviews).
+
+In the course of this project, we have noticed that the effect of nice values is especially weak, and consequently have produced experimental patches to make their effect stronger.
+However, it is not clear at this point whether we can increase their effect satisfactorily enough in the current ULE setting.
+
+We have also started another scheduler project about adapting ULE to hybrid architectures, which might also trigger more drastic scheduler changes.
+
+Sponsor: The FreeBSD Foundation