On 6/25/2021 10:37 AM, Ionela Voinescu wrote: > Quick questions for you: > > 1. When you say you tried a 5.4 kernel, did you try it with these > patches backported? They also have some dependencies with the recent > changes in the arch topology driver and cpufreq so they would not be > straight forward to backport. > > If the 5.4 kernel you tried did not have these patches, it might be best > to try next/master that has these patches, but with > CONFIG_ACPI_CPPC_CPUFREQ_FIE=n, just to eliminate the possibility that > an incorrect frequency scale factor here would affect utilization that > would then affect the schedutil frequency selection. I would not expect > this behavior even if the scale factor was wrong, but it would be good > to rule out. > > 2. Is your platform booting with all CPUs? Are any hotplug operations > done in your scenario? Ionela, I found that set ACPI_PROCESSOR=y instead of ACPI_PROCESSOR=m will fix the previous mentioned issues here (any explanations of that?) even though the scaling down is not perfect. Now, we have the following on this idle system: # cat /sys/devices/system/cpu/*/cpufreq/cpuinfo_cur_freq | sort | uniq -c 79 1000000 1 1160000 73 1400000 1 2000000 4 2010000 1 2800000 1 860000 Even if I rerun a few times, there could still have a few CPUs running lower than lowest_perf (1GHz). Also, even though I set all CPUs to use "userspace" governor and set freq to the lowest. A few CPUs keep changing at will. # cat /sys/devices/system/cpu/*/cpufreq/cpuinfo_cur_freq | sort | uniq -c 156 1000000 3 2000000 1 760000
