http://bugzilla.suse.com/show_bug.cgi?id=1131437
http://bugzilla.suse.com/show_bug.cgi?id=1131437#c14
Jan Kara changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |giovanni.gherdovich@suse.co
| |m
Flags| |needinfo?(giovanni.gherdovi
| |ch@suse.com)
--- Comment #14 from Jan Kara ---
So I took 4.18 +
patches.suse/cpufreq-intel_pstate-use-setpoint-of-10-on-servers.patch
patches.suse/cpufreq-ondemand-set-default-up_threshold-to-30-on-multi-core-systems.patch
patches.suse/cpufreq-intel_pstate-Ramp-up-frequency-faster-when-utilisation-reaches-setpoint.patch
patches.suse/cpufreq-intel_pstate-Temporarily-boost-P-state-when-exiting-from-idle.patch
and the results are as:
Amean 1 39.42 ( 0.00%) 39.00 ( 1.06%) 38.98 (
1.13%) 39.58 ( -0.40%) 38.93 ( 1.25%)
Amean 2 34.35 ( 0.00%) 36.44 ( -6.09%) 31.83 (
7.32%) 33.67 ( 1.98%) 31.72 ( 7.65%)
Amean 4 35.31 ( 0.00%) 42.02 ( -19.02%) 41.41 (
-17.28%) 44.03 ( -24.71%) 43.04 ( -21.90%)
So actually worse than vanilla 4.18. It seems it won't be so easy and we'll
need to figure out from scratch what's happening with frequency scaling and how
to fix it for dbench. Giovanni, any idea what to try?
BTW, feel free to use marvin4 for experiments (kernel sources are in
source/linux, config I run is in
configs/config-global-dhp__io-dbench4-async-xfs).
--
You are receiving this mail because:
You are on the CC list for the bug.