[RFC,0/3] Strange hackbench speed-up

Message

Lukasz Luba Sept. 21, 2018, 9:38 a.m. UTC

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;a=shortlog;h=refs/heads/eas/next/integration_20180817_0000

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