[Bug 1112824] New: Severe Performance Degradation with update to latest tumbleweed (20181018)
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824 Bug ID: 1112824 Summary: Severe Performance Degradation with update to latest tumbleweed (20181018) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: GNOME Assignee: bnc-team-gnome@forge.provo.novell.com Reporter: ldewey@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Created attachment 786777 --> http://bugzilla.opensuse.org/attachment.cgi?id=786777&action=edit journalctl output There is a severe performance degradation when upgrading to the latest version of tumbleweed. Mouse movements are extremely jittery, typing is choppy, slow, and will often repeat characters which were only typed once. Behavior is consistent with all things utilizing gnome-shell version 3.30.0 and 3.30.1 (attempted to use GNOME_factory repository). Performance is bad enough to render the entire desktop environment virtually unusable. Journalctl Logs: ================ (See attached file). System Information: =================== (See attached file). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c1
--- Comment #1 from Larry Dewey
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Michiel Janssens
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c2
--- Comment #2 from Michiel Janssens
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c3
Philip Raets
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Robert Munteanu
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Bruce Rogers
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c4
Dominique Leuenberger
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c5
--- Comment #5 from Robert Munteanu
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c6
--- Comment #6 from Philip Raets
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c7
Atri Bhattacharya
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c8
--- Comment #8 from Atri Bhattacharya
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c9
--- Comment #9 from Michiel Janssens
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Wolfgang Rosenauer
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Oliver Kurz
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c10
Nicklas Boman
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Olivier Nicolas
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Markos Chandras
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c11
--- Comment #11 from Olivier Nicolas
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c12
--- Comment #12 from Wolfgang Rosenauer
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c13
--- Comment #13 from Larry Dewey
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
nicolas bertrand
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c14
Nicolás Luciano Bértolo
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c15
Kukuh Syafaat
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Dingzhong Chen
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c16
Benjamin Sabatini
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c17
Ivan Petrovic
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c18
Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c19
--- Comment #19 from Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c20
--- Comment #20 from Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Michael Puls
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c21
--- Comment #21 from Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c22
--- Comment #22 from Nicolás Luciano Bértolo
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c23
--- Comment #23 from Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c24
--- Comment #24 from Robert Munteanu
It seems the problem is only with Intel processors, only openSUSE, there is no problem with other distributions, I checked
Does that mean Intel CPUs have the problem and AMD CPUs don't? Or does it mean systems using the Intel iGPU have the problem and systems using discrete AMD / NVidia GPUs don't? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c25
--- Comment #25 from Dead Mozay
(In reply to Dead Mozay from comment #23)
It seems the problem is only with Intel processors, only openSUSE, there is no problem with other distributions, I checked
Does that mean Intel CPUs have the problem and AMD CPUs don't? Or does it mean systems using the Intel iGPU have the problem and systems using discrete AMD / NVidia GPUs don't?
There is a problem with Intel CPU, various benchmarks show a drop in performance in multi-core testing, sometimes decent, just checked with other distributions, there is no such thing. I also tried both the integrated graphics and the discrete, and quite good, I have gtx 1070, the difference with the intel hd is no -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c26
--- Comment #26 from Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c27
--- Comment #27 from Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c28
--- Comment #28 from Robert Munteanu
in general, as far as I can tell, the problem is not in the gnome, but somewhere in the depths of the system packages. after compiling the kernel from the source code, the problem with hyper-threading disappeared, the gnome with the enabled hyper-threading showed slideshows instead of animations
Interesting. Is this the same kernel version as in Tumbleweed? Did you use the same config? This might help tracking down the root cause. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c29
--- Comment #29 from Dead Mozay
(In reply to Dead Mozay from comment #27)
in general, as far as I can tell, the problem is not in the gnome, but somewhere in the depths of the system packages. after compiling the kernel from the source code, the problem with hyper-threading disappeared, the gnome with the enabled hyper-threading showed slideshows instead of animations
Interesting. Is this the same kernel version as in Tumbleweed? Did you use the same config? This might help tracking down the root cause.
I compiled 4.19.2, but the problem appeared a long time ago, the configuration used the standard one, without changes, I wanted to compare it to Fedora config, but there it is missing, you need to get it from makemenu, only all hands in any way will not reach to save a config. I tried to identify the problem, but it did not work, all my attempts were unsuccessful there is little experience and knowledge, if you tell me what you need, I will try to help -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Yifan Jiang
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c30
--- Comment #30 from Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c31
--- Comment #31 from Robert Munteanu
Created attachment 790294 [details] kernel config
It seems that it was possible to solve the problem, at least on the Intel HD animations, they became smooth, so that someone else would check it, you need to rebuild the kernel with the attached config
Thanks for the config! I tried to compare it with the one shipped in TW, but unfortunately there are too many differences: $ zcat /proc/config.gz | diff - kconfig-suggested | wc -l 4621 I'll try and test your assumption that this is specific to Intel CPUs soon though, I have an AMD machine that I have not updated yet. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Dominique Leuenberger
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c32
--- Comment #32 from Dead Mozay
(In reply to Dead Mozay from comment #30)
Created attachment 790294 [details] kernel config
It seems that it was possible to solve the problem, at least on the Intel HD animations, they became smooth, so that someone else would check it, you need to rebuild the kernel with the attached config
Thanks for the config! I tried to compare it with the one shipped in TW, but unfortunately there are too many differences:
$ zcat /proc/config.gz | diff - kconfig-suggested | wc -l 4621
I'll try and test your assumption that this is specific to Intel CPUs soon though, I have an AMD machine that I have not updated yet.
It's my pleasure I just concluded, everyone who said that they had no problems with the gnome, everyone CPU AMD. There is also a possibility that a patch is guilty, and everything is fine with the config, I compiled it manually without patches. PS And yes, the problem really disappeared, I launched several programs, a browser with a lot of tabs, the animations remained smooth, there are jerks, but usual for a gnome and not like they were before -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c33
--- Comment #33 from Michiel Janssens
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c34
--- Comment #34 from Atri Bhattacharya
There is a possibility that the spectre mitigations have something to do with all this, and or hyperthreading/smt.
3. boot with kernel parameters: spectre_v2=off Transition is smooth This parameter seems to have the biggest impact of all the tested parameters.
Early days -- minutes, actually -- but this seems to help a lot in my case too (Intel i7-7*** processors). There are still some animation choppiness on Application overview, but nothing like before. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c35
--- Comment #35 from Martin Wilck
3. boot with kernel parameters: spectre_v2=off Transition is smooth This parameter seems to have the biggest impact of all the tested parameters.
Thanks a LOT for figuring this out. But reading above that only openSUSE is affected - I'd assume that Ubuntu and Fedora are also shipping with these mitigations enabled by default, no? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c36
--- Comment #36 from Robert Munteanu
There is a possibility that the spectre mitigations have something to do with all this, and or hyperthreading/smt. I tested my system on the impact of those mitigations. As a reference I used a mouse click on "Show applications" item on the gnome-shell menu, running wayland. Watching if the application icons transition smoothly from the corner into the main desktop area. Hardware: Dell XPS 13 9360 Snapshot 20181118 Kernel 4.19.2-1
My subjective results 1. boot with default kernel parameters Transition is barely noticeable, not smooth for sure
2. boot with kernel parameters: pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier Transition is very smooth
3. boot with kernel parameters: spectre_v2=off Transition is smooth This parameter seems to have the biggest impact of all the tested parameters.
Now I read about the new recently disclosed spectre v2 vulnerabilities and the STIBP mitigation. Some voices say that we might as well disable hyperthreading/smt instead of these new mitigations.
4. boot with default kernel parameters, and hyperthreading disabled in BIOS Transitions are smooth.
For the moment I will leave all mitigations enabled and hyperthreading disabled. For the record, this is an Intel Kabylake cpu
Some more data points: - for my Lenovo W541 laptop - i7-4810MQ with iGPU, none of these helped. The animations are maybe slightly faster, but still laggy - after updating my desktop ( Ryzen 5 2600X, Nvidia 1070, Samsung EVO 970 NVME SSD ) from Gnome 3.28, the animations are smooth, but I feel I slight stutter when pressing buttons for the first time, e.g. the applications button. Maybe I'm imagining, I don't now. What I think would be useful is for those affected and for which the various boot options worked to clarify whether they were using a discrete GPU or the integrated GPU. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c37
--- Comment #37 from Atri Bhattacharya
What I think would be useful is for those affected and for which the various boot options worked to clarify whether they were using a discrete GPU or the integrated GPU.
In my case integrated GPU: Intel® HD Graphics 620 (Kaby Lake GT2). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c38
--- Comment #38 from Atri Bhattacharya
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c39
--- Comment #39 from Nicolás Luciano Bértolo
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c40
--- Comment #40 from Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c41
--- Comment #41 from Zhiyuan Gao
(In reply to Michiel Janssens from comment #33)
3. boot with kernel parameters: spectre_v2=off Transition is smooth This parameter seems to have the biggest impact of all the tested parameters.
Thanks a LOT for figuring this out. But reading above that only openSUSE is affected - I'd assume that Ubuntu and Fedora are also shipping with these mitigations enabled by default, no?
So I had a look upon fedora29. - kernel version 4.18.17 - gnome version 3.30.2 hyperthreading on and it seems spectre protection is also turned on So presumably the only difference we have is that kernel version is different. What do you think? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c42
--- Comment #42 from Dead Mozay
(In reply to Martin Wilck from comment #35)
(In reply to Michiel Janssens from comment #33)
3. boot with kernel parameters: spectre_v2=off Transition is smooth This parameter seems to have the biggest impact of all the tested parameters.
Thanks a LOT for figuring this out. But reading above that only openSUSE is affected - I'd assume that Ubuntu and Fedora are also shipping with these mitigations enabled by default, no?
So I had a look upon fedora29. - kernel version 4.18.17 - gnome version 3.30.2 hyperthreading on and it seems spectre protection is also turned on
So presumably the only difference we have is that kernel version is different.
What do you think?
Fedora kernel 4.19.2 there are no problems either -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c43
--- Comment #43 from Michiel Janssens
(In reply to Robert Munteanu from comment #36)
What I think would be useful is for those affected and for which the various boot options worked to clarify whether they were using a discrete GPU or the integrated GPU.
In my case integrated GPU: Intel® HD Graphics 620 (Kaby Lake GT2).
I have the same iGPU. Intel HD 620 KL GT2 on i7-7500U cpu. Also have to mention that I've mainly tested with 2 connected 24inch external monitors, so the gpu has to work harder and artifacts are easier to spot. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Scott Reeves
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c44
--- Comment #44 from Benjamin Sabatini
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c45
--- Comment #45 from Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c46
--- Comment #46 from Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c47
--- Comment #47 from Martin Wilck
and also found out that there are no patches STIBP in Fedora, in openSUSE this patch is there, maybe that's the problem
This would make sense if the performance regressions were only observed with 4.19.2 and newer, where STIBP was first enabled in openSUSE. But people have started reporting this with earlier kernels. If people are running 4.19.2, STIBP likely contributes to the slowness. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c48
--- Comment #48 from Benjamin Sabatini
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c49
--- Comment #49 from Dead Mozay
So what info/logs would be helpful to fix this?
problem fixed? I just have a self-assembly kernel, at the same time there was an update to the gnome, now I’m not sure what exactly improved the performance -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c50
--- Comment #50 from Nicolás Luciano Bértolo
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c51
--- Comment #51 from Dead Mozay
I tried kernel-vanilla and I found that it runs even better than kernel-default with spectre mitigations off. Can anybody replicate my findings?
in 4.19.4 a patch has already been adopted that disables stibp, by the way stibp was enabled in 4.14, but yes, performance improves with vanilla kernel -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c52
--- Comment #52 from Benjamin Sabatini
(In reply to Nicolás Luciano Bértolo from comment #50)
I tried kernel-vanilla and I found that it runs even better than kernel-default with spectre mitigations off. Can anybody replicate my findings?
in 4.19.4 a patch has already been adopted that disables stibp, by the way stibp was enabled in 4.14, but yes, performance improves with vanilla kernel
So problem not fixed in the default kernel. As many have said several times, the problem was pre 4.19.2. In other words, it is not because of STIBP. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c53
--- Comment #53 from Michiel Janssens
I tried kernel-vanilla and I found that it runs even better than kernel-default with spectre mitigations off. Can anybody replicate my findings?
For my system they give similar behavior, so a lot better then just kernel-default. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c54
--- Comment #54 from Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c55
David Mulder
I tried kernel-vanilla and I found that it runs even better than kernel-default with spectre mitigations off. Can anybody replicate my findings?
vanilla kernel + spectre fixes enabled works well for me. Disabling spectre is even better. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c56
--- Comment #56 from Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Tomasz Witowski
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Sam Yu
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c57
--- Comment #57 from Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c58
Takashi Iwai
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c60
--- Comment #60 from Dead Mozay
Can anyone of the gazillion people on this bugzilla build the upstream v4.20-rc5 kernel and test with it?
We have disabled STIBP et al upstream and will backport this to our kernels eventually.
Thx.
disabling stibp does not solve the problem, I tried, I also deleted a number of patches that could affect performance, nothing changes. I also found that the problem also exists in kernel 4.12, and problems started with it -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c65
--- Comment #65 from Dead Mozay
(In reply to Borislav Petkov from comment #59)
Can anyone of the gazillion people on this bugzilla build the upstream v4.20-rc5 kernel and test with it?
FWIW, OBS Kernel:HEAD repo already contains the latest upstream 4.20-rc5: https://download.opensuse.org/repositories/Kernel:/HEAD/standard/ You can try kernel-vanilla from that repo.
nothing changed -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c67
--- Comment #67 from Dead Mozay
(In reply to Dominique Leuenberger from comment #63)
yes, it seems to be an interaction between GNOME and the kernel
If the performance regression goes away when you use a different desktop env than gnome, then it is clearly a gnome issue.
Otherwise, you'd have to be more specific about this "interaction". Maybe perf-profile a typical workload which causes the regression, etc.
Thx.
it is possible, and it is also possible if the CPU will not work correctly, problems will also be observed in the gnome, the gnome is very dependent on how the CPU works. At the beginning of the search for a problem, I did synthetic tests, they showed a drop in multi-core tests, which in turn could well cause a similar problem in the GNOME -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c70
--- Comment #70 from Nicolás Luciano Bértolo
(In reply to Dead Mozay from comment #65)
nothing changed
If booting that same kernel with
spectre_v2=off spectre_v2_user=off spec_store_bypass_disable=off l1tf=off
on the kernel command line still doesn't change anything, then the problem is somewhere else.
I can confirm that those parameters help a lot. But in my tests I couldn't find a difference between 4.19 and 4.20. 4.20 with mitigations enabled is just as bad as 4.19-default. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c73
--- Comment #73 from Michiel Janssens
(In reply to Nicolás Luciano Bértolo from comment #70)
I can confirm that those parameters help a lot. But in my tests I couldn't find a difference between 4.19 and 4.20. 4.20 with mitigations enabled is just as bad as 4.19-default.
Well, the mitigations do cost and we've tried to make them as unpunishing as possible. For example, my workstation with 20-rc5 has:
/sys/devices/system/cpu/vulnerabilities/l1tf:Not affected /sys/devices/system/cpu/vulnerabilities/meltdown:Not affected /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline, IBPB: conditional, STIBP: disabled, RSB filling
which means that SSB will be enabled only for applications which request it (prctl and seccomp), spectre_v2 is mitigated by retpolines (a lot cheaper than IBRS) and the indirect branch predictor barrier happens when switching between different user processes of which one can be a malicious one.
And this is the default setting.
The whole idea behind having all those cmdline options was for people who don't want to sacrifice performance and would like to disable the security mitigations. So the ultimate decision will be with the user.
In any case, the default case does enable a *sensible* set of the mitigations but they are not for free(!) and depend on the workload.
I hope I'm making sense here.
To me you are making sense, thank you for looking into this. I have the same result as https://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c70 However, I also tested kernel-vanilla, from Head and current 4.19.5. Kernel-vanilla gives similar or almost similar result as with mitigations off as you mentioned in https://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c66 But in my understanding kernel-vanilla has all default mitigations on, as running latest spectre-meltdown-checker says my system is not vulnerable. So it seems to me there must be a difference in the kernels. 4.19.5-1-vanilla: /sys/devices/system/cpu/vulnerabilities/l1tf Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable /sys/devices/system/cpu/vulnerabilities/meltdown Mitigation: PTI /sys/devices/system/cpu/vulnerabilities/spec_store_bypass Mitigation: Speculative Store Bypass disabled via prctl and seccomp /sys/devices/system/cpu/vulnerabilities/spectre_v1 Mitigation: __user pointer sanitization /sys/devices/system/cpu/vulnerabilities/spectre_v2 Mitigation: Full generic retpoline, IBPB, IBRS_FW 4.19.5-1-default: /sys/devices/system/cpu/vulnerabilities/l1tf Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable /sys/devices/system/cpu/vulnerabilities/meltdown Mitigation: PTI /sys/devices/system/cpu/vulnerabilities/spec_store_bypass Mitigation: Speculative Store Bypass disabled via prctl and seccomp /sys/devices/system/cpu/vulnerabilities/spectre_v1 Mitigation: __user pointer sanitization /sys/devices/system/cpu/vulnerabilities/spectre_v2 Mitigation: Indirect Branch Restricted Speculation, IBPB, IBRS_FW Apparently on my Intel system both kernels have different spectre_v2 mitigations. Kernel-default is using IBRS, which as you say is more expensive than retpoline, which is used by kernel-vanilla. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c74
--- Comment #74 from Michiel Janssens
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c78
--- Comment #78 from Dead Mozay
(In reply to Michiel Janssens from comment #73)
Apparently on my Intel system both kernels have different spectre_v2 mitigations. Kernel-default is using IBRS, which as you say is more expensive than retpoline, which is used by kernel-vanilla.
Yes, kernel-default has our SUSE patches which are part of SLE and have this additional IBRS enablement which is not upstream and thus vanilla doesn't have it.
IBRS is a heavy hammer and didn't get accepted upstream but we took it. Which is going to be replaced by enhanced IBRS which should be lighter but it is still being rolled out and I don't know whether older, already released machines can even get it through microcode. For details, see:
https://software.intel.com/sites/default/files/managed/c5/63/336996- Speculative-Execution-Side-Channel-Mitigations.pdf
where all the different mitigation mechanisms are explained.
Now, it is debatable whether a Skylake class machine which needs IBRS to be fully mitigated is even exploitable when only retpolines are enabled. It has been said that running a spectre v2 exploit on a machine only with retpolines and not IBRS is very very hard to do. Thus, many people are unwilling to pay the performance penalty and revert to retpolines. IOW, if you boot with spectre_v2=retpoline on kernel-default, you should be getting close to vanilla.
All IMHO, of course.
I build a kernel 4.19.5 without IBRS patches, nothing has changed, although I do not exclude the possibility that I could do something wrong, or skip. https://build.opensuse.org/package/show/home:Dead_Mozay:Kernel/kernel-defaul... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c81
--- Comment #81 from Dead Mozay
(In reply to Dead Mozay from comment #75)
Created attachment 792011 [details] Logs
Yes, you're comparing apples with oranges:
1. Fedora is 4.18.16-300.fc29.x86_64 which has some patches - who knows what - all the distros do ship their own tweaks ontop.
2. 4.20.0-rc5-1.g2ccaf30-vanilla which is the upstream kernel (perhaps?) and does not have those patches.
All this says is that Fedora's kernel is somewhat better, provided the benchmarks are sensible. I have no clue what yours do.
If you want to compare security mitigations, you need to take the same kernel and do two runs, once with the mitigation enabled and once with the mitigation disabled.
with the same kernel, the results are the same, just where it is installed there is no possibility to use other kernels because of the proprietary drivers nvidia. in fedora vanilla kernel, without patches, at least so maintainers maintain I tried to install fedora on this laptop, it works fine even with the kernel 4.19.4 which was at that time -- You are receiving this mail because: You are on the CC list for the bug.
If you want to compare security mitigations, you need to take the same kernel and do two runs, once with the mitigation enabled and once with the mitigation > disabled. I performed tests with enabled and disabled parameters, the result in fedora is
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c83
--- Comment #83 from Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c84
--- Comment #84 from Dead Mozay
(In reply to Dead Mozay from comment #81)
(In reply to Borislav Petkov from comment #79)
(In reply to Dead Mozay from comment #75)
Created attachment 792011 [details] Logs
Yes, you're comparing apples with oranges:
1. Fedora is 4.18.16-300.fc29.x86_64 which has some patches - who knows what - all the distros do ship their own tweaks ontop.
2. 4.20.0-rc5-1.g2ccaf30-vanilla which is the upstream kernel (perhaps?) and does not have those patches.
All this says is that Fedora's kernel is somewhat better, provided the benchmarks are sensible. I have no clue what yours do.
If you want to compare security mitigations, you need to take the same kernel and do two runs, once with the mitigation enabled and once with the mitigation disabled.
with the same kernel, the results are the same, just where it is installed there is no possibility to use other kernels because of the proprietary drivers nvidia. in fedora vanilla kernel, without patches, at least so maintainers maintain I tried to install fedora on this laptop, it works fine even with the kernel 4.19.4 which was at that time
Are you testing Fedora kernel with openSUSE user-space stuff? Or are you testing Fedora user-space?
If Fedora kernel works better with openSUSE user-space, then the point should be either Fedora's downstream patch or the difference of the kernel configuration.
For the latter case, you can try to build the upstream kernel with Fedora kernel config and see whether it works.
I tried to build the kernel with the fedora config, I even wrote about it somewhere above, it works better, but there are still some problems, -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c85
--- Comment #85 from Takashi Iwai
Are you testing Fedora kernel with openSUSE user-space stuff? Or are you testing Fedora user-space?
If Fedora kernel works better with openSUSE user-space, then the point should be either Fedora's downstream patch or the difference of the kernel configuration.
For the latter case, you can try to build the upstream kernel with Fedora kernel config and see whether it works.
I tried to build the kernel with the fedora config, I even wrote about it somewhere above, it works better, but there are still some problems,
If you still have the same performance problem with a self-built upstream kernel using the Fedora config, then it's really something else than kernel. If something is *improved* by the Fedora kernel config, though, we'd like to see the difference. You can try the following: - Boot with Fedora config kernel, copy /proc/config.gz to .config on 4.19.x Linux kernel tree, and run "make localmodconfig". This will give you a minimal set of kernel config for the currently running kernel. Save this config to somewhere. - Similarly, boot with openSUSE kernel, and do the same. Now you get two kernel configs you can directly compare. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c86
--- Comment #86 from Dead Mozay
(In reply to Dead Mozay from comment #84)
Are you testing Fedora kernel with openSUSE user-space stuff? Or are you testing Fedora user-space?
If Fedora kernel works better with openSUSE user-space, then the point should be either Fedora's downstream patch or the difference of the kernel configuration.
For the latter case, you can try to build the upstream kernel with Fedora kernel config and see whether it works.
I tried to build the kernel with the fedora config, I even wrote about it somewhere above, it works better, but there are still some problems,
If you still have the same performance problem with a self-built upstream kernel using the Fedora config, then it's really something else than kernel.
If something is *improved* by the Fedora kernel config, though, we'd like to see the difference. You can try the following:
- Boot with Fedora config kernel, copy /proc/config.gz to .config on 4.19.x Linux kernel tree, and run "make localmodconfig". This will give you a minimal set of kernel config for the currently running kernel. Save this config to somewhere.
- Similarly, boot with openSUSE kernel, and do the same. Now you get two kernel configs you can directly compare.
https://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c30 this is fedora config, I only enabled support BTRFS -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c87
--- Comment #87 from Takashi Iwai
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c88
--- Comment #88 from Dead Mozay
That config contains all stuff, so it's not clear which different matters. That's why I asked to create minimal configs so that we can compare 1:1.
unfortunately in Fedora CONFIG_IKCONFIG_PROC=n -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c89
--- Comment #89 from Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c90
--- Comment #90 from Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c96
--- Comment #96 from Takashi Iwai
(In reply to Takashi Iwai from comment #87)
That config contains all stuff, so it's not clear which different matters. That's why I asked to create minimal configs so that we can compare 1:1.
unfortunately in Fedora CONFIG_IKCONFIG_PROC=n
Then copy Fedora kernel config manually to .config on kernel source directory, then run "make localmodconfig". It's only about copying from the proper source. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c97
--- Comment #97 from Dead Mozay
(In reply to Dead Mozay from comment #88)
(In reply to Takashi Iwai from comment #87)
That config contains all stuff, so it's not clear which different matters. That's why I asked to create minimal configs so that we can compare 1:1.
unfortunately in Fedora CONFIG_IKCONFIG_PROC=n
Then copy Fedora kernel config manually to .config on kernel source directory, then run "make localmodconfig". It's only about copying from the proper source. Made. Maybe I didn’t do that, it issued 2 requests, I answered both NEW
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Dennis Irrgang
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c98
--- Comment #98 from Dennis Irrgang
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c99
--- Comment #99 from Dead Mozay
Any updates on this? I thought I was going crazy because my fresh install was sluggish as hell.
Also running TW on a T480 with an Intel i5 8250u.
not yet, so nobody understood what the problem -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c101
Timo Jyrinki
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c102
--- Comment #102 from Takashi Iwai
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c105
--- Comment #105 from Dead Mozay
Quickly looking at the logs of comment 97, the main differences between two kernel configs are:
CONFIG_NO_HZ_FULL=y for Fedora CONFIG_NO_HZ_IDLE=y for TW
CONFIG_PREEMPT_VOLUNTARY=y for Fedora CONFIG_PREEMPT=y for TW
CONFIG_SCHED_AUTOGROUP=y for Fedora CONFIG_SCHED_AUTOGROUP=n for TW
CONFIG_SLUB=y for Fedora CONFIG_SLAB=y for TW
The last one is unlikely influencing on the performance, though. The rest are subtle drivers and debugging configs.
So I'm building a TW kernel with the config changes above to follow Fedora in OBS home:tiwai:bsc1112824 repo. The build should finish in an hour or so.
Please give it a try and see whether if this really improves things as advertised here.
I feel the gnome has become a bit more responsive, but I tried the free Nvidia drivers, it could also be optimization nouveau driver in the kernel, This should be checked on the Intel graphics, unfortunately I have no such opportunity now -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c106
--- Comment #106 from Timo Jyrinki
So I'm building a TW kernel with the config changes above to follow Fedora in OBS home:tiwai:bsc1112824 repo. The build should finish in an hour or so.
Please give it a try and see whether if this really improves things as advertised here.
I don't see difference on my Intel machine with the 4.19.8-1.g8bc7ab5-default nosmt=force ie disabling hyperthreading is something that does seem to make a real tangible difference for me. With it the most annoying lags are gone. The effect is the same both with 4.19.7 and the one from home:tiwai:bsc1112824, so in other words the changed configuration there does not seem to affect this behavior. This is based on 10+ boots. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c107
--- Comment #107 from Takashi Iwai
(In reply to Takashi Iwai from comment #102)
So I'm building a TW kernel with the config changes above to follow Fedora in OBS home:tiwai:bsc1112824 repo. The build should finish in an hour or so.
Please give it a try and see whether if this really improves things as advertised here.
I don't see difference on my Intel machine with the 4.19.8-1.g8bc7ab5-default
nosmt=force ie disabling hyperthreading is something that does seem to make a real tangible difference for me. With it the most annoying lags are gone. The effect is the same both with 4.19.7 and the one from home:tiwai:bsc1112824, so in other words the changed configuration there does not seem to affect this behavior. This is based on 10+ boots.
Just to be sure: did you already test the kernel in OBS Kernel:HEAD, which is based on the latest 4.20-rc? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c108
--- Comment #108 from Timo Jyrinki
Just to be sure: did you already test the kernel in OBS Kernel:HEAD, which is based on the latest 4.20-rc?
Now I have (4.20.0-rc6-2.g91eea17-default). It seems the situation remains the same even there. With hyperthreading enabled overall user experience is bad due to lagginess, with nosmt=force it's usable. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c110
--- Comment #110 from Dead Mozay
(In reply to Timo Jyrinki from comment #108)
Now I have (4.20.0-rc6-2.g91eea17-default). It seems the situation remains the same even there. With hyperthreading enabled overall user experience is bad due to lagginess, with nosmt=force it's usable.
Does booting with l1tf=off help?
Does booting with spectre_v2=retpoline help?
Can you try a different desktop environment besides gnome and see how it behaves there?
Thx.
disabling patches on the 4.19.7 kernel no longer affects anything, just made several reboots with different patch shutdown options, and without shutting down at all, the result is the same. At the moment, my performance is only affected by disabling hyper-threading. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c111
--- Comment #111 from Nicolás Luciano Bértolo
disabling patches on the 4.19.7 kernel no longer affects anything, just made several reboots with different patch shutdown options, and without shutting down at all, the result is the same. At the moment, my performance is only affected by disabling hyper-threading.
This does not match my experience. Using spectre_v2=retpoline makes the default kernel perform just as well as the vanilla kernel. I'm using kernel 4.19.7-1-default. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c112
--- Comment #112 from Dead Mozay
disabling patches on the 4.19.7 kernel no longer affects anything, just made several reboots with different patch shutdown options, and without shutting down at all, the result is the same. At the moment, my performance is only affected by disabling hyper-threading.
This does not match my experience. Using spectre_v2=retpoline makes the default kernel perform just as well as the vanilla kernel.
I'm using kernel 4.19.7-1-default.
Perhaps spectre_v2 = retpoline affects the work with Intel HD graphics, i have Nvidia with proprietary drivers, for me this option is useless. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c113
--- Comment #113 from Dead Mozay
disabling patches on the 4.19.7 kernel no longer affects anything, just made several reboots with different patch shutdown options, and without shutting down at all, the result is the same. At the moment, my performance is only affected by disabling hyper-threading.
This does not match my experience. Using spectre_v2=retpoline makes the default kernel perform just as well as the vanilla kernel.
I'm using kernel 4.19.7-1-default.
Checked on my laptop http://paste.opensuse.org/view//92547497, the difference really is with the parameter spectre_v2=retpoline, but still this is not enough, a conflict of patches may have occurred somewhere, I saw a package with a bunch of patches somewhere, and a few were very old, 6 years ago were created, most likely they have not been needed for a long time, and now such patches can cause only problems -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Emiliano Langella
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c114
--- Comment #114 from Dennis Irrgang
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c115
--- Comment #115 from Dennis Irrgang
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c116
--- Comment #116 from Dead Mozay
There may also be a time component to this. It seems like performance is degrading over time. After a reboot performance is 'usable', but after a few hours of working it becomes notably worse.
At the expense of overall performance, I'm not sure, but the GNOME starts to fail more, if the computer is running for a long time without rebooting. What I had enough of my mind, I already checked, it remains to hope for real gurus. but in general, similar problems with animations appeared in Fedora, but in openSUSE, they are more noticeable and annoying, for many, but I do not exclude the possibility that the lags are due to the fact that I have Fedora installed on the old HDD, and openSUSE on NVME SSD, but problems are still more 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=1112824
Adam Szyszko
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c118
--- Comment #118 from Adam Szyszko
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c119
--- Comment #119 from Dead Mozay
I'm testing 4.20 kernel now. For me nothing has changed. Still animations are choppy, windows are opening delayed. My specs: Intel i7-7500U, Intel HD graphics 620, 8GB ram.
similarly, I did not notice any changes except one, all options for disabling protection spectre V2 can be removed. Performance no longer suffers when security is enabled, but with the gnome this problem did not solve. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c121
--- Comment #121 from Dead Mozay
And now can anyone try with a different desktop environment besides gnome?
some people say that everything is ok there, perhaps because they have nothing to compare with, but when I checked the bug I checked with plasma5 I also noticed some problems in animations there, but I’ll not say that the root of the problems in the gnome will be, in plasma5, through the release, they break something, into this the moment there is something broken too, when choosing the engine, the opengl3 animations work poorly, changing the version to the old one helps a little, but problems remain anyway, this problem is in plasma5, at the moment it is not possible to conduct such a check, you need to wait when the problem is corrected in plasma5. And there are no more sane desktop environments where you can see how graphics acceleration works and other things. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c123
--- Comment #123 from Dead Mozay
Ok, bouncing back for reassignment. If there's anything the kernel can do, I'm all ears.
at the moment I see only one problem related to the kernel, the SMT enabled in the BIOS still spoils the performance, again this is most noticeable in the gnome, otherwise it seems to me that it is indistinguishable from the vanilla kernel, I don’t observe any early performance losses, the rest apparently need to look elsewhere. It is necessary to do an audit of all system packages, as I said earlier there are packages with very old patches, it is possible that somewhere such a patch caused some kind of conflict. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c124
Atri Bhattacharya
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c125
--- Comment #125 from Dead Mozay
Are you using GNOME on a wayland session or an XOrg session?
XOrg on desktop, wayland on laptop -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c126
Wolfgang Rosenauer
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c127
--- Comment #127 from Dead Mozay
I've lost track about this issue during the last weeks but I'm still facing Gnome performance which is really hard to work with on my laptop also with latest TW snapshot.
I'm supposed to run Gnome under Xorg. At least that is what my session selector says but on the other hand when I look at the process list I see Xwayland running and not Xorg. (Looks like a bug to me)
My system is a Core-i7-7500 (Quad) but the Gnome shell performance is really hard to work with. All window/desktop actions (moving windows, switches workspaces etc) are quite laggy and not smooth at all. This started in October and only got better a bit. Compared to before it's really slow. Considering switching to Xfce or something for the hope it'll be better.
echo $XDG_SESSION_TYPE will show what session you have X11 or Wayland. To activate the X11 session, you need to edit the file /etc/gdm/custom.conf, remove comment from the line WaylandEnable=false and restart session. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c128
--- Comment #128 from Wolfgang Rosenauer
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c129
--- Comment #129 from Dead Mozay
XDG_SESSION_TYPE is "x11" wolfgang@ox:~> ps ax | grep X 1834 tty7 Sl+ 0:00 /usr/bin/Xwayland :1024 -rootless -terminate -accessx -core -auth /run/user/464/mutter/Xauthority -listen 4 -listen 5 -displayfd 6 3393 tty2 Sl+ 0:02 /usr/bin/X vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -background none -noreset -keeptty -verbose 3 wolfgang@ox:~> grep -i wayland /etc/gdm/custom.conf #WaylandEnable=false
What is the verdict for that output? Wayland or Xorg? I guess "wayland" but XDG_SESSION_TYPE does not reflect that.
you need to edit the file /etc/gdm/custom.conf, remove comment from the line WaylandEnable=false and restart session. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c130
--- Comment #130 from Wolfgang Rosenauer
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c131
--- Comment #131 from Dead Mozay
Did that now. Now there is no Xwayland running anymore. And the desktop animations are now certainly smoother than with wayland running but but also still stutter more than expected. gnome-shell CPU consumption still very visible.
the consumption of CPU resources for the gnome is normal, this is not the reason -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c132
Michael G
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c133
--- Comment #133 from Wolfgang Rosenauer
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Victor Zhestkov
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c134
simon izor
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c135
--- Comment #135 from Dead Mozay
I'm really confused why were are assuming this is a kernel issue? What is GNOME doing with the kernel that could cause this?
I just encountered two other users in a Discord server that I frequent that have this same exact issue (GNOME is extremely sluggish and they have Intel CPUs), but only with GNOME, and only on Tumbleweed. All other DEs work fine. All other distros with GNOME 3.30 work fine.
There's gotta be some patch we apply to GNOME or *something* along those lines causing this... it seems extremely unlikely that it would be the kernel as these users have no issue using KDE Plasma or Xfce on the latest Tumbleweed snapshot (20190126). GNOME runs much slower for both of them on Tumbleweed than on Arch or Fedora, but only GNOME. As I said above, what would could be going with the kernel that would *only* affect GNOME?
Everything is very difficult, as I wrote above, the gnome is very dependent on how well the processor works in the operating system, any error in the kernel can affect its operation, which in turn can lead to different regressions, so the possibility of such exclusion was it is impossible, for example, by disabling the spectre protection, it started to work better, patches were applied to the kernel, not the gnome, there were such conclusions from here, currently disabling patches does not change anything at all, and he again started to lag after the latest updates.
GPU <- [ [ Cogl + Cairo ] <- [ GDK + Clutter ] <- GTK+ ] <- application So GNOM works, need to check these packages, I don’t have enough skills to check it
I tried plasma 5, it also lags me, not like a gnome, but it’s still noticeable -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c136
--- Comment #136 from simon izor
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c137
--- Comment #137 from Victor Zhestkov
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c138
--- Comment #138 from Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c140
--- Comment #140 from Dead Mozay
sudo zypper addrepo https://download.opensuse.org/repositories/home:Dead_Mozay:GNOME/openSUSE_Tu... sudo zypper refresh sudo zypper install -f libmozjs-60 reboot Who will check, please write
-- You are receiving this mail because: You are on the CC list for the bug.
g_main_context_check g_main_context_prepare ibus g_source_iter_next
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c141
--- Comment #141 from Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c142
--- Comment #142 from Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c143
Richard Brown
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c144
--- Comment #144 from Victor Zhestkov
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c145
--- Comment #145 from Victor Zhestkov
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c146
--- Comment #146 from Takashi Iwai
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Mike Galbraith
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Libor Pechacek
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c151
--- Comment #151 from Dead Mozay
After my own testing, I've proposed changing to a kernel that uses VOLUNTARY preemption
https://lists.opensuse.org/opensuse-kernel/2019-02/msg00005.html
Anyone on Tumbleweed wishing to see if they can reproduce my findings can give the kernel I tried a go at https://download.opensuse.org/repositories/home:/favogt:/twvolun/standard/ x86_64/kernel-default-4.20.6-1.1.g463cfd2.x86_64.rpm
I tried this kernel on my laptop and ran a test in sysprof this is the initial data https://cloud.rfo13.ru/index.php/s/sQpk72nRXSESYpL This is after the kernel update. https://cloud.rfo13.ru/index.php/s/gCcaAHYNDopAdMd and this is after the update libmozjs-60 from my repository https://cloud.rfo13.ru/index.php/s/b8XDLsS3mAfFXrJ there is definitely progress, but visually almost nothing changes. I also stumbled upon such tests https://www.phoronix.com/scan.php?page=article&item=dellxps-9380-linux&num=1 Perhaps the author of the article is right, and the problem lies in energy consumption. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c152
--- Comment #152 from Timo Jyrinki
there is definitely progress, but visually almost nothing changes.
In your going through GNOME stack patches, did you find anything suspicious we're carrying that might be causing performance drops and should be dropped if not upstreamed? And dropping non-upstreamable patches is a good idea overall. I wouldn't (necessarily, unless having fun of course) spend time on doing things other distributions aren't doing, but finding the differences.
I also stumbled upon such tests https://www.phoronix.com/scan.php?page=article&item=dellxps-9380-linux&num=1 Perhaps the author of the article is right, and the problem lies in energy consumption.
Surely that's yet another part of the equation, but I've also tweaked my performance policies to be balance_performance which matches other distributions. And I've disabled hyperthreading, and using spectre_v2=retpoline. All of that makes things better, but not comparable to other distros. In addition to /sys/devices/system/cpu/*/*/energy_performance_preference (permanent via /etc/default/tlp) it'd be welcome to know if there are other knobs to turn that could be affecting what Phoronix found, but previously I haven't bumped to others that would be as important. I'd also be interested in trying out the voluntary preemption, to not rule out that and since that's clearly something that is not as easy to test (no runtime switch). Optimizing for smooth desktop usability seems to be really complex these days, and it seems that differing from what others do always has a negative impact due to that complexity. That's a bit sad state of affairs, and lack of performance work resources put to the desktop, but what can we do. It's nice though that Phoronix confirms that we're not all crazy. Sometimes user perceptions are biased or wrong, especially when it comes to "did it help?" if it's not a huge difference. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c153
--- Comment #153 from Dead Mozay
Thanks everyone for your continued investigations. Let's not despair, the solutions are there somewhere :)
(In reply to Dead Mozay from comment #151)
there is definitely progress, but visually almost nothing changes.
In your going through GNOME stack patches, did you find anything suspicious we're carrying that might be causing performance drops and should be dropped if not upstreamed? And dropping non-upstreamable patches is a good idea overall.
Unfortunately, I did not find anything concrete, except for the regressions in mozjs60, which are corrected by a regular update to a more recent version of this library, I also noticed a strange sqlite behavior, but after a while it disappeared, apparently then some background operations went, and the tracker-miners also behave the same way, after turning off the PC, it began to work quietly, when turned on, I constantly howled even in idle time. but all this did not lead to the desired result, Is that update mozjs fixed some animations
I wouldn't (necessarily, unless having fun of course) spend time on doing things other distributions aren't doing, but finding the differences.
Surely that's yet another part of the equation, but I've also tweaked my performance policies to be balance_performance which matches other distributions. And I've disabled hyperthreading, and using spectre_v2=retpoline. All of that makes things better, but not comparable to other distros.
For my PC and laptop, only the disabling of hyper threading is relevant now, the rest is no longer affected
It's nice though that Phoronix confirms that we're not all crazy.
I agree, when I started saying almost a year ago that there was a problem in GNOME, no one believed me, everyone claimed that everything was fine, then I decided that the problem could be in my hardware, but later at the presentation on the release day Leap 15 showed a laptop with installed Leap 15, and there it was already clear that lags are present, these lags were caused by the enabled SMT, then everything started with them, the performance drop was already noticeable in GNOME 3.28, but there is also an interesting point, GNOME 3.26 and 3.28 are susceptible to memory leakage but openSUSE is the only Linux distribution the tributary was at that time where there were no memory leaks in GNOME 3.28, but there was a performance drop, I then considered that a patch was corrected for leaks, but slightly degrading performance, I hoped that with the next release it would be better, but as it turned out worse -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c154
--- Comment #154 from Nicolás Luciano Bértolo
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c155
--- Comment #155 from Dead Mozay
One thing that is different in TW compared to Fedora, Ubuntu, etc. is btrfs as root filesystem.
It is known that gnome-shell likes to perform io operations in the rendering thread, so btrfs may be too slow for that? This is just speculation.
I wonder if anyone that is using ext4 as root fs can repro this behaviour.
The file system does not play a role, it was checked and there ext4 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c156
--- Comment #156 from Victor Zhestkov
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c157
Bruno Friedmann
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c158
--- Comment #158 from Dead Mozay
Invited to join as a non impacted users :-)
I share some informations : I'm using plasma5 with xorg and proprio nvidia drivers I didn't find or perceive any slowdown on my desktop in the last months.
I've tested geekbench and the result are there with a plain normal TW (up to date) https://browser.geekbench.com/v4/cpu/12014162
What I always apply is patch all hardware firmware for all component on my hardware some have direct relation with spectre/meldown and as my cpu is a xeon it is also preboot patched with kernel-firmware when the lastest Dell bios doesn't contain all fixes.
This is true, there are no such problems in plasma5, it worked for almost 2 days, everything was fine. but it's still not clear what causes problems in GNOME -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c159
--- Comment #159 from Nicolás Luciano Bértolo
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c161
--- Comment #161 from Nicolás Luciano Bértolo
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c162
--- Comment #162 from Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c163
--- Comment #163 from Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Roy Lee
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Artem Tim
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c164
--- Comment #164 from Timo Jyrinki
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Timo Jyrinki
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Timo Jyrinki
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c165
--- Comment #165 from Timo Jyrinki
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c166
--- Comment #166 from Richard Brown
This mainly just confirms that a) performance with defaults is very bad, quite unusable, b) performance with known tweaks is better, but still far worse than it should be.
It supports, but I wouldn't say it confirms much After all, what versions of what packages are being really tested there? Is Ubuntu GNOME using identical binaries to openSUSE GNOME? If no, then those changes could be part of the factor Does Ubuntu GNOME have additional patches, or less patches than oepnSUSE GNOME? Those differences could be part of this story And the same for all of the libraries and even the kernel in use.. your testing helps, but without a full analysis of the differences at play, it doesn't help us a great deal. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c167
--- Comment #167 from Timo Jyrinki
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c168
--- Comment #168 from Robert Munteanu
Something on my mind is to check that 20181015 <-> 20181018 snapshot delta mentioned in comment #160 and see if the difference is as big as what I have there on the video between distributions.
I think this is the first step that can be done. I unfortunately don't have a spare machine and the time to run the tests, but I think a binary search in the updates that were applied between 20181015 and 20181018 would help pinpoint the root cause. Assuming that the 20181018 snapshot has broken performance, there are N package updates between 20181015 and 20181018. One can split these N package updates in N1 and N2. It should happen that one of these contains the problematic update, so applying N1 (for instance) should reproduce the problem but not N2. And so on and so forth. If anyone has the possibility to do this I think it would be a worthwhile exercise. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c169
--- Comment #169 from Dead Mozay
(In reply to Timo Jyrinki from comment #167)
Something on my mind is to check that 20181015 <-> 20181018 snapshot delta mentioned in comment #160 and see if the difference is as big as what I have there on the video between distributions.
I think this is the first step that can be done. I unfortunately don't have a spare machine and the time to run the tests, but I think a binary search in the updates that were applied between 20181015 and 20181018 would help pinpoint the root cause.
Assuming that the 20181018 snapshot has broken performance, there are N package updates between 20181015 and 20181018. One can split these N package updates in N1 and N2. It should happen that one of these contains the problematic update, so applying N1 (for instance) should reproduce the problem but not N2. And so on and so forth.
If anyone has the possibility to do this I think it would be a worthwhile exercise.
It is not necessary to have another PC, you can use the virtualbox 6.x version and choose VMSVGA as the graphic controller, there is very good performance in GNOME, there is a list of updates here
http://mirror.tspu.ru/opensuse/tumbleweed/iso/Changes.20181018.txt
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c170
--- Comment #170 from Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c171
--- Comment #171 from Dead Mozay
sudo zypper ar -f obs://home:Dead_Mozay:branches:openSUSE:Factory home:Dead_Mozay:branches:openSUSE:Factory and update with vendor change sudo zypper dup --from home:Dead_Mozay:branches:openSUSE:Factory --allow-vendor-change
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c172
--- Comment #172 from Robert Munteanu
Anyone can check
sudo zypper ar -f obs://home:Dead_Mozay:branches:openSUSE:Factory home:Dead_Mozay:branches:openSUSE:Factory and update with vendor change sudo zypper dup --from home:Dead_Mozay:branches:openSUSE:Factory --allow-vendor-change
Cool, thanks for setting this up! For the record, these are the instructions that worked for me $ sudo zypper ar -r https://download.opensuse.org/repositories/home:/Dead_Mozay:/branches:/openS... $ sudo zypper dup --from home_Dead_Mozay_branches_openSUSE_Factory --allow-vendor-change And even though the package is a branch of openSUSE_Factory, which sounds scary, it only brings in mutter with 4 additional patches: The following 4 packages are going to be upgraded: libmutter-3-0 mutter mutter-data mutter-lang In my testing the lag situation seems to be improved, although not completely smooth yet: - when hitting the 'super' key to open the applications menu, the delay is much smaller, but still noticeable - when pressings the 'show applications' button there is a definite stutter/delay when the application icons should be flying in So a definite improvement, but still not as it should be. Host info: $ inxi -G -v 1 System: Host: rombert.corp.adobe.com Kernel: 4.20.12-1-default x86_64 bits: 64 Desktop: Gnome 3.30.2 Distro: openSUSE Tumbleweed 20190301 CPU: 6-Core: Intel Core i7-8850H type: MT MCP speed: 800 MHz min/max: 800/4300 MHz Graphics: Device-1: Intel UHD Graphics 630 driver: i915 v: kernel Device-2: NVIDIA GP107GLM [Quadro P2000 Mobile] driver: nvidia v: 418.43 Display: x11 server: X.Org 1.20.4 driver: modesetting,nvidia resolution: 3840x2160~60Hz OpenGL: renderer: Quadro P2000/PCIe/SSE2 v: 4.6.0 NVIDIA 418.43 Drives: Local Storage: total: 961.19 GiB used: 97.53 GiB (10.1%) Info: Processes: 367 Uptime: 4h 16m Memory: 31.03 GiB used: 5.61 GiB (18.1%) Shell: bash inxi: 3.0.32 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c173
--- Comment #173 from Robert Munteanu
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c173
--- Comment #173 from Robert Munteanu
(In reply to Dead Mozay from comment #171)
Anyone can check
sudo zypper ar -f obs://home:Dead_Mozay:branches:openSUSE:Factory home:Dead_Mozay:branches:openSUSE:Factory and update with vendor change sudo zypper dup --from home:Dead_Mozay:branches:openSUSE:Factory --allow-vendor-change
Cool, thanks for setting this up!
For the record, these are the instructions that worked for me
$ sudo zypper ar -r https://download.opensuse.org/repositories/home:/Dead_Mozay:/branches:/ openSUSE:/Factory/openSUSE_Factory/home:Dead_Mozay:branches:openSUSE:Factory. repo $ sudo zypper dup --from home_Dead_Mozay_branches_openSUSE_Factory --allow-vendor-change
And even though the package is a branch of openSUSE_Factory, which sounds scary, it only brings in mutter with 4 additional patches:
The following 4 packages are going to be upgraded: libmutter-3-0 mutter mutter-data mutter-lang
In my testing the lag situation seems to be improved, although not completely smooth yet:
- when hitting the 'super' key to open the applications menu, the delay is much smaller, but still noticeable - when pressings the 'show applications' button there is a definite stutter/delay when the application icons should be flying in
So a definite improvement, but still not as it should be.
Host info:
$ inxi -G -v 1 System: Host: rombert.corp.adobe.com Kernel: 4.20.12-1-default x86_64 bits: 64 Desktop: Gnome 3.30.2 Distro: openSUSE Tumbleweed 20190301 CPU: 6-Core: Intel Core i7-8850H type: MT MCP speed: 800 MHz min/max: 800/4300 MHz Graphics: Device-1: Intel UHD Graphics 630 driver: i915 v: kernel Device-2: NVIDIA GP107GLM [Quadro P2000 Mobile] driver: nvidia v: 418.43 Display: x11 server: X.Org 1.20.4 driver: modesetting,nvidia resolution: 3840x2160~60Hz OpenGL: renderer: Quadro P2000/PCIe/SSE2 v: 4.6.0 NVIDIA 418.43 Drives: Local Storage: total: 961.19 GiB used: 97.53 GiB (10.1%) Info: Processes: 367 Uptime: 4h 16m Memory: 31.03 GiB used: 5.61 GiB (18.1%) Shell: bash inxi: 3.0.32
that's why I wrote that partially solves the problem, if hyper threading is enabled, try disabling -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c175
--- Comment #175 from Robert Munteanu
(In reply to Robert Munteanu from comment #172)
(In reply to Dead Mozay from comment #171)
Anyone can check
sudo zypper ar -f obs://home:Dead_Mozay:branches:openSUSE:Factory home:Dead_Mozay:branches:openSUSE:Factory and update with vendor change sudo zypper dup --from home:Dead_Mozay:branches:openSUSE:Factory --allow-vendor-change
Cool, thanks for setting this up!
For the record, these are the instructions that worked for me
$ sudo zypper ar -r https://download.opensuse.org/repositories/home:/Dead_Mozay:/branches:/ openSUSE:/Factory/openSUSE_Factory/home:Dead_Mozay:branches:openSUSE:Factory. repo $ sudo zypper dup --from home_Dead_Mozay_branches_openSUSE_Factory --allow-vendor-change
And even though the package is a branch of openSUSE_Factory, which sounds scary, it only brings in mutter with 4 additional patches:
The following 4 packages are going to be upgraded: libmutter-3-0 mutter mutter-data mutter-lang
In my testing the lag situation seems to be improved, although not completely smooth yet:
- when hitting the 'super' key to open the applications menu, the delay is much smaller, but still noticeable - when pressings the 'show applications' button there is a definite stutter/delay when the application icons should be flying in
So a definite improvement, but still not as it should be.
Host info:
$ inxi -G -v 1 System: Host: rombert.corp.adobe.com Kernel: 4.20.12-1-default x86_64 bits: 64 Desktop: Gnome 3.30.2 Distro: openSUSE Tumbleweed 20190301 CPU: 6-Core: Intel Core i7-8850H type: MT MCP speed: 800 MHz min/max: 800/4300 MHz Graphics: Device-1: Intel UHD Graphics 630 driver: i915 v: kernel Device-2: NVIDIA GP107GLM [Quadro P2000 Mobile] driver: nvidia v: 418.43 Display: x11 server: X.Org 1.20.4 driver: modesetting,nvidia resolution: 3840x2160~60Hz OpenGL: renderer: Quadro P2000/PCIe/SSE2 v: 4.6.0 NVIDIA 418.43 Drives: Local Storage: total: 961.19 GiB used: 97.53 GiB (10.1%) Info: Processes: 367 Uptime: 4h 16m Memory: 31.03 GiB used: 5.61 GiB (18.1%) Shell: bash inxi: 3.0.32
that's why I wrote that partially solves the problem, if hyper threading is enabled, try disabling
Yes, with: - your patches to mutter - hyper-threading disabled in BIOS - the latest TW kernel with the updated default config # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set Then responsiveness is spot on. I'll post another screencap for comparison. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c176
--- Comment #176 from Robert Munteanu
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c177
--- Comment #177 from Michael G
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c178
Carson Black
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Juan Ramos
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c179
David Walker
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Jeffrey Cheung
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
Vadim Krevs
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c184
Dead Mozay
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c192
--- Comment #192 from Wolfgang Rosenauer
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c193
--- Comment #193 from Wolfgang Rosenauer
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c196
--- Comment #196 from Robert Munteanu
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c197
--- Comment #197 from Timo Jyrinki
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c200
--- Comment #200 from Timo Jyrinki
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c201
--- Comment #201 from James Wang
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c202
--- Comment #202 from James Wang
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c203
--- Comment #203 from James Wang
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c204
--- Comment #204 from Sebastian Parschauer
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c210
--- Comment #210 from Dead Mozay
Hey,
"x86_energy_perf_policy" be changed between "AC mode" and "Bat mode", seems like root cause.
I will upload AC mode log and Bat mode log, they come from tlp-stat report.
We recently had a discussion about x86_energy_perf_policy that might be related: We dropped an upstream patch in some kernel code-streams for the x86_energy_perf_policy handling because it was broken, but it turned out, that that wasn't working either.
See the discussion here: https://patchwork.kernel.org/patch/10853023/
As response to this thread, Rafael made a new patch improving the handling, see this thread: https://patchwork.kernel.org/patch/10862699/
I don't know the state of that patch, according to patchwork it is not yet merged upstream.
Is this related?
almost all problems were solved by disabling debugging when building mozjs60 https://build.opensuse.org/request/show/706263 Animations have become smooth, but there are still some jerks in animations, but overall it is much better. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c230
--- Comment #230 from Timo Jyrinki
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824#c236
Dominique Leuenberger
participants (2)
-
bugzilla_noreply@novell.com
-
bugzilla_noreply@suse.com