Lulo – Scheduler

The scheduler is Lulo’s most substantial subsystem: a privileged, continuously re-enforcing /proc watcher that resolves each process to exactly one sparse profile – by exclusion, window focus, explicit rule, or background fallback – and applies nice, scheduling policy, RT priority, and I/O priority directly through syscalls every interval.

Table of Contents

1. The shape of the scheduler
2. Config model
3. Profiles as sparse overlays
4. Rules and matchers
5. Policy resolution order
6. The enforcement loop
7. How policy is applied
8. Dynamic policy: focus and background
9. Tunables and presets
10. The SCHED page
11. Design notes
12. See also

1. The shape of the scheduler

Lulo’s scheduler is a policy layer for Linux process priority. It is closer to a compact policy daemon than a one-shot chrt / renice wrapper: it loads file-backed config, scans every process on a fixed interval, classifies each one, and applies scheduling attributes – then does it all again on the next tick so policy stays enforced as processes come and go.

Only the privileged daemon lulod-system ever issues a scheduling syscall. The engine lives in src/daemon/lulod_system_sched.c (about 2,000 lines); per-process metadata collection is shared code in src/shared/lulo_proc_meta.c.

2. Config model

The config is a directory tree, not one large DSL file. The root is /etc/lulo/scheduler (overridable via LULOD_SYSTEM_CONFIG_DIR).

Only regular files ending in .conf (and not dot-files) are loaded, gathered with scandir + alphasort so the load order is lexical – which is why the shipped files are numbered (10-audio-rt.conf, 14-exclude-lulo.conf, …). All three parsers share the same strict line handling: trim, skip blanks and #/; comments, require key=value, and treat an unknown key as a hard parse error. A missing scheduler.conf is non-fatal; the defaults below are seeded before parsing.

Global settings

The shipped example lowers the cadence to watcher_interval_ms=750.

3. Profiles as sparse overlays

A profile describes how a matched process should be treated – but only the fields it actually sets. Every value field is paired with a has_* flag, and an unset field means “leave this attribute unchanged.” A profile is therefore a sparse overlay, not a full scheduling spec.

Profiles are sorted by a synthetic “aggressiveness” score (policy rank, plus RT priority, plus 20 − nice, with disabled profiles pushed down) so the more forceful ones sort first in the UI. Some shipped examples:

Because a profile only writes the dimensions it sets, different profiles compose on orthogonal axes instead of clobbering each other – and resolution always picks exactly one winner per process, so there is no double-apply.

4. Rules and matchers

Rules decide which profile applies to which processes. A rule is enabled by default and carries a matcher kind, a glob pattern, and a target profile (or an exclude flag).

Matching is plain fnmatch glob against a field of the process’s metadata. Six matcher kinds map to six fields:

The exe matcher tries the full path and then the basename, so pattern=jackd matches /usr/bin/jackd. Crucially, unit and slice are derived from the cgroup path, not queried from systemd – so the whole scheduler stays systemd-API-free while still classifying by unit and slice. This is the same cgroup structure you can browse on the Cgroups page.

Rules are scanned in a sorted order and the first enabled match wins. An exclude match drops the process completely (no profile, no focus, no background). A non-exclude match whose target profile is disabled or missing is skipped, so a lower-priority rule can still apply.

5. Policy resolution order

For every process, the scan resolves a single effective profile in a strict precedence: exclusion → focus override → explicit rule → background fallback.

Focus matches a process when it is the exact focused PID (verified by start-time), or shares the focused window’s systemd unit, or shares its cgroup – so focusing an app boosts its whole unit/cgroup, not just the one window-owning thread. A process is “app-scope” for the background fallback when its cgroup contains /app.slice/ or /background.slice/, or its unit begins with app- (each gated by the matching background_match_* flag). Anything that falls through all four steps is left exactly as the kernel had it.

6. The enforcement loop

lulod-system runs one poll() loop over its control socket with a computed timeout. When the timeout expires it rescans /proc and reapplies policy, then reschedules for watcher_interval_ms later (clamped to at least 100ms). A focus update or a config reload triggers an immediate rescan rather than waiting for the next tick.

Each scan drops any stale focus target (start-time mismatch), iterates the numeric /proc entries, collects each process’s metadata, resolves its profile, reads its current scheduling state, applies the target, and records a live row. The whole tree is re-evaluated every interval – that continuous re-enforcement is what makes the scheduler hold policy over time instead of losing it the moment a process re-execs or a new one spawns.

7. How policy is applied

