scx_prio_less(9)

📦 version 7.3.1, in nixpkgs unstable

💅 scx_prio_less(9) — Kernel API Manual, bestie 💅

Okay so welcome to the Kernel API Manual page for scx_prio_less(9). This is the whole lore on task ordering for core-sched, and yes, we’re gonna get into it. 🫶

🌸 NAME 🌸

scx_prio_less — Task ordering for core-sched

✨ SYNOPSIS ✨

bool scx_prio_less (const struct task_struct *a , const struct task_struct *b , bool in_fi );

🎀 ARGUMENTS 🎀

  • a — task A
  • b — task B
  • in_fi — in forced idle state

🦋 DESCRIPTION 🦋

Core-sched is literally an additional scheduling layer sitting on top of the usual sched_class'es, and it needs to find out the expected task ordering. For SCX, core-sched calls this function to interrogate the task ordering. 💖

A pair of tasks owned by one scheduler is ordered by the owner’s ops.core_sched_before. A pair spanning two schedulers is ordered by their nearest common ancestor which implements the op — and that’s the one case where the op is called on tasks that the scheduler delegated to its sub-schedulers and may not be scheduling anymore. Bestie, that’s the little plot twist. 🌀

When neither applies, or the deciding scheduler is bypassing on either task’s CPU, the default ordering runs the task which has been waiting longer first. A running task counts as the most recently serviced and orders after every waiting task. Waiting tasks are compared by p->scx.runnable_at. No cap. ⭐

💖 RETURN 💖

true if a should run after b.

🔥 SEE ALSO 🔥

Kernel file ./kernel/sched/ext/ext.c plus this whole friend group of related pages:

This page is scx_prio_less(9), source/version ./kernel/sched/ext, dated October 2026. Go be iconic with your task ordering, bestie. 🎀💜

📦 where this page comes from