Messages in this thread | | | From | "Doug Smythies" <> | Subject | RE: [PATCH v4 1/6] x86,sched: Add support for frequency invariance | Date | Thu, 28 Nov 2019 14:48:27 -0800 |
| |
Summary: There never was an issue here.
Sorry for the noise of this thread, and the resulting waste of time.
On 2019.11.26 23:33 Doug Smythies wrote: > On 2019.11.26 07:20 Giovanni Gherdovich wrote: >> 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.
No it 's not.
Issues with my Sandy Bridge, i7-2600K, test computer and kernel 5.4 seem to be because it is running an older Ubuntu server version, apparently somewhat dependant on cgroup V1 and their cgmanager package. I am unable to remove the package to test further because I do use VMs that seem to depend on it.
In the kernel configuration when CONFIG_UCLAMP_TASK_GROUP=y the computer behaves as though the new parameter "cpu.uclamp.min" is set to max rather than 0, but I can not prove it.
>>> 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:
I failed to mention that was brand new Ubuntu server 20.04 development version installation, which turns out to have been an important omission.
>>> >>> 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.
I took the disk from the Haswell computer and put it in the Sandy Bridge computer, and then everything was fine:
Kernel 5.4 intel_cpufreq/schedutil: 3636 seconds Kernel 5.4 + gg 6 intel_cpufreq/schedutil: 2427.6 seconds Ratio: 0.67 which is consistent with previous Sandy Bridge results
...
Those above kernels included:
CONFIG_UCLAMP_TASK_GROUP=y
Which cause my older Ubuntu server edition using the intel_cpufreq/schedutil to respond much like the performance governor, as reported the other day and above.
I also booted the Sandy Bridge computer, with its original disk, with the kernel command line containing:
cgroup_no_v1=all
and, while it complained during boot, it did work as expected using the intel_cpufreq/schedutil driver/governor.
... Doug
| |