oxidecomputer / oxidecomputer/hubris

Define the specific level of "fairness" in scheduling

Open
#2,517 1 comment 0 reactions 1 assignee View on GitHub

@cbiffle is already working on this.

Since May 17, 2026.

🤔 design kernel robustness
Dominant language
Rust
Stars
3.6k
Forks
239
Avg merge
1d 12h
Merged PRs (30d)
23

Description

During in-person conversations, @cbiffle claimed that tasks of the same priority level were scheduled in a "fair, round-robin" manner.

Although higher-priority tasks will always be scheduled before lower-priority tasks, the current reference does not particularly define what level of fairness is given to tasks of the same priority:

Within a single priority level, multitasking is effectively cooperative: the kernel will never interrupt a task to switch to another task of equal or lower priority, until that task performs an operation that yields the CPU, such as sending a message or blocking to receive messages that haven’t arrived yet. The alternative to this is to implement time-slicing, where a task gets a fixed amount of time before another task at the same priority will have the opportunity to run; we chose not to implement this.

If tasks A, B, and C are all made ready, task A is scheduled and sends to a higher priority task which immediately responds, which task will be scheduled? In a "completely fair" scheme, both B and C would be given CPU time before A is re-scheduled. Many schedulers explicitly choose to return to A as it is known that A can now make forward progress (as it just received a response). However if we return to A, there is a possibility that A could continue making calls to high-priority tasks in a loop, which would starve tasks B and C of CPU time until Task A finally cooperatively yields.

I am not actually sure what today's scheduler will do, and given the current specification, either behavior would likely be considered "compliant" with the design.

We may want to ensure "completely fair" scheduling (which may also need to define what happens with "late arriving" tasks, e.g. what if a new Task D becomes ready AFTER Task A has been given time, but before Tasks B and C have been given time? Is it also given time before returning to Task A? Or does it only become eligible in the "next" round?), and update the scheduler (if necessary) and docs to match. OR, we may want to document that scheduling within a single priority may be "unfair", as something to consider when assigning priorities.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.