Re: [PATCH v4 1/6] x86,sched: Add support for frequency invariance

Giovanni Gherdovich
2019-11-26T15:14:21Z

On Mon, 2019-11-25 at 21:59 -0800, Doug Smythies wrote:
> [...]
> The issue with the schedutil governor not working properly in the 5.4 RC series
> appears to be hardware dependant.
>
> My test computer is Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz., Sandy Bridge.
> On a temporary basis, I acquired a computer with an
> Intel(R) Core(TM) i5-4460 CPU @ 3.20GHz, Haswell,
> and schedutil governor behaviour with the exact same kernels is fine:
>
> That "gitsource" test, "make test" 6 times, first run thrown out:
>
> Kernel 5.4 intel_cpufreq/schedutil: 3411.8 seconds
> Kernel 5.4 + gg 6 intel_cpufreq/schedutil: 1696.7 seconds
> Ratio: 0.49
> Recall you got a ratio of 0.49 with 5th generation, Broadwell.

It's good to hear that we're getting the same performance numbers for this
patchset on all hardware that is not a Sandy Bridge. Thanks for double
checking, independent verification is always valuable.

Now, regarding the 5.4 regression for schedutil you see on Sandy Bridge: can
we move this to the kernel bugzilla? Would you care to open a bug there and CC
me to it? If it's reproducible we should assess it and see what can be done.

I've tried gitsource on 5.3 versus 5.4, using intel_cpufreq + schedutil; I
don't see the drop you're observing, but I don't have a Sandy Bridge readily
available. This is what I see:

Arithmetic mean of elapsed time for gitsource over 5 iterations (seconds):

microarch v5.3 (baseline) v5.4
------------------------------------------------------------------
Haswell 1337.84 +- 0.11% 1336.35 +- 0.12% ( 0.11%)
Broadwell 1335.42 +- 0.08% 1352.54 +- 0.03% ( -1.28%)
Skylake 887.03 +- 1.02% 870.90 +- 1.19% ( 1.82%)

I'm looking around for a Sandy Bridge but I can make no promises at the
moment.

Thanks,
Giovanni