cpufreq ondemand的sampling_down_factor参数效果和解释不一致

[everything411]

https://github.com/immortalwrt/immortalwrt/blob/59ac244b6dfef370fa19760bc5e59c13d4debf26/package/emortal/cpufreq/files/cpufreq.init#L50

当前的解释为“CPU 检查切换的周期 (ms)。注意：过于频繁的切换频率会引起网络延迟抖动“，见

luci/applications/luci-app-cpufreq/po/zh_Hans/cpufreq.po

Line 67 in eb04509

msgstr "CPU 检查切换的周期 (ms)。注意：过于频繁的切换频率会引起网络延迟抖动"

根据内核文档https://www.kernel.org/doc/html/v5.15/admin-guide/pm/cpufreq.html

sampling_down_factor
Temporary multiplier, between 1 (default) and 100 inclusive, to apply to the sampling_rate value if the CPU load goes above up_threshold.
This causes the next execution of the governor’s worker routine (after setting the frequency to the allowed maximum) to be delayed, so the frequency stays at the maximum level for a longer time.
Frequency fluctuations in some bursty workloads may be avoided this way at the cost of additional energy spent on maintaining the maximum CPU capacity.

也就是说sampling_down_factor是维持在最高频率的周期乘数，当cpu达到up_threshold时，会维持在最高频率持续sampling_rate * sampling_down_factor时间后再次调整频率，也就是说sampling_down_factor越大，维持在最高频率的时间越久。如果要调整“CPU 检查切换的周期”，应该直接改sampling_rate（单位是微秒），而不是sampling_down_factor。调大sampling_down_factor并没有修改检测周期，而是让一个周期的检测在生效时，维持了sampling_down_factor倍的时间。不难注意到一个比较大的sampling_down_factor会倾向于使cpu长时间维持在最高频率，这看起来和本意并不一致。