http://bugzilla.opensuse.org/show_bug.cgi?id=948368 Martin Pluskal changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mpluskal@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=948368 Jeff Mahoney changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeffm@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

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.

http://bugzilla.opensuse.org/show_bug.cgi?id=948368 Andreas Jaeger changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aj@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=948368 Max Lin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mlin@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=948368 Kirill Kirillov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kkirill@opensuse.org -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=948368 http://bugzilla.opensuse.org/show_bug.cgi?id=948368#c10 Vadim Krevs changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- Flags|needinfo?(jeffm@suse.com) | --- Comment #10 from Vadim Krevs --- Phoronix repeated the tests with the released openSUSE 42.1: http://www.phoronix.com/scan.php?page=article&item=nov-2015-linux&num=1 Sadly, openSUSE 42.1 is amongst the slowest compared distros, especially in anything disk-intensive. As I understand, they used XFS for tests this time on openSUSE. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=948368 http://bugzilla.opensuse.org/show_bug.cgi?id=948368#c14 --- Comment #14 from Mel Gorman --- FYI, bug 954765 is tracking the systemd-related issue for Tumbleweed. How and when LEAP gets a fixed package will depend on whether the SLE systemd package or the Tumbleweed systemd package is pulled. It's also mentioned upstream at https://github.com/systemd/systemd/issues/1715 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=948368 http://bugzilla.opensuse.org/show_bug.cgi?id=948368#c15 --- Comment #15 from Jiri Srain --- According to the package changelog of 42.1 GM, the udev package has the change reverted (and therefore should use correct scheduler for SSD). I think that we need to search for the reason why openSUSE is slower elsewhere - and I'm not sure whether/how I could help here... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=948368 http://bugzilla.opensuse.org/show_bug.cgi?id=948368#c19 --- Comment #19 from Vadim Krevs --- I can confirm #18 on two upgraded 13.2->Leap 42.1 systems. Thank you very much. -- You are receiving this mail because: You are on the CC list for the bug.