the NixOS service

the scheduler is now also a flake package and a NixOS module. running sudo ./target/release/scx_soryu by hand still works — the service is an addition, not a replacement.

adding it to copland

flake.nix inputs:

scx-soryu.url = "github:elwrcl/scx_soryu/bmq";

in the configuration:

imports = [ inputs.scx-soryu.nixosModules.default ];

services.scx-soryu = {
  enable = true;
  notify.user = "elars";   # desktop notification on ejection
};

that's it. the defaults are measured values: sliceUs = 1000 (the same compile took 4m49s at 4194 and 4m39s at both 1000 and 500), starveMs = 128, boostOnWake = false (boost-on-wake.md), timeoutMs = 5000, reportSec = 60.

to turn it off: services.scx-soryu.enable = false; or systemctl stop scx-soryu. either one falls back to EEVDF immediately.

"something happened and nobody noticed"

an ejection is a silent event: the kernel drops the scheduler, every task falls back to default kernel scheduler, and nothing on the desktop says so. three layers were added to fix that.

1. the loader says so, loudly. ejection used to be a bare Error: ... line printed by anyhow — easy to scroll past in a terminal, unlabeled and unsearchable in the journal. now it's two ERROR-level lines:

scx_soryu was ejected by the kernel: EXIT: runnable task stall (...)
all tasks are back on default kernel scheduler; the scheduler is NOT running

2. systemd retries three times, then gives up. Restart=on-failure, 3 starts in 5 minutes. a transient load spike recovers on its own; a persistent problem doesn't flap forever — it lands in failed.

3. failed triggers a desktop notification. a second unit bound with OnFailure= finds the user's session bus and calls notify-send --urgency=critical. if there's no session, it exits quietly (no notification, no error either).

either way, the full story is in the journal:

journalctl -u scx-soryu -n 200

telemetry noise

the loader prints four lines a second — fine in a terminal, a disaster in the journal. --report-sec was added; the service uses 60. shutdown is still checked once a second regardless, so systemctl stop isn't slowed down.

to see live status while the service is running:

sudo scx_soryu --monitor 3

verified in a VM

nixosConfigurations.servicevm — the same test VM, but running the scheduler as a service instead of by hand. the checks that were run against it:

check	result
comes up at boot	`active`, `sched_ext=enabled`
clean `systemctl stop`	`inactive`, `sched_ext=disabled`, not `failed`
restarts	`active`, `enabled`
repeated SIGKILL	2 restarts, then `failed` — no flapping
journal	`Start request repeated too quickly` + `Failed with result 'start-limit-hit'`

a clean systemctl stop mattered: SIGTERM reaches the loader and drops the struct_ops link, so unload is clean and the unit isn't marked failed.

packaging note

packages.default builds inside the sandbox: the BPF object is compiled against scx_utils's vendored vmlinux.h, then CO-RE-relocated against the running kernel's BTF at load time. so the build doesn't depend on the running kernel — /sys/kernel/btf/vmlinux is only needed at run time.

(the src/bpf/vmlinux.h sitting in the repo turned out unused — deleting it, the build still passes the same way. it was already gitignored.)

3.4 KiB Raw Permalink Blame History