# Pi5
over_voltage_delta=500000
arm_freq=2800
#gpu_freq=800 # Caused issues
usb_max_current_enable=1
# Pi5 only. Enable for faster read/writes for
# A2 SD cards. If card supports it you will see
# "mmc0: Command Queue Engine enabled" in dmesg
dtparam=sd_cqe
One window showing cpu usage with htop.
One window compiling a kernel at the same time running the aquarium test page.
The other window showing scx service started.
Been making preparations today to do so as a test for people. I will also have to push my scx-scheds-git package also.
Yeah i recognised htop. You know if you are making a movie about hackers, that is what you put on the monitors
So you are 400mhz faster then me, and my fps is around 55-57 so i guess it makes sense. I can’t overclock because i am on 15watts. It probably can’t take it.
Being new I search for best setup and get different opinions. Following the cachyos forum they seem to settle on this:
● scx.service - Start scx_scheduler
Loaded: loaded (/usr/lib/systemd/system/scx.service; enabled; preset: disabled)
Active: active (running) since Mon 2024-12-02 09:58:30 CST; 7min ago
Invocation: cb5e1ca8b08041558bd7e835b1aa58cb
Main PID: 500469 (scx_lavd)
Tasks: 4 (limit: 9025)
CPU: 903ms
CGroup: /system.slice/scx.service
└─500469 scx_lavd --performance --no-core-compaction
Dec 02 09:58:30 jellyfin systemd[1]: Started Start scx_scheduler.
Dec 02 09:58:31 jellyfin bash[500469]: 15:58:31 [INFO] scx_lavd scheduler is initialized (build ID: 1.0.7-gfa1e12ae-dirty aarch64-unknown-linux-gnu)
Dec 02 09:58:31 jellyfin bash[500469]: 15:58:31 [INFO] scx_lavd scheduler starts running.
Quote:
Basically, --performance is pretty straightforward, it make zero compromise on performance. --no-core-compaction disable core compaction which is a feature meant to save power, which is the opposite of “performance”.
Updated:
I noticed they fixed another aarch64 issue so I rebuilt sch-scheds-git and pushed it to unstable. I switched to commit 246fad9 (which is the fix) in my PKGBUILD as they had build failures in the latest commits above it here.
Cloning into 'scx'...
done.
==> Starting prepare()...
==> Starting pkgver()...
Note: switching to '246fad9aad90aabc212347a0a97af57874ed0930'.
HEAD is now at 246fad9a vmlinux: Increase cpumask size in vmlinux.h for all arch
==> Updated version: scx-scheds-git 1.0.6.r262.g246fad9a-1
==> Starting build()...
It has various files in /boot and some wifi firmware files. You should be up to date with them all. I have no idea what a start test is and what you are talking about what won’t work.
Added:
According to this you need to flash the eeprom with the beta image. Did you do that? Or it also looks like you can just add numa=fake=3 (for pi4) in cmdline.txt. For my pi5 after rebooting:
Looking at those tests make me wonder if numa is worth messing with.
Update:
I ran glmark2 in my xfce with kernel 6.12.1.
With scx-scheds disabled and numa disabled: glmark2 Score: 390
With scx-scheds and numa enabled: glmark2 Score: 394
With scx-scheds enabled and numa disabled: glmark2 Score: 438
Will have to wait and see in 6.13 kernel if the new commits for scx-scheds to make sch-scheds more compatible with numa helps.
Tested with vulkan’s vkmark:
With scx-scheds disabled and numa disabled vkmark score: 1015
With scx-scheds enabled and numa enabled vkmark score: 1023
With scx-scheds enabled and numa disabled vkmark score: 1394
I have no clue why upstream and RPi have been dragging their feet with upgrades the last couple of weeks. I built pi4 6.12.2 for you to test and also me to see if all of my changes were good. It seems to work booted on my pi5.
Linux jellyfin 6.12.1-2-MANJARO-RPI4 #1 SMP PREEMPT Wed Dec 4 18:42:09 UTC 2024 aarch64 GNU/Linux
● scx.service - Start scx_scheduler
Loaded: loaded (/usr/lib/systemd/system/scx.service; enabled; preset: disabled)
Active: active (running) since Wed 2024-12-04 12:54:17 CST; 1min 3s ago
Invocation: 5a3ce6a8629d4eff9a6e77ecfda47daf
Main PID: 922 (scx_lavd)
Tasks: 4 (limit: 8897)
CPU: 596ms
CGroup: /system.slice/scx.service
└─922 scx_lavd --performance --no-core-compaction
Dec 04 12:54:17 jellyfin systemd[1]: Started Start scx_scheduler.
Dec 04 12:54:18 jellyfin bash[922]: 18:54:18 [INFO] scx_lavd scheduler is initialized (build ID: 1.0.7-g246fad9a-dirty aarch64-unknown-linux-gnu)
Dec 04 12:54:18 jellyfin bash[922]: 18:54:18 [INFO] scx_lavd scheduler starts running.
Have not seen any freezes here. Been testing for 3 days. I have given up on NUMA. Seems things are not as good with it enabled. Might have to do with the fake in numa=fake=.
Change SCX_SCHEDULER= to another one to see if there is any change with your system you are using. I found some work better than others here. The scx_rustland was just horrible here with the fish tank. Some times what you are doing makes a differenc with different ones.
Might also get off that beta firmware on your eeprom also if you are on it.
Looks like you are where you should be. Did you install the scx-scheds-git in unstable. It had a fix for freezing due to low memory being allotted.
@Rip2 While doing today’s upgrade on unstable I ran into files being existing on my system. I had forgotten last week that I had built bpf and libbpf from the kernel v6.12 source tree under tools/bpf/bpftools trying to have the latest versions to get scx-scheds to compile before their fix. Today’s upgrade includes the latest libbpf 1.5.0 package and the linux-tools-meta package that is compiled against kernel v6.12 which has bpf v1.5.0.
Do an upgrade and reboot and see if it helps your issue.