Applying a profile is idempotent: each attribute is written only when the current value differs from the target, so a steady-state system issues almost no syscalls. Three mechanisms cover the four dimensions:

For fifo / rr the RT priority is the profile’s rt_priority (or a floor of 1 if unset); non-RT policies force priority 0. The I/O target has a subtle promotion: setting only io_priority promotes a none-class process to best-effort, and setting only io_class defaults the priority to 4. After applying, the engine re-queries the actual state and reports applied / ok or a per-syscall error – and it suppresses a spurious error when a write “failed” only because the value was already correct (for example an EPERM on a setting that already matched), which keeps the status column quiet for processes it cannot or need not change.

One caveat worth knowing: SCHED_DEADLINE is ranked and labeled (DLN) in the code, but the apply path only ever calls sched_setscheduler with a plain sched_param. It never builds the sched_attr (runtime / deadline / period) that SCHED_DEADLINE requires, and there is no sched_setattr call anywhere – so a profile requesting deadline scheduling would fail to apply. The five working policies are other, batch, idle, fifo, and rr.

8. Dynamic policy: focus and background

Two built-in policies are exposed in SCHED → Rules as the synthetic, display-only rows (focus) and (background). They are configured through scheduler.conf, not separate rule files.

Focus. The focus monitor runs in lulod, which forwards the focused-window PID (and its start-time and provider) to lulod-system. The system daemon re-collects metadata for that PID, verifies the start-time matches (a PID-reuse guard), records the focus target, and runs an immediate rescan. From then on, any process matching that target by PID, unit, or cgroup gets focus_profile. See Focus Providers for how the PID is detected on KDE and GNOME.

Background. Any app-scope process not already excluded, focused, or matched by an explicit rule falls through to background_profile. “App-scope” is decided purely from the cgroup and unit, as described in the resolution order above.

Self-exclusion is config, not code. There is no hardcoded guard preventing the scheduler from renicing its own processes – protection comes entirely from the shipped exclude rules: 14-exclude-lulo.conf (comm glob lulo*), 13-exclude-prio-tools.conf (chrt), plus excludes for dbus, systemd, and rtkit. A deployment that deletes these would let the scheduler manage those processes, so they are part of the contract, not incidental.

9. Tunables and presets

The scheduler controls grew a kernel-tunables layer (commit a3d9b10): lulod-system discovers a curated, allowlisted set of read/write knobs – /proc/sys/kernel/sched_*, cpufreq, intel_pstate / amd_pstate, cpuidle, and SMT control – with every path re-validated through realpath and a prefix check so symlink or traversal escapes are rejected.

Presets are key=value files of absolute tunable paths applied atomically, each path re-validated at apply time. The tunables_startup_preset setting auto-applies a named preset on every reload, and preset application is gated behind the RW authorization lease (see Process Model & IPC). This is the scheduler-side counterpart to the standalone Tune page; notably, the RT-throttling knobs (sched_rt_runtime_us / sched_rt_period_us) are exposed here for you to set, but the watcher never auto-tunes them – protection against RT starvation is left to your rt_priority choices and these knobs.

10. The SCHED page

The SCHED page has five subviews, switched with Shift-Tab.

The Live list shows the resolved profile and applied state per process, but not which rule won – the (focus) / (background) rule name and the focused: yes/no flag appear only in the detail pane and the status bar (which reads view ... pane ... focused ... watcher <ms>).

Editing workflow

lulo is not a text editor; it uses structured navigation plus external-editor handoff.

System files are committed through the privileged path, so editing /etc/lulo config never requires the TUI itself to run as root.

11. Design notes

• Continuous, idempotent re-enforcement. The full /proc tree is rescanned and reapplied every interval, but syscalls fire only when a value actually needs changing – so policy is held without log churn or wasted writes.
• One winner per process. Sparse-overlay profiles plus single-winner resolution mean mechanisms compose on orthogonal dimensions and never fight each other.
• PID-reuse safety. Focus targeting is keyed on PID and /proc start-time; a mismatch drops the target instantly.
• systemd-aware without systemd APIs. Unit and slice classification is derived from the cgroup path, so the engine needs no D-Bus or libsystemd in the hot path.
• A compact policy daemon. Continuous scanning, dynamic focus/background policy, and live reporting make this much more than a chrt/renice front-end.

12. See also

• Architecture Overview
• Focus Providers – how the focused PID reaches the scheduler
• Process Model & IPC – the privileged path and RW lease
• Cgroups View – the cgroup/slice/unit structure matchers read against
• CPU & Process View – the live processes being managed