$ uname -r
5.8.15-rockchip64
$ sudo cat /sys/devices/system/cpu/cpufreq/policy{0,4}/ondemand/sampling_rate
10000
10000
It appears that 10000 seems to be a default (or the minimum value possible). Per https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt 10000 is too low given the cpu_transition_latency:
$ uname -r
5.8.15-rockchip64
$ cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_transition_latency
40000
40000
40000
40000
515000
515000
Given the documented formula cpuinfo_transition_latency * 750 / 1000, it should be (at a minimum) 30000 for cpu0-3, and 386250 for cpu4-5.
Using sysfs to configure cpufreq on boot with the revised sampling_rate seems to make it stable (although uptime is only about 2 days in). I ran periodic load testing to get the ondemand governor to change freq, and this config looks promising. Despite the previously mentioned calculations, i opted to align the sampling_rate with what was present in the 4.4 kernel:
$ tail -n+1 /etc/sysfs.d/*
==> /etc/sysfs.d/cpufreq-policy0.conf <==
devices/system/cpu/cpufreq/policy0/scaling_governor = ondemand
devices/system/cpu/cpufreq/policy0/scaling_max_freq = 1416000
devices/system/cpu/cpufreq/policy0/scaling_min_freq = 600000
devices/system/cpu/cpufreq/policy0/ondemand/sampling_rate = 40000
==> /etc/sysfs.d/cpufreq-policy4.conf <==
devices/system/cpu/cpufreq/policy4/scaling_governor = ondemand
devices/system/cpu/cpufreq/policy4/scaling_max_freq = 1800000
devices/system/cpu/cpufreq/policy4/scaling_min_freq = 600000
devices/system/cpu/cpufreq/policy4/ondemand/sampling_rate = 465000
$ for i in 0 1 2 3 4 5; do sudo cat /sys/devices/system/cpu/cpu${i}/cpufreq/scaling_{governor,min_freq,max_freq}; done;
ondemand
600000
1416000
ondemand
600000
1416000
ondemand
600000
1416000
ondemand
600000
1416000
ondemand
600000
1800000
ondemand
600000
1800000
one of two boards are already crashing, not sure if its the board or what. going to switch to "performance" governor and see. figured i'd share the sample_rate delta info though.