Hi,
I was watching the issue for a few weeks now and it's bad enough to post here finally because I'm not sure if I have enough information for a bugreport.
I was running Leap 15.1 on my system - Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz (4 core) - 16GiB RAM - builtin Intel graphics (i915) - SSD - Xfce
15.1 was running quite smooth for me.
Since the upgrade to 15.2 it pretty quickly (under some sort of load) gets into a state where the desktop is stuttering with everything: - mouse movement gets stuck - windows do not appear instantly - switching desktops is delayed, rerendering takes quite long
The point is that I cannot even tell which type of load exactly is causing this behaviour but it is not a lot. As I'm writing this mail my load average in top shows 0,27 but still when moving my mouse it stutters. Another example: When I upload a larger amount of data to the internet my UI also seems to be affected.
I really have no idea how to track that down more but it's annoying and it started exactly after update to 15.2.
Any ideas, hints, feedback?
Thanks, Wolfgang
09.08.2020 10:41, Wolfgang Rosenauer пишет:
Hi,
I was watching the issue for a few weeks now and it's bad enough to post here finally because I'm not sure if I have enough information for a bugreport.
I was running Leap 15.1 on my system
- Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz (4 core)
- 16GiB RAM
- builtin Intel graphics (i915)
- SSD
- Xfce
15.1 was running quite smooth for me.
Since the upgrade to 15.2 it pretty quickly (under some sort of load) gets into a state where the desktop is stuttering with everything:
- mouse movement gets stuck
I had similar effects on Ubuntu after update from kernel 5.0 to 5.3. Effects appeared as soon as system started to use swap (it did not matter what amount, even several MB was already enough). Same was with kernel 5.4, I ended up using kernel 5.5.
- windows do not appear instantly
- switching desktops is delayed, rerendering takes quite long
The point is that I cannot even tell which type of load exactly is causing this behaviour but it is not a lot. As I'm writing this mail my load average in top shows 0,27 but still when moving my mouse it stutters. Another example: When I upload a larger amount of data to the internet my UI also seems to be affected.
I really have no idea how to track that down more but it's annoying and it started exactly after update to 15.2.
Any ideas, hints, feedback?
You may try more recent kernel to compare.
On 8/9/20 3:15 AM, Andrei Borzenkov wrote:
15.1 was running quite smooth for me.
Since the upgrade to 15.2 it pretty quickly (under some sort of load) gets into a state where the desktop is stuttering with everything:
- mouse movement gets stuck
I had similar effects on Ubuntu after update from kernel 5.0 to 5.3. Effects appeared as soon as system started to use swap (it did not matter what amount, even several MB was already enough). Same was with kernel 5.4, I ended up using kernel 5.5.
- windows do not appear instantly
- switching desktops is delayed, rerendering takes quite long
In addition to Andrei's suggestion, search for recent i915 issues. I seem to recall reading a recent article about troubles with the drivers under certain conditions -- but can't for the life of me recall what or where. (I don't have one, so I read in passing). A different kernel test would be the same quick check for a solution.
Am 09.08.20 um 10:15 schrieb Andrei Borzenkov:
09.08.2020 10:41, Wolfgang Rosenauer пишет:
Hi,
I was watching the issue for a few weeks now and it's bad enough to post here finally because I'm not sure if I have enough information for a bugreport.
I was running Leap 15.1 on my system
- Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz (4 core)
- 16GiB RAM
- builtin Intel graphics (i915)
- SSD
- Xfce
15.1 was running quite smooth for me.
Since the upgrade to 15.2 it pretty quickly (under some sort of load) gets into a state where the desktop is stuttering with everything:
- mouse movement gets stuck
In case you are running btrfs, you might have some tree-balancing. This can take up an hour or two. But once it's done, you are fine.
You can see a process called "btrfs-balance" or similar with ps -e, top your your process-list-window of your DE.
I had similar effects on Ubuntu after update from kernel 5.0 to 5.3. Effects appeared as soon as system started to use swap (it did not matter what amount, even several MB was already enough). Same was with kernel 5.4, I ended up using kernel 5.5.
Interesting. With openSuse 15.2. my problems with swap have finally been solved. I was struggling since the 13.x-series.
- windows do not appear instantly
- switching desktops is delayed, rerendering takes quite long
The point is that I cannot even tell which type of load exactly is causing this behaviour but it is not a lot. As I'm writing this mail my load average in top shows 0,27 but still when moving my mouse it stutters. Another example: When I upload a larger amount of data to the internet my UI also seems to be affected.
I really have no idea how to track that down more but it's annoying and it started exactly after update to 15.2.
Any ideas, hints, feedback?
You may try more recent kernel to compare.
On 09/08/2020 12.37, Simon Heimbach wrote:
Am 09.08.20 um 10:15 schrieb Andrei Borzenkov:
09.08.2020 10:41, Wolfgang Rosenauer пишет:
...
I had similar effects on Ubuntu after update from kernel 5.0 to 5.3. Effects appeared as soon as system started to use swap (it did not matter what amount, even several MB was already enough). Same was with kernel 5.4, I ended up using kernel 5.5.
Interesting. With openSuse 15.2. my problems with swap have finally been solved. I was struggling since the 13.x-series.
This is very interesting. In my experience, swap changed to the bad from 13.x to Leap. I don't have any 15.2 yet to compare.
I called the issue "swap fragmentation". The hard disk was constantly seeking to locate the areas to read or write on swap. My solution was to buy an SSD and put swap on it: besides the increased read/write speed, the seek time is basically nil, so there is no fragmentation penalization.
Now all my working machines are on SSD, so I will not be able to check if this "fragmentation" has been solved on 15.2.
Le 09/08/2020 à 09:41, Wolfgang Rosenauer a écrit :
I really have no idea how to track that down more but it's annoying and it started exactly after update to 15.2.
well...I have similar problem with 15.1 :-(
sometime, with no visible reason, the kde desktop freeze for a long time
at first seems related to bus use (copy between disks, download, upload...), but nothing really obvious
jdd
* Wolfgang Rosenauer wolfgang@rosenauer.org [08-09-20 03:43]:
Hi,
I was watching the issue for a few weeks now and it's bad enough to post here finally because I'm not sure if I have enough information for a bugreport.
I was running Leap 15.1 on my system
- Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz (4 core)
- 16GiB RAM
- builtin Intel graphics (i915)
- SSD
- Xfce
15.1 was running quite smooth for me.
Since the upgrade to 15.2 it pretty quickly (under some sort of load) gets into a state where the desktop is stuttering with everything:
- mouse movement gets stuck
- windows do not appear instantly
- switching desktops is delayed, rerendering takes quite long
The point is that I cannot even tell which type of load exactly is causing this behaviour but it is not a lot. As I'm writing this mail my load average in top shows 0,27 but still when moving my mouse it stutters. Another example: When I upload a larger amount of data to the internet my UI also seems to be affected.
I really have no idea how to track that down more but it's annoying and it started exactly after update to 15.2.
Any ideas, hints, feedback?
although I run Tw, I also noticed a recent graphical slow-down and solved it by turning off composting. But my difficulty may be related to my quite old video card, NVIDIA GF106 [GeForce GTS 450].
to toggle composting on/off, <alt><shift><f12>
On 8/9/20 3:41 AM, Wolfgang Rosenauer wrote:
Since the upgrade to 15.2 it pretty quickly (under some sort of load) gets into a state where the desktop is stuttering with everything:
- mouse movement gets stuck
- windows do not appear instantly
- switching desktops is delayed, rerendering takes quite long
I have been experiencing the same thing. I keep the System Monitor (KSysGuard) running, so I can keep a eye on it. When it happens, all 8 CPU cores are running at or near 100 percent and I'm not using anywhere near the maximum memory, with little swap. Yesterday, I had to use a different computer, to have a video chat with some friends, as my main computer was completely unusable.
On 09-08-2020 16:06, James Knott wrote:
On 8/9/20 3:41 AM, Wolfgang Rosenauer wrote:
Since the upgrade to 15.2 it pretty quickly (under some sort of load) gets into a state where the desktop is stuttering with everything:
- mouse movement gets stuck
- windows do not appear instantly
- switching desktops is delayed, rerendering takes quite long
I have been experiencing the same thing. I keep the System Monitor (KSysGuard) running, so I can keep a eye on it. When it happens, all 8 CPU cores are running at or near 100 percent and I'm not using anywhere near the maximum memory, with little swap. Yesterday, I had to use a different computer, to have a video chat with some friends, as my main computer was completely unusable.
Did you try a fresh and new created account to exclude the possibility of config corruption.
On 8/9/20 12:12 PM, JJM de Faber wrote:
Did you try a fresh and new created account to exclude the possibility of config corruption.
What sort of user config could cause all 8 cores to max out?
Anyway, I tried that <alt><shift>F12 and it seems OK so far, but I'll have to watch it.
On 09/08/2020 18.32, James Knott wrote:
On 8/9/20 12:12 PM, JJM de Faber wrote:
Did you try a fresh and new created account to exclude the possibility of config corruption.
What sort of user config could cause all 8 cores to max out?
LOTS! For instance, the other user could be using a different desktop completely :-D
Or simply, a different compossing.
Anyway, I tried that <alt><shift>F12 and it seems OK so far, but I'll have to watch it.
On 8/9/20 3:13 PM, Carlos E. R. wrote:
LOTS! For instance, the other user could be using a different desktop completely :-D
I'm the only user. My cat & dog don't use the computer very much. ;-)
On 09/08/2020 21.19, James Knott wrote:
On 8/9/20 3:13 PM, Carlos E. R. wrote:
LOTS! For instance, the other user could be using a different desktop completely :-D
I'm the only user. My cat & dog don't use the computer very much. ;-)
Who cares you are the only user? I have a dozen users defined on the machine, for my sole use.
On Sun, 9 Aug 2020 21:13:32 +0200 "Carlos E. R." robin.listas@telefonica.net wrote:
On 09/08/2020 18.32, James Knott wrote:
On 8/9/20 12:12 PM, JJM de Faber wrote:
Did you try a fresh and new created account to exclude the possibility of config corruption.
What sort of user config could cause all 8 cores to max out?
LOTS! For instance, the other user could be using a different desktop completely :-D
What other user?
Or simply, a different compossing.
I suppose you mean compositing, just like the other person who referred to composting? But if you do then you're way outside my experience. I try to avoid composting except in my garden :)
Anyway, I tried that <alt><shift>F12 and it seems OK so far, but I'll have to watch it.
On 09/08/2020 21.22, Dave Howorth wrote:
On Sun, 9 Aug 2020 21:13:32 +0200 "Carlos E. R." robin.listas@telefonica.net wrote:
On 09/08/2020 18.32, James Knott wrote:
On 8/9/20 12:12 PM, JJM de Faber wrote:
Did you try a fresh and new created account to exclude the possibility of config corruption.
What sort of user config could cause all 8 cores to max out?
LOTS! For instance, the other user could be using a different desktop completely :-D
What other user?
Start yast, user management, create user. :-)
Or simply, a different compossing.
I suppose you mean compositing, just like the other person who referred to composting? But if you do then you're way outside my experience. I try to avoid composting except in my garden :)
:-)
Anyway, I tried that <alt><shift>F12 and it seems OK so far, but I'll have to watch it.
On 8/9/20 12:32 PM, James Knott wrote:
Anyway, I tried that <alt><shift>F12 and it seems OK so far, but I'll have to watch it.
That doesn't seem to have helped. I even booted the previous kernel, but no difference. One thing I've noticed is top shows "Web Content" as a big hog. I don't ever recall seeing that, in all the years I've been using top.
On 10/08/2020 13.06, James Knott wrote:
On 8/9/20 12:32 PM, James Knott wrote:
Anyway, I tried that <alt><shift>F12 and it seems OK so far, but I'll have to watch it.
That doesn't seem to have helped. I even booted the previous kernel, but no difference. One thing I've noticed is top shows "Web Content" as a big hog. I don't ever recall seeing that, in all the years I've been using top.
That's Firefox. Just kill that process, it causes thi guilty tabs in FF to die. You can click to restart them, or not.
Some of the pages you load causes that.
On 8/10/20 7:22 AM, Carlos E. R. wrote:
That doesn't seem to have helped. I even booted the previous kernel, but no difference. One thing I've noticed is top shows "Web Content" as a big hog. I don't ever recall seeing that, in all the years I've been using top.
That's Firefox. Just kill that process, it causes thi guilty tabs in FF to die. You can click to restart them, or not.
I have killed Firefox many times, even before this issue, so I'm quite familiar with that. However, it seems to be more related to Chromium.
Some of the pages you load causes that.
The pages I load haven't changed much from what I've been using prior to this. In fact, just looking at the list, there is nothing that I haven't been reading since well before this particular issue.
On 10/08/2020 14.49, James Knott wrote:
On 8/10/20 7:22 AM, Carlos E. R. wrote:
That doesn't seem to have helped. I even booted the previous kernel, but no difference. One thing I've noticed is top shows "Web Content" as a big hog. I don't ever recall seeing that, in all the years I've been using top.
That's Firefox. Just kill that process, it causes thi guilty tabs in FF to die. You can click to restart them, or not.
I have killed Firefox many times, even before this issue, so I'm quite familiar with that. However, it seems to be more related to Chromium.
No, I'm not saying "kill Firefox" (nor Chrome), but kill "Web Content". Different thing.
Some of the pages you load causes that.
The pages I load haven't changed much from what I've been using prior to this. In fact, just looking at the list, there is nothing that I haven't been reading since well before this particular issue.
Doesn't matter.
On 8/10/20 8:51 AM, Carlos E.R. wrote:
I have killed Firefox many times, even before this issue, so I'm quite familiar with that. However, it seems to be more related to Chromium.
No, I'm not saying "kill Firefox" (nor Chrome), but kill "Web Content". Different thing.
Some of the pages you load causes that.
The pages I load haven't changed much from what I've been using prior to this. In fact, just looking at the list, there is nothing that I haven't been reading since well before this particular issue.
I tried killing Web Content and it made no difference. However, the problem does appear to be related to Chromium. I normally run Google GMail, Calendar, Contacts and Messages in 4 tabs all the time and have Chromium configured to open all 4 when I start it. After I start it, I can see the CPU usage go to max on all 8 cores and then when I kill, things go back to normal. I have been using Chromium that way for years, yet this problem just started very recently. IIRC, there was a Chromium update recently. The thing is, it doesn't always go to max when I start Chromium. I just started it now and everything looks normal, but the problem happened when I started it a few minutes ago. I'm currently using about 5 GB of memory out of 16 and no swap. This is typical of when the problem happens. CPU is currently very low (a few percent) on all 8 cores.
On 10/08/2020 15.41, James Knott wrote:
On 8/10/20 8:51 AM, Carlos E.R. wrote:
I have killed Firefox many times, even before this issue, so I'm quite familiar with that. However, it seems to be more related to Chromium.
No, I'm not saying "kill Firefox" (nor Chrome), but kill "Web Content". Different thing.
Some of the pages you load causes that.
The pages I load haven't changed much from what I've been using prior to this. In fact, just looking at the list, there is nothing that I haven't been reading since well before this particular issue.
I tried killing Web Content and it made no difference. However, the problem does appear to be related to Chromium. I normally run Google GMail, Calendar, Contacts and Messages in 4 tabs all the time and have Chromium configured to open all 4 when I start it. After I start it, I can see the CPU usage go to max on all 8 cores and then when I kill, things go back to normal. I have been using Chromium that way for years, yet this problem just started very recently. IIRC, there was a Chromium update recently. The thing is, it doesn't always go to max when I start Chromium. I just started it now and everything looks normal, but the problem happened when I started it a few minutes ago. I'm currently using about 5 GB of memory out of 16 and no swap. This is typical of when the problem happens. CPU is currently very low (a few percent) on all 8 cores.
Ok, so you have four tabs. Killing "Web Content" should kill _one_ of those 4 tabs. Which?
Explanation. Web browsers now start several threads - for example, Firefox seems to start 8 by default, and distribute the tabs evenly between those threads. So if you have 4 tabs only, killing one thread should kill one tab.
Which tab? There is some broken web page in that tab.
On 8/10/20 2:05 PM, Carlos E. R. wrote:
Ok, so you have four tabs. Killing "Web Content" should kill _one_ of those 4 tabs. Which?
Explanation. Web browsers now start several threads - for example, Firefox seems to start 8 by default, and distribute the tabs evenly between those threads. So if you have 4 tabs only, killing one thread should kill one tab.
Which tab? There is some broken web page in that tab.
I didn't check which tabs. However, those 4 Google pages were in Chromium, not Firefox and killing Web Content seemed to work on Firefox only. I'll have to try again next time it bogs down. It seems to be OK right now, with all cores bouncing around 10% or so and 4.5 GB of memory used and no swap.
BTW, I tried in my test account with only a browser running a single tab & speedtest.net. Firefox was a bit poorer than normal and Chromium was much worse. I typically get low 90s down, but got upper 80s down with Firefox and about 7 with Chromium. This was on a freshly booted computer, running only the browser and System Monitor running.
On 10/08/2020 20.17, James Knott wrote:
On 8/10/20 2:05 PM, Carlos E. R. wrote:
Ok, so you have four tabs. Killing "Web Content" should kill _one_ of those 4 tabs. Which?
Explanation. Web browsers now start several threads - for example, Firefox seems to start 8 by default, and distribute the tabs evenly between those threads. So if you have 4 tabs only, killing one thread should kill one tab.
Which tab? There is some broken web page in that tab.
I didn't check which tabs. However, those 4 Google pages were in Chromium, not Firefox and killing Web Content seemed to work on Firefox only. I'll have to try again next time it bogs down. It seems to be OK right now, with all cores bouncing around 10% or so and 4.5 GB of memory used and no swap.
Just have a terminal runing "top", it will say what process is hogging the cpu. Pressing "k" (kill) will offer to kill just that one on the top. Easy peasy.
BTW, I tried in my test account with only a browser running a single tab & speedtest.net. Firefox was a bit poorer than normal and Chromium was much worse. I typically get low 90s down, but got upper 80s down with Firefox and about 7 with Chromium. This was on a freshly booted computer, running only the browser and System Monitor running.
On 8/10/20 2:21 PM, Carlos E. R. wrote:
Just have a terminal runing "top"
Hmmm... I used to have an ADM-3 terminal and used to work a lot with DEC VT-100s. ;-)
https://en.wikipedia.org/wiki/ADM-3A https://en.wikipedia.org/wiki/VT100
On Mon, 10 Aug 2020 14:30:45 -0400 James Knott james.knott@jknott.net wrote:
On 8/10/20 2:21 PM, Carlos E. R. wrote:
Just have a terminal runing "top"
Hmmm... I used to have an ADM-3 terminal and used to work a lot with DEC VT-100s. ;-)
https://en.wikipedia.org/wiki/ADM-3A https://en.wikipedia.org/wiki/VT100
Well if it was actually an ADM-3A and certainly for a VT100, they have the cursor-addressing capability to make top work :)
Dunno if it actually does, or course although both
$ TERM=vt100 top $ TERM=adm3a top
do:)
and even TERM=adm3 does so I think there's a bit of artistic licence.
On 8/10/20 3:06 PM, Dave Howorth wrote:
Well if it was actually an ADM-3A and certainly for a VT100, they have the cursor-addressing capability to make top work:)
Dunno if it actually does, or course although both
$ TERM=vt100 top $ TERM=adm3a top
do:)
and even TERM=adm3 does so I think there's a bit of artistic licence.
Please note, I said "used to". ;-)
It's been over 30 years since I last touched a VT-100 and I gave away the ADM-3 even earlier. BTW, I also used to have an ASR 35 Teletype, but it's long gone too.
* James Knott james.knott@jknott.net [08-10-20 15:17]:
On 8/10/20 3:06 PM, Dave Howorth wrote:
Well if it was actually an ADM-3A and certainly for a VT100, they have the cursor-addressing capability to make top work:)
Dunno if it actually does, or course although both
$ TERM=vt100 top $ TERM=adm3a top
do:)
and even TERM=adm3 does so I think there's a bit of artistic licence.
Please note, I said "used to". ;-)
It's been over 30 years since I last touched a VT-100 and I gave away the ADM-3 even earlier. BTW, I also used to have an ASR 35 Teletype, but it's long gone too.
is any of this really relevant to your problem?
On 10-08-2020 13:06, James Knott wrote:
On 8/9/20 12:32 PM, James Knott wrote:
Anyway, I tried that <alt><shift>F12 and it seems OK so far, but I'll have to watch it.
That doesn't seem to have helped. I even booted the previous kernel, but no difference. One thing I've noticed is top shows "Web Content" as a big hog. I don't ever recall seeing that, in all the years I've been using top.
Did you create a new fresh account with all config default ?
I don't know what <alt><shift>F12 does.
A new account is created via yast "security and Users" "User and group management".
Create an account named "test" or something and login to the new account.
If you don't have any problem in "test" the problem is at your old account level.
regards,Hans
* JJM de Faber hans.defaber@gmail.com [08-10-20 07:37]:
On 10-08-2020 13:06, James Knott wrote:
On 8/9/20 12:32 PM, James Knott wrote:
Anyway, I tried that <alt><shift>F12 and it seems OK so far, but I'll have to watch it.
That doesn't seem to have helped. I even booted the previous kernel, but no difference. One thing I've noticed is top shows "Web Content" as a big hog. I don't ever recall seeing that, in all the years I've been using top.
Did you create a new fresh account with all config default ?
I don't know what <alt><shift>F12 does.
It starts/stops (toggle) the display compositor
On 8/10/20 8:05 AM, Patrick Shanahan wrote:
It starts/stops (toggle) the display compositor
Does it survive reboots? Also, I tried it and it didn't make much difference.
On 2020-08-10 6:50 a.m., James Knott wrote:
On 8/10/20 8:05 AM, Patrick Shanahan wrote:
It starts/stops (toggle) the display compositor
Does it survive reboots? Also, I tried it and it didn't make much difference.
System settings --> Display management --> Compositor: toggle "Enable compositor on startup"
On 8/10/20 10:23 AM, Darryl Gregorash wrote:
System settings --> Display management --> Compositor: toggle "Enable compositor on startup"
On that, I see this message:
"OpenGL compositing (the default) has crashed KWin in the past.
This was most likely due to a driver bug.
If you think that you have meanwhile upgraded to a stable driver,
you can reset this protection but be aware that this might result in an immediate crash!
Alternatively, you might want to use the XRender backend instead."
Should I turn it on?
On 2020-08-10 12:06 p.m., James Knott wrote:
Should I turn it on?
I have no idea, James. The only performance "issue" I have seen is that Firefox takes an infinite amount of time to shut down. That first showed up with 15.1, after a FF update. What surprised me, though, is that my boot drive is now a NVMe, and that is where everything lives.
But I have not had any other issues with performance.
On 8/10/20 7:34 AM, JJM de Faber wrote:
Did you create a new fresh account with all config default ?
I do have a test account, which is rarely used. However, this issue is recent. Every week, I have a video chat with some friends and it normally goes well. However, this past Saturday, my computer was completely unusable for that chat. I get the impression that it might be related to Chromium, but can't say for certain. Both it and the kernel have been updated recently. I am also not the only one here that seems to have that issue. Also, it doesn't appear to be a memory issue, as it happens when I'm using less than half the memory and little or no swap.
On 10/08/2020 15.25, James Knott wrote:
On 8/10/20 7:34 AM, JJM de Faber wrote:
Did you create a new fresh account with all config default ?
I do have a test account, which is rarely used.
Well, try with that user. Even better, a completely new user, created today. Just do it, don't argue :-)
-
Andrei Borzenkov -
Carlos E. R. -
Carlos E.R. -
Darryl Gregorash -
Dave Howorth -
David C. Rankin -
James Knott -
jdd＠dodin.org -
JJM de Faber -
Patrick Shanahan -
Simon Heimbach -
Wolfgang Rosenauer