RE: [PATCH] cpufreq: governor: Ensure sufficiently large sampling intervals

["Doug Smythies" <dsmythies@telus.net>]

On 2017.12.17 17:16 Rafael J. Wysocki wrote:

> After commit aa7519af450d (cpufreq: Use transition_delay_us for legacy
> governors as well) the sampling_rate field of struct dbs_data may be
> less than the tick period which causes dbs_update() to produce
> incorrect results, so make the code ensure that the value of that
> field will always be sufficiently large.
>
> Fixes: aa7519af450d (cpufreq: Use transition_delay_us for legacy governors as well)
> Reported-by: Andy Tang <andy.tang@nxp.com>
> Reported-by: Doug Smythies <dsmythies@telus.net>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> drivers/cpufreq/cpufreq_governor.c |   19 ++++++++++++++++---
> 1 file changed, 16 insertions(+), 3 deletions(-)
>
> Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
> ===================================================================
> --- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
> +++ linux-pm/drivers/cpufreq/cpufreq_governor.c
> @@ -22,6 +22,8 @@
> 
> #include "cpufreq_governor.h"
> 
> +#define CPUFREQ_DBS_MIN_SAMPLING_INTERVAL	(2 * TICK_NSEC / NSEC_PER_USEC)
> +

Left over from the other thread on Friday I was testing both the above and
the 1 TICK version:

+#define CPUFREQ_DBS_MIN_SAMPLING_INTERVAL	(TICK_NSEC / NSEC_PER_USEC)

I tested periodic workflows at around 35% average load with work/sleep
frequencies from 100 to 2100 hertz, for both 250 Hertz kernels
(4 millisecond TICK) and 1000 Hertz kernels (1 millisecond TICK)

The 1 TICK version does have a "nosier" response than the 2 TICK version,
but both seem to work fine. Neither are worse than the schedutil response
for the same test.

I'd be O.K. with either the 1 TICK or 2 TICK versions.

... Doug