On Wed, Jul 12, 2017 at 6:51 PM, Leonard Crestez <leonard.crestez@xxxxxxx> wrote: > On Wed, 2017-07-12 at 13:36 +0200, Rafael J. Wysocki wrote: >> On Wed, Jul 12, 2017 at 1:29 PM, Leonard Crestez >> <leonard.crestez@xxxxxxx> wrote: >> > >> > This checks that the cpufreq driver actually sets the requested >> > frequency. >> This won't work on modern x86 with APERF/MPERF (see recent commits in >> that area). > > This test should be skipped if the cpu always adjusts it's own > frequency dynamically. It should check if scaling_set_speed won't > reflect in cpuinfo_cur_freq, but I'm not sure how to do that reliably. Well, this is my concern, actually. > I checked with the intel_pstate driver and it's already skipped in this > test because no userspace governor is available. This could be a way to > check if the CPU supports targetting a precise constant frequency. > > Or are you saying that cpuinfo_cur_freq in general shouldn't be > expected to just return the current frequency but also adjust for time > spent in various idle states? On x86 cpuinfo_cur_freq shouldn't be expected to return the frequency requested by the driver. After the recent changes, if the APERF and MPERF feedback registers are available, arch code will use them to compute the current frequency as seen by the CPU which is not guaranteed to be equal to whatever has been requested by the cpufreq driver for various reasons. > It seems to me that if you want to track > the current load it might be better to report this through different > more explicit mechanism. > > In particular imx already supports cpuidle states where the arm core > clock is turned off and later resumed but this has no effect on > cpuinfo_cur_freq. I guess you could just blacklist x86 overall in this test. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
