http://bugzilla.opensuse.org/show_bug.cgi?id=948368
http://bugzilla.opensuse.org/show_bug.cgi?id=948368#c4
Mel Gorman changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|mgorman@suse.com |kernel-maintainers@forge.pr
| |ovo.novell.com
--- Comment #4 from Mel Gorman ---
I'm unassigning myself as I'm not committed to working on this right now and a
number of subsystems are affected as I'll explain shortly. I also do not have
access to a similarly configured machine right now.
There are a large number of differences between the tests that affect the
results. It's not an apples-to-apples comparison but the out-of-the-box
performance is always interesting and worth paying attention to. I would expect
the outcome of this would be tuning recommendations instead of outright bugs
but that remains to be seen.
Disk benchmarks
---------------
tldr -- use deadline to see how much the gap closes. I consider it unlikely
that xfs is slower than ext4 on this system but it's worth checking.
On openSUSE, the tests were run on XFS (according to page 1 of the article) and
the implication is that all others were run in ext4. It's worth noting that on
a single rotary disk, I would expect xfs to be slower due to allocation groups
causing seeks but that does not apply here due to the use of SSD. Seek times
are expected to be constant on such devices.
I believe the relevant difference is that openSUSE LEAP is using the NOOP
scheduler. I do not know the history of what that decision was made but it's
not without consequences. First, there is no concept of fairness so multiple IO
sources can see stalls and reduced performance with NOOP scheduler that may be
alleviated by the use of deadline. However, the test descriptions imply that
many of the tests were single-threaded and this point does not apply. However,
SSDs physically operate on a different block size than the logical block size.
Multiple 512K or 4KB requests can result in expensive read-modify-write
requests on the underlying device when there is no merging. Deadline can allow
more efficient IO patterns.
Recommended actions
1. Verify that deadline is faster than noop for SSDs on a similarly configured
machine
2. If verified, update the default setting on openSUSE LEAP
CPU-intensive
-------------
tldr: Try "sudo cpupower frequency-set -g performance" or read down for
alternative recommendations
The results show major declines in cpu-intensive workloads. Some of those are
expected to lightly load the overall machine but use individual cores
intensely. The intel_pstate driver is overly aggressive at lower the CPU
frequency. Forums and mailing lists are littered with complains about the
performance when this driver is used. While I do not have specific data to use,
I have informal evidence that there is a performance regression between 3.12
and 4.1 and the intel_pstate cpufreq driver has been identified as the source.
Starting recommendation is any of the following
1. sudo cpupower frequency-set -g performance
2. echo 30 > /sys/kernel/debug/pstate_snb/setpoint
echo 14 > /sys/kernel/debug/pstate_snb/p_gain_pct
3. Disabline intel_pstate
The tests differ by kernel version and cpufreq settings but even so, cpufreq is
not a perfect fit to explain the gap. Manjaro has a similar kernel and cpufreq
defaults but does not see the same problems. It is possible Manjaro has other
internal default tweaks or backports that are not described in the article. A
potential alternative explanation is that the compiler produced particularly
bad code for haswell.
Recommended action:
1. Verify if the performance governor eliminates the issue
2. If so, check if the altered defaults to powersave are close enough to
optimal performance to have an acceptable balance between power saving and
performance
GPU-intensive
-------------
I have no specific recommendations here as I'm insufficiently familiar with the
different driver versions and their performance impact.
Ideally, separate bugs would be created to investigate each topic (filesystem,
IO scheduler settings, cpufreq idling, compiler used and anything that crops up
that is GPU related).
--
You are receiving this mail because:
You are on the CC list for the bug.