want rtl8192cu back, pls.
btw, sched-ext-1.0.9 released.
The flags can be found on the command line with each scheduler with -h. Example scx_rusty -h. From what I can determine like you are finding out is more efficient use of the cpu. There is an advantage with scx running geekbench6 with the score also.
I know nothing about that and have no clue why RPi is not enabling it either.
It will not compile. I suspect the aarch64 issue crept back in.
I built the v6.14-rc1 kernels but have no sound and video in my movies are jerky. Too tired to prep to submit issue to RPi tonight. I have to build a kernel just like they way they do so they will pay attention.
Iâve got one those raspberry pi m2 hats in today. Tricky little things to put on. Iâm trying to think if thereâs a way to move my user over to the SSD.
@Darksky If you read the links, it explains a lot.
Basically: itâs the use of page sizes larger than 4k for the gpu (and not only for the cpu). Only from 6.13 and apparently you just need to compile with CONFIG_TRANSPARENT_HUGEPAGE.
This comes from the raspberry GPU software engineer and itâs normal that itâs not used officially since pios focuses on 6.12. What I donât know is whether they make different configurations depending on the kernel or whether itâs global. If itâs differentiated, you have to ask them why they havenât put it in for 6.13 and 6.14, otherwise youâll have to wait 2 years for them to support it in their kernel. And in between, itâs up to the maintainer to set the flag.
And there you have it â Big/Super Pages are now fully enabled in V3D. The only requirement to activate this feature in any given kernel is ensuring that
CONFIG_TRANSPARENT_HUGEPAGEis enabled.
When I read your links the other day it seems CONFIG_TRANSPARENT_HUGEPAGE is for the pi4/5 only. My main question in my mine was with the pi4 kernel a lot of users here boot several other pi devices. Would they even boot with this enabled. That was the first thing that came to my mind as why RPi could be avoiding this. They like providing one kernel for all. It might not be as much of an issue with the 16k kernel.
If memory constrained on embedded, you may want to say N.
Then secondary thoughts was with using sch_scheds or not.
Which pi device do you have?
I have a pi5.
I thinks that donât touch pi 1-3, just v3d (pi4/5) and enabling that will be use only if you have pi4/5 (v3d) and harmless for other. And itâs just for 3d (gaming emulationâŠ) not related to 16k kernel itself.
There will be a Download button here when the new pi5 kernel is through compiling. Unpack artifacts.zip and install the 2 kernel packages.
https://gitlab.manjaro.org/manjaro-arm/packages/core/linux-rpi5-mainline/-/jobs/15404
Let me know how it turns out.
Added:
I guess it is working but so far I can not tell much difference. I ran geekbench6 and itâs score for multicore has taken a hit of @200 points since last time I ran it. I do not know yet what caused thatâŠ
[ 6.788137] systemd[1]: Finished Load Kernel Module drm.
[ 7.890242] v3d 1002000000.v3d: [drm] Using Transparent Hugepages
[ 7.994786] [drm] Initialized v3d 1.0.0 for 1002000000.v3d on minor 0
I have made simple test and at least no regression
glmark2 1909/1911
glmark2-es 1918/1915
vkmark 1714/1716
aquarium in firefox 42 for 5000 fishes
Need to test with a 4k kernel if this is compatible with wine
Give it @15min for the kernel to compile.
@Rip2 rtl8192cu back in this kernel.
https://gitlab.manjaro.org/manjaro-arm/packages/core/linux-rpi4-mainline/-/jobs/15407
Itâs ok for wine. So probably for all applications requiring a 4k kernel.
ok, TRANSPARENT_HUGEPAGE build as âyâ not âmâ, how to remove for test?
@pelwell has zeroed in on the issue with v6.14-rc1. He is saying it will not be a simple fix so I told him I was in no hurry.
sched-ext-1.0.9, they edit PKGBUILD.
build() {
cd $_gitname
arch-meson . build
-D openrc=disabled \
-D libbpf_a=disabled \
-D bpftool=disabled \
-D b_lto=true \
-D b_lto_mode=full \
-D cargo_home="$srcdir"/scx
meson compile -C build
}
It does not change the fact it will not compile on aarch64. Frankly I am getting tired of the sched_ext people. They seem to keep the x86 side doing ok but I believe they have no one to test the aarch64 side. I am beginning wonder if it is worth the effort anymore. To me their scx-scheds are in the infant stage at best. A lot of them do not work and a lot are experimental.
ok, i file a note to AUR sub-forum.
They do not care about aarch64 anymore.
https://github.com/sched-ext/scx/issues/1320
At least one bug report.
1 Like
They asked you a question today and I answered it. Looks like it may be an issue with NUMA. If I remember right PiOS have their own thing going on to have NUMA working. We shall seeâŠ
v6.12.13 / v6.13.2 kernel packages pushed to unstable when the mirrors sync.
v6.14-rc2 upgraded but still does not have sound. I made another post about it just to get on record. I have not heard back from them since opening the issue and they verified no sound.
1 Like
i think itâs SDRAM_BANKLOW=-1 in the eeprom to desactivate numa if you have time to test.
Edit : They have done a patch. Not so bad with scx-scheduler1.0.9 with scx_lavd
systemctl status scx
â scx.service - Start scx_scheduler
Loaded: loaded (/usr/lib/systemd/system/scx.service; enabled; preset: disabled)
Active: active (running) since Tue 2025-02-11 08:53:26 CET; 12min ago
Invocation: fbc419bc08f1486da632883df178b86f
Main PID: 713 (scx_lavd)
Tasks: 4 (limit: 9024)
CPU: 542ms
CGroup: /system.slice/scx.service
ââ713 scx_lavd --performance --no-core-compaction
Feb 11 08:53:26 bloodmoon-pc systemd[1]: Started Start scx_scheduler.
Feb 11 08:53:26 bloodmoon-pc bash[713]: 07:53:26 [INFO] scx_lavd scheduler is initialized (build ID: 1.0.9-g8777ff5d-dirty aarch64-unknown-linux-gnu)
Feb 11 08:53:26 bloodmoon-pc bash[713]: 07:53:26 [INFO] scx_lavd scheduler starts running.
1 Like
scx-scheds-1.0.9-1 pushed to unstable when the mirrors sync.