Raspberry Pi images use powersave governor by default

[mechaniputer]

The mainline Linux kernel uses schedutil as the default cpu frequency governor for both arm and arm64 since version 5.9, and now uses it by default on most other platforms as well. Void for x86/x86_64 currently use schedutil by default because of this. However, the Raspberry Pi kernel fork uses powersave instead, and then overrides it using the cpufreq package in Raspberry Pi OS. The developers do not seem inclined to change it since the default setting is overridden by Raspberry Pi OS anyway.

Void Linux does not initially override the default setting, so the default governor that the kernel is compiled with is the one that is used. This makes the system extremely slow until the user overrides the kernel's default setting.

My proposal is to add a sed command to the build templates make the kernel follow the default used in mainline kernels. This seems simpler than adding the cpufreq package to the base images. I believe the change would only affect the templates for rpi-kernel, rpi3-kernel, and rpi4-kernel.

And the change could look like this:
# Set default frequency governor to match mainline kernel
sed -i 's/CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE=y/CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL=y/g' "$defconfig"

Let me know what you think.

System

• xuname:
  Void 5.10.52_1 aarch64 Unknown notuptodate rFF
• package:
  rpi4-kernel-5.10.52_1

Expected behavior

Linux mainline kernel uses schedutil by default, including on arm and arm64.
Void generally follows this default from upstream.
I would expect the default governor for Void to also be schedutil on my Raspberry Pi.

Actual behavior

Void for Raspberry Pi uses powersave and the system is sluggish until the default is overridden.

Steps to reproduce the behavior

Check default cpu governor on Void for Raspberry Pi. Compare to default for x86 and x86_64.

[mikoxyz]

An alternative would be to stop directly using upstream's defconfig, and instead use a defconfig based on upstream's defconfig that's more similar to our arm(64) defconfig.

[mechaniputer]

An alternative would be to stop directly using upstream's defconfig, and instead use a defconfig based on upstream's defconfig that's more similar to our arm(64) defconfig.

That's true, but it would need to be done carefully since there may really be some config settings that are important on some Pi hardware. I don't know for certain whether that is the case. Probably worth doing a diff to see what would actually change and whether it's worth maintaining a separate config over.

[mikoxyz]

That's true, but it would need to be done carefully since there may really be some config settings that are important on some Pi hardware. I don't know for certain whether that is the case. Probably worth doing a diff to see what would actually change and whether it's worth maintaining a separate config over.

True, though there doesn't seem to be too many Pi-specific options in upstream's defconfig (at least in the bcm2711 defconfig.) I've attached a diff for reference.

[ahesford]

cat <<EOF >> /etc/rc.local
echo schedutil > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
EOF

Problem solved. The RPi kernels are not mainline, they come from the Raspberry Pi foundation. We don't change the scheduler from the dfeault there.

[mechaniputer]

Problem solved.

The fact is that defaults matter, and we have the ability change what the default is in Void. If the current default is less desirable than some other default, why wouldn't we change it? Void's mainline kernel overrides some config, and this one can too, if we decide it's worth it. I think it is, but am looking to see if there is a constructive discussion to be had about it.

[paper42]

I think.this should be at least documented in void-docs.

[github-actions]

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.