Possibilty to use the latest kernel (6.18) with RPi4 using their next branch?

Troubleshooting
1

Raspberry Pi OS makes it possible to use the next/upcoming LTS kernel using their next branch to go from current 6.12 kernel to 6.18. Is this also possible using DietPi?

2

It should be possible to use the same tools as on RPI OS. Like rpi-update

3

I will try that. Thank you.

4

Be aware, 6.18 has not been officially released yet for RPi, it still has quite some problems:
https://github.com/raspberrypi/linux/issues?q=is%3Aissue%206.18

But upgrade went smooth on my RPi 3B+

rpi-update rpi-6.18.y
5

Thank you for that! I have done it on my RPi5 running RPi OS and haven’t yet noticed any negative impact. I don’t know if it is the new “sheaves” feature but 6.18 has transformed all my lower end computer into smoother machines.

6

Sheaves is an opt-in feature but I can not find info how to activate it. How did you do it?
Looks like its not activated, no output from

/sys/kernel/slab/slub_stats
7

I haven’t activated it so that is probably not what has made my computers “smoother”. I wonder then what it might be.

8

I was wrong, it was opt-in until 6.18. But it still looks like it’s not enabled in the rpi kernel. Sheaves should replace partial slabs, but it looks like they are still active

grep SLUB /boot/config-$(uname -r)
CONFIG_SLUB=y
# CONFIG_SLUB_TINY is not set
# CONFIG_SLUB_STATS is not set
CONFIG_SLUB_CPU_PARTIAL=y
CONFIG_SLUB_DEBUG=y
# CONFIG_SLUB_DEBUG_ON is not set

Same on my Debian VM, I guess we have to wait a bit more :slight_smile:

9

Thank you for all the help you have given me. This is very interesting and really makes me wonder what then could have made this difference. I am quite sure it is no placebo but I understand that means little to others.

10

I did a bit more research and depending on the source they say:

  • it’s always active in kernel 6.18 and there is no way to check for a config flag or something similar
  • other sources say with CONFIG_SLUB_CPU_PARTIAL=y it’s not active

I have also not so much knowledge about the kernel stuff and just relay on external sources.

It’s also possible that just a reboot of a long running machine let it feel “smoother” :sweat_smile:

Aynways, I did some benchmarks, on the RPi 3B+ and also in the VM (4 cores, 4GB RAM).
I did

  • 3 runs of (hackbench -g 20 -l 10000) and
  • 3 runs of stress-ng --malloc 4 --malloc-bytes 32K --timeout 60s --metrics-brief
    on each machine and calculated the averages:

The results for hackbench are runtime in seconds.
The results for stress-ng are bogo ops/s (real time).

VM

6.12.57+deb13-amd64 6.18-amd64
hackbench 45.2 24.4
stress-ng 14 607 100 14 777 501

RPi 3B+

6.12.63-v8+ 6.18.1-v8+
hackbench (time in seconds) 185.68 165.4
stress-ng (bogos ops/s) 1 946 871 1 959 804

I did then some additional runs with hackbench to double check the results.
So no real performance enhancement (stress-ng ops/s identical) but with kernel 6.18 the runtime / latency on the

  • VM was reduces by around 44%!
  • RPi 3B+ only around 10%.

@38dietpi what machines do you run with kernel 6.18?

I guess save to say it’s active, but sheaves is not the only improvement in 6.18
https://kernelnewbies.org/Linux_6.18

11

Nice test!

I am running it on an i3-7100U, another i3 (Haswell) and my RPi5. I believe I have noticed the biggest differences on the i3s. Before there was often judder/lags when opening GNOME’s application screen or when dragging the mouse up to the left and get an overview in KDE Plasma. Now it never lags and when windows open they smoothly appear and not like it has loaded 90% really quick but the last 10% takes some more/additional time. I haven’t noticed any apparent speed up e.g. things using less CPU.

1 Like