mt7622: switch default CPU governor to ondemand

[graysky2]

The most common CPU governor in the OpenWRT project is currently ondemand (see below). Switch mt7622 over to it as well. This commit also updates the default config.

Audit the code by running the following and then analyzing the results:
find -name 'config-5.*' -print0 | xargs -0 grep 'CONFIG_CPU_FREQ_DEFAULT_GOV.*=y'

ondemand: 16
performance: 5
schedutil: 5
userspace: 2

Build system: x86_64
Build-tested: ramips/mt7621

Signed-off-by: John Audia graysky@archlinux.us

[nasbdh9]

Not configuring CONFIG_SND_SOC_MT6359 causes build break

If you just change the default governor, can edit it manually

[graysky2]

@nasbdh9 - I test built it and did not get an error. I added that line back and adjusted the PR.

[nasbdh9]

@nasbdh9 - I test built it and did not get an error. I added that line back and adjusted the PR.

CONFIG_SND_SOC_MT6359
It should be left as is, not changed...

[graysky2]

@nasbdh9 - I am confused. make kernel_menuconfig CONFIG_TARGET=mediatek_mt7622 wanted to remove it and the others in the PR. I thought your last comment was that removing it would cause breakage?

I think I will re-scope this PR to only change the default governor rather than doing that plus refreshing the default config.

[nasbdh9]

root@OpenWrt:~# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
ondemand
ondemand
root@OpenWrt:~# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
300000 437500 600000 812500 1025000 1137500 1262500 1350000
300000 437500 600000 812500 1025000 1137500 1262500 1350000
root@OpenWrt:~# lscpu
Architecture:            aarch64
  CPU op-mode(s):        32-bit, 64-bit
  Byte Order:            Little Endian
CPU(s):                  2
  On-line CPU(s) list:   0,1
Vendor ID:               ARM
  Model name:            Cortex-A53
    Model:               4
    Thread(s) per core:  1
    Core(s) per cluster: 2
    Socket(s):           -
    Cluster(s):          1
    Stepping:            r0p4
    CPU max MHz:         1350.0000
    CPU min MHz:         300.0000
    BogoMIPS:            25.00
    Flags:               fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
Vulnerabilities:
  Itlb multihit:         Not affected
  L1tf:                  Not affected
  Mds:                   Not affected
  Meltdown:              Not affected
  Spec store bypass:     Not affected
  Spectre v1:            Mitigation; __user pointer sanitization
  Spectre v2:            Not affected
  Srbds:                 Not affected
  Tsx async abort:       Not affected

looks good now

[graysky2]

This PR should be placed on hold until there is a proper fix for the potential to freeze on boot due to a firmware bug. See: https://forum.openwrt.org/t/belkin-rt3200-linksys-e8450-wifi-ax-discussion/94302/1490

EDIT: #5025 fixes the potential to freeze issue.

[nbd168]

I thought schedutil was meant to be an improvement over ondemand. Shouldn't we use that one?

[graysky2]

@nbd168 - It depends on use case in my experience. For example, I get consistently lower throughput to wireless clients using schedutil on my RT3200 vs using ondemand albeit, I have ondemand tuned to be more sensitive:

echo 5 > /sys/devices/system/cpu/cpufreq/policy0/ondemand/up_threshold
echo 10 > /sys/devices/system/cpu/cpufreq/policy0/ondemand/sampling_down_factor

Speed test downloading to iPhone 13 on 5GHz radio:

• ondemand: 475.5 ± 3.5 Mbps download (n=4 tries)
• schedutil: 409.3 ± 3.5 Mbps download (n=4 tries)

I didn't capture the time_in_state during the tests (cat /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state) but just watching the CPU freq in htop during the test, I can see that ondemand keep the CPU freq higher more of the time which is consistent with the higher average throughput.

[lynxthecat]

ondemand: 475.5 ± 3.5 Mbps download (n=4 tries)
schedutil: 409.3 ± 3.5 Mbps download (n=4 tries)

It would be interesting to know how both of these compare with 'performance'.

Has any analysis been done to consider the effects of the scheduler on SQM and/or the CAKE algorithm? Couldn't that be more significant than considering raw throughput at these high levels?

[graysky2]

You can try it... I use a RPi4 for my routing and have the SQM there.

[Ansuel]

@graysky2 we should REALLY understand why userspace was set in the first place... userspace locks the freq to a fixed value and the freq needs to be changed from userspace... So we have some scripts that does that? Does this target have problem with some freq?

From me this change is ok but it would be worth to investigate why it wasn't done from the start.

[graysky2]

we should REALLY understand why userspace was set in the first place

I believe it was set to performance due to the hang-on-reboot issue which has since been fixed. See: #5025

@dangowrt - please correct me if I am mistaken.

[Ansuel]

@graysky2 yes i remember that commit, i didn't remember if it was exactly related to mt7622... if that's the reason than OK FOR ME to use ondemand again... problem of schedutil is that it requires correct driver use and stuff to handle bw request and afaik not a lot of target does that... (so this is why in some condition you have worse perf... the driver never say what is the correct amount of work that is currently or will do...)

[graysky2]

I also prefer ondemand. See tests against schedutil above.

[lynxthecat]

But surely it's not just about raw performance; schedutil may offer a better performance to power ratio or so? I mean how meaningful is it just to compare throughput and conclude that ondemand is better?

[Ansuel]

think is that these are router and even at max freq they don't consume that much... reality is that using a too much conservative or power aware sched may result in worse perf as it can react to peak traffic slowly. An user can totally use a custom gov if he really wants tho :D

[lynxthecat]

Hmm. But from some internet searching looks like schedutil is technically superior? Albeit I've not studied this in great detail.

https://lwn.net/Articles/682391/

[Ansuel]

@lynxthecat it is for everything else like normal system and phones.... it's not for router with legacy driver and basic cpuscaling and idle state... as I said to make schedutil works correctly it needs to be aware of the task so one of the reason of ondemand giving better perf than schedutil is the fact that the driver doesn't really comunicate to the system the amount of load that will generate.