Hi,
I have noticed an odd behavior in hackbench test, when developing some enhancements for thermal subsystem. It is present on ARM64 big.LITTLE (4b+4l) SoC.
When hackbench runs normally after system reboot, it takes ~11sec to finish. When the module (which has locking present) is loaded and unloaded, time-to-finish is around ~6sec.
The module tries to mimic the thermal framework, so everyone can experiment on local system without the need of thermal configuration.
The test scenario and results are described in patch 1/3.
Patch 3/3 is to narrow down the issue - mutex_unlock() call.
Please apply only patch 1 and 2 and give it a try. You should see the speed-up 11s -> 6s. Then apply patch 3, rebuild the module, reboot the system, load the module, and run the test again (there should not be any improvements 11s -> 11s).
I have noticed that the sequence: load the module, unload, run the test, also gives the speed-up. So there is no need to constantly touch the mutexes in the background.
Any comments are welcome, esspecially for Will or Mark who where implementing low-level atomic stuff for mutexes.
Tested on a few kernels (tag 4.18-rc6, EAS-next-integration_20180817_0000, some stable 4.14.x) and all are affected.
Ypu can experiment with this kernel: EAS kernel branch: eas/next/integration_20180817_0000 also check tag: v4.18-rc6 url: http://linux-arm.org/git?p=linux-power.git%3Ba=shortlog%3Bh=refs/heads/eas/n...
Regards, Lukasz Luba
Lukasz Luba (3): drivers: base: add test module hackbench speedup drivers: base: add hackbench_speedup as a module drivers: hackbench_speedup: remove locking
drivers/base/Makefile | 1 + drivers/base/hackbench_speedup.c | 148 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 149 insertions(+) create mode 100644 drivers/base/hackbench_speedup.c
-- 2.7.4