OMVExtras InstallScript or OMV itself is changing cpufrequtils GOVERNOR during installation

What is the output of:

grep GOVERNOR /etc/default/cpufrequtils

grep GOVERNOR /etc/default/openmediavault

This is done by the cpufreq Salt state.

The install script is setting OMV_CPUFREQUTILS_GOVERNOR in /etc/default/openmediavault and then running omv-salt stage run prepare. Salt should be doing the right thing and the install should be doing the right thing as long as /etc/default/cpufrequtils exists before starting the script.

Quote from ct100

did some tests and the GOVERNOR change in my "/etc/default/cpufrequtils" file happens at line 282 of the InstallScript during this command:
Code

That makes sense. The install script changes it after that line but omv changes the file that OMV is sourcing. I guess I need to get the value in /etc/default/cpufrequtils and store before omv is installed OR add an argument to the script to set it. Leaning toward the latter since most people don't know what to set it to.

Is the schedutil governor better for ARM devices? If so, why not let the cpufrequtils Salt state do the job? In that case i only need the output of salt-call grains.item osarch due the fact that i do not have an ARM device.

I guess the code should look like:

{%- set governor = salt['pillar.get']('default:OMV_CPUFREQUTILS_GOVERNOR', salt['grains.filter_by']({
    "default": "ondemand",
    "amd64": "conservative",
    "i386": "conservative",
    "armhf": "schedutil",
    "arm64": "schedutil",
    "armel": "schedutil",
}, grain="osarch")) -%}

Did i miss an architecture?

What is the default on a ARM Debian derivate like RaspiOS?

Quote from ct100

schedutil is recommended for heterogeneous CPU topologies like ARM big.LITTLE or Intel CPUs with different size cores because it supports energy aware scheduling. So it can correctly schedule tasks between small and big cores.

https://www.kernel.org/doc/htm…heduler/sched-energy.html

https://www.phoronix.com/news/Linux-5.7-Schedutil-P-State

I don’t know how to automatically detect a heterogeneous CPU in Linux. Some models have different max clock speeds for small and big cores. With “cat /proc/cpuinfo” the CPU variant & part parameter is different between CPU cores at least for ARM.

RK3588s on Armbian example:

Code

# cat /proc/cpuinfo
processor       : 0
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x2
CPU part        : 0xd05
CPU revision    : 0

processor       : 1
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x2
CPU part        : 0xd05
CPU revision    : 0

processor       : 2
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x2
CPU part        : 0xd05
CPU revision    : 0

processor       : 3
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x2
CPU part        : 0xd05
CPU revision    : 0

processor       : 4
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x4
CPU part        : 0xd0b
CPU revision    : 0

processor       : 5
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x4
CPU part        : 0xd0b
CPU revision    : 0

processor       : 6
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x4
CPU part        : 0xd0b
CPU revision    : 0

processor       : 7
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x4
CPU part        : 0xd0b
CPU revision    : 0

Serial          : XXXXXXXXXXXXXXXXX

Display More

Display More

I don't want to make it too complicated. OMV is trying to use the best possible setup, but everything should be within reason and simple. So you suggest to default the governor to schedutil as shown in the code in my previous post? If users want a different one, they can use the environment variable to customize it.

I am working on testing changes I made to the install script. I noticed on a fresh install on my Orange Pi 5 Plus that the governor is set to ondemand by default by Armbian.

The kernel does support schedutil.

CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y

I did notice the kernel defaults to schedutil as well.

CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL=y

Any idea why Armbian is not setting the default to schedutil on this bigLittle board? I think the install script was actually doing something better by using the kernel's default governor when /etc/default/cpufrequtils doesn't exist.

Quote from ct100

They might use the same base files for all images. I don't think this is intentional since schedutil is definitly correct for big.LITTLE.

I agree. According to this article, schedutil is the default for all arm cpus starting with the 5.9 kernel - https://www.phoronix.com/news/Linux-5.9-Power-Management

Quote from ct100

Maybe read out Kernel default governor on Armbian and skip cpufrequtils file. Also could get rid of taskset list for big.LITTLE with schedutil.

I think I will since the code is already written in the install script to figure this out.

Quote from ryecoaaron

I agree. According to this article, schedutil is the default for all arm cpus starting with the 5.9 kernel - https://www.phoronix.com/news/Linux-5.9-Power-Management

Anything i have to do? Which osarch is affected? armhf, arm64 or armel?

Quote from votdev

Anything i have to do? Which osarch is affected? armhf, arm64 or armel?

OK, based on

Quote

Making Schedutil the default governor on ARM and ARM64 (AArch64). This follows Intel P-State working to transition to Schedutil by default as well.

i will set the default governer to schedutil for arm64.

Quote from votdev

Anything i have to do?

I think it makes sense to make the default schedutil for arm* since it is the default in the kernel.

Quote from ryecoaaron

I think it makes sense to make the default schedutil for arm* since it is the default in the kernel.

OK

Quote from ct100

Could you skip the ionice/taskset part of the installscript when schedutil governor is detected? Or at least add a parameter for the script to skip the part?

It makes no sense to taskset the processes because schedutil moves them between small and big cores already.

I just finished testing and uploaded the new version of the install script that does skip the ionice setup when schedutil is the governor.

installScript/install at master · OpenMediaVault-Plugin-Developers/installScript

script that installs omv-extras and openmediavault if not installed already. - OpenMediaVault-Plugin-Developers/installScript

github.com