Whatever the reason (kernel update, scx-scheds 1.0.12-2, pkgbuild options changed, bpf updated). Scx can be updated (i have use arch package to test). I think this is very useful for a rpi, whatever you think of it.
For lavd, which seems to be a recommended generalist scx. You need to remove the option --no-core-compaction.
âperformance Run the scheduler in performance mode to get maximum performance. This option cannot be used with other conflicting options (âautopilot, --autopower, --balanced, --powersave, --no-core-compaction)
sudo nano /etc/default/scx
# List of scx_schedulers: scx_bpfland scx_central scx_flash scx_lavd scx_layered scx_nest scx_qmap scx_rlfifo scx_rustland scx_rusty scx_simple scx_userl>
SCX_SCHEDULER=scx_lavd
# Set custom flags for each scheduler, below is an example of how to use
SCX_FLAGS='--performance'
sudo systemctl enable scx.service
sudo systemctl start scx.service
systemctl status scx.service
systemctl status scx.service
â scx.service - Start scx_scheduler
Loaded: loaded (/usr/lib/systemd/system/scx.service; enabled; preset: disabled)
Active: active (running) since Tue 2025-05-20 10:57:34 CEST; 16min ago
Invocation: b2a9cd53bed341f4ac1099a1c9cb48bc
Main PID: 720 (scx_lavd)
Tasks: 4 (limit: 9027)
CPU: 1.049s
CGroup: /system.slice/scx.service
ââ720 scx_lavd --performance
May 20 10:57:34 bloodmoon-pc bash[720]: monitor: None,
May 20 10:57:34 bloodmoon-pc bash[720]: monitor_sched_samples: None,
May 20 10:57:34 bloodmoon-pc bash[720]: verbose: 0,
May 20 10:57:34 bloodmoon-pc bash[720]: version: false,
May 20 10:57:34 bloodmoon-pc bash[720]: help_stats: false,
May 20 10:57:34 bloodmoon-pc bash[720]: }
May 20 10:57:34 bloodmoon-pc bash[720]: 08:57:34 [INFO] CPU pref order in performance mode: [0, 1, 2, 3]
May 20 10:57:34 bloodmoon-pc bash[720]: 08:57:34 [INFO] CPU pref order in powersave mode: [0, 1, 2, 3]
May 20 10:57:35 bloodmoon-pc bash[720]: 08:57:35 [INFO] scx_lavd scheduler is initialized (build ID: 1.0.12-g091a2ade-dirty aarch64-unknown-linux-gnu)
May 20 10:57:35 bloodmoon-pc bash[720]: 08:57:35 [INFO] scx_lavd scheduler starts running.
scx_lavd -h
weâll have to see about the bug https://github.com/sched-ext/scx/issues/1511
I tried too fast and thereâs still a problem.
scx_lavd --performance
09:42:48 [INFO] Performance mode is enabled.
09:42:48 [INFO] Opts {
autopilot: false,
autopower: false,
performance: true,
powersave: false,
balanced: false,
slice_max_us: 5000,
slice_min_us: 300,
cpu_pref_order: "",
no_futex_boost: false,
no_preemption: false,
no_wake_sync: false,
no_core_compaction: true,
no_freq_scaling: false,
stats: None,
monitor: None,
monitor_sched_samples: None,
verbose: 0,
version: false,
help_stats: false,
}
thread 'main' panicked at rust/scx_utils/src/misc.rs:77:13:
setrlimit failed with error code: -1
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
I donât remember if this is default ?
ulimit -a
real-time non-blocking time (microseconds, -R) unlimited
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 30090
max locked memory (kbytes, -l) 8192
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 30090
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
chatgpt response (and question of github status of ulimit -l)
The error youâre encountering:
setrlimit failed with error code: -1
comes from this line in your code:
panic!(âsetrlimit failed with error code: {}â, res);
This indicates that the call to setrlimit failed when trying to set RLIMIT_MEMLOCK to RLIM_INFINITY. This is a common issue when the executing user lacks the necessary privileges to raise memory locking limits.
This means your current shell session (and thus any process you launch from it) is limited to locking only 8 MB of memoryâfar below the RLIM_INFINITY that your Rust code tries to set with setrlimit.
Why This Matters
Your function:
let new_rlimit = libc::rlimit {
rlim_cur: libc::RLIM_INFINITY,
rlim_max: libc::RLIM_INFINITY,
};
let res = libc::setrlimit(libc::RLIMIT_MEMLOCK, &new_rlimit);
fails because your user does not have permission to raise the limit beyond 8192 KB. The kernel blocks this action, and setrlimit returns an error, causing the panic.
Options to Fix the Issue 1. Temporarily Raise the Limit (if allowed)
In your shell:
ulimit -l unlimited
sudo su
[root@bloodmoon-pc bloodmoon]# ulimit -l unlimited
[root@bloodmoon-pc bloodmoon]# ulimit -a | grep locked
max locked memory (kbytes, -l) unlimited
[root@bloodmoon-pc bloodmoon]# scx_lavd --performance
10:34:51 [INFO] Performance mode is enabled.
10:34:51 [INFO] Opts {
autopilot: false,
autopower: false,
performance: true,
powersave: false,
balanced: false,
slice_max_us: 5000,
slice_min_us: 300,
cpu_pref_order: "",
no_futex_boost: false,
no_preemption: false,
no_wake_sync: false,
no_core_compaction: true,
no_freq_scaling: false,
stats: None,
monitor: None,
monitor_sched_samples: None,
verbose: 0,
version: false,
help_stats: false,
}
10:34:51 [INFO] CPU pref order in performance mode: [0, 1, 2, 3]
10:34:51 [INFO] CPU pref order in powersave mode: [0, 1, 2, 3]
10:34:52 [INFO] scx_lavd scheduler is initialized (build ID: 1.0.12-g091a2ade-dirty aarch64-unknown-linux-gnu)
10:34:52 [INFO] scx_lavd scheduler starts running.
Donât know if itâs secure to launch that with administrator rights but at least it proves thatâs the problem.
As a workaround edit
sudo nano /etc/security/limits.conf
# End of file
* soft memlock unlimited
* hard memlock unlimited
ulimit -l
unlimited
Waiting from an official answer of @Darksky
Wouldnât the problem be limited to the shell session as it seems to be launched with systemd?