Messages in this thread | ![/](/images/icornerl.gif) | | From | "Doug Smythies" <> | Subject | RE: [PATCH v4 1/6] x86,sched: Add support for frequency invariance | Date | Sat, 23 Nov 2019 23:49:57 -0800 |
| |
Hi all,
The address list here is likely incorrect, and this e-mail is really about a kernel 5.4 bisected regression.
It had been since mid September, and kernel 5.3-rc8 since I had tried this, so I wanted to try it again. Call it due diligence. I focused on my own version of the "gitsource" test.
Kernel 5.4-rc8 (as a baseline reference).
My results were extremely surprising.
As it turns out, at least on my test computer, both the acpi-cpufreq and intel_cpufreq CPU frequency scaling drivers using the schedutil governor are broken. For the tests that I ran, there is negligible difference between them and the performance governor. So, one might argue that they are not broken, but rather working incredibly well, which if true then this patch is no longer needed.
I bisected the kernel and got:
first bad commit: [04cbfba6208592999d7bfe6609ec01dc3fde73f5] Merge tag 'dmaengine-5.4-rc1' of git://git.infradead.org/users/vkoul/slave-dma
Which did not make any sense at all. I don't even know how this is being pulled into my kernel compile. O.K., I often (usually) make a mistake during bisection, so I did it again, and got the same result.
Relevant excerpt from the commit:
diff --cc drivers/dma/Kconfig index 413efef,03fa0c5..7c511e3 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@@ -294,8 -294,8 +294,8 @@@ config INTEL_IOATDM If unsure, say N.
config INTEL_IOP_ADMA - tristate "Intel IOP ADMA support" - depends on ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX + tristate "Intel IOP32x ADMA support" - depends on ARCH_IOP32X ++ depends on ARCH_IOP32X || COMPILE_TEST select DMA_ENGINE select ASYNC_TX_ENABLE_CHANNEL_SWITCH help
If I revert the above, manually, then everything behaves as expected (minimally tested only, so far).
Are others seeing the schedutil governors not working as expected with any of kernels 5.4-rc1 - 5.4-rc8?
I do have a pretty graph of my method of doing the "gitsource" test, but am not ready to post it yet. Here is some gitsource test data, 6 runs of "make test", the first run is discarded:
"gg 6" means this 6 patch set.
Kernel 5.4-rc8 + revert, intel_cpufreq/schedutil: 3899 seconds Kernel 5.4-rc8 + gg 6 + revert, intel_cpufreq/schedutil: 2740.7 seconds Ratio: 0.70 (as expected) Kernel 5.4-rc8, intel_cpufreq/schedutil: 2334.7 seconds (faster than expected) Kernel 5.4-rc8 + gg 6 patch set, intel_cpufreq/schedutil: 2275.0 seconds (faster than expected) Ratio: 0.97 (not as expected) Kernel 5.4-rc8, intel_cpufreq/performance: 2215.3 seconds Kernel 5.4-rc8, intel_cpufreq/ondemand: 3286.3 seconds Re-stated from previous e-mail: Kernel 5.3-rc8, intel_cpufreq/schedutil: ratio: 0.69 (I don't have the original times)
... Doug
| ![\](/images/icornerr.gif) |