[arch-general] High lag in graphical applications
Hello everyone, I've got some serious lag in using graphical applications since Sunday. I was able to narrow it down quite a bit, but I can't find a solution. I'm using a ThinkPad P50s with Intel HD 520 and NVIDIA Quadro M500M graphics (but, AFAIK, only the Intel Graphics are used) with X11 and i3. Since Sunday, when using applications like thunar, xfce-terminal, firefox, thunderbird, ... every interaction (starting, clicking a menu, a menu item, sometimes even hovering) caused the whole GUI to freeze from ~5 secs to up to 30 secs (thunar seemed to be the worst, with folders opening in no less than 30 secs). However, scrolling lists, webpages, typing text, using terminal applications... worked with no lag. I ran multiple system updates every day, ensuring that my system was up-to-date, nothing helped. I tried switching to KDE then, noticing that while the old applications still caused the same lag, all KDE-Applications (KDE file manager etc.) worked with no lag. When switching from X11 to Wayland with KDE (or replacing i3 with sway), even the old applications (thunar, xfce-terminal, firefox, thunderbird, ...) work with nearly no lag. However, sometimes GUI interactions in thunderbird or firefox still cause high lag. When using XFCE, though, I couldn't find any noticeable lag. I tried downgrading the following packages (in that order): * mesa-vdpau (19.1.6-2 -> 19.1.5-1), lib32-mesa (19.1.6-1 -> 19.1.5-1), libva-mesa-driver (19.1.6-2 -> 19.1.5-1) * gtk3 (1:3.24.11-1 -> 1:3.24.10-1) * qt5-base (5.13.1-2 -> 5.13.0-7), qt5-declarative (5.13.1-1 -> 5.13.0-1), qt5-graphicaleffects (5.13.1-1 -> 5.13.0-1), qt5-imageformats (5.13.1-1 -> 5.13.0-1), qt5-location (5.13.1-1 -> 5.13.0-1), qt5-multimedia (5.13.1-1 -> 5.13.0-1), qt5-quickcontrols2 (5.13.1-1 -> 5.13.0-1), qt5-quickcontrols (5.13.1-1 -> 5.13.0-1), qt5-script (5.13.1-1 -> 5.13.0-1), qt5-sensors (5.13.1-1 -> 5.13.0-1), qt5-speech (5.13.1-1 -> 5.13.0-1), qt5-svg (5.13.1-1 -> 5.13.0-1), qt5-tools (5.13.1-1 -> 5.13.0-1), qt5-webchannel (5.13.1-1 -> 5.13.0-1), qt5-webengine (5.13.1-2 -> 5.13.0-1), qt5-webkit (5.212.0alpha3-4 -> 5.212.0alpha3-3), qt5-x11extras (5.13.1-1 -> 5.13.0-1), qt5-xmlpatterns (5.13.1-1 -> 5.13.0-1) * nvidia-utils (435.21-1 -> 430.40-2), nvidia (435.21-4 -> 430.40-5) * linux-headers (5.2.14.arch2-1 -> 5.2.4.arch1-1), linux-hardened-headers (5.2.14.a-1 -> 5.2.8.a-1), linux-firmware (20190815.07b925b-1 -> 20190717.bf13a71-1), linux-hardened (5.2.14.a-1 -> 5.2.8.a-1), linux (5.2.14.arch2-1 -> 5.2.4.arch1-1) * linux-firmware (20190717.bf13a71-1 -> 20190628.70e4394-1), linux (5.2.4.arch1-1 -> 5.1.16.arch1-1), linux-hardened (5.2.8.a-1 -> 5.1.16.a-1), linux-hardened-headers (5.2.8.a-1 -> 5.1.16.a-1), linux-headers (5.2.4.arch1-1 -> 5.1.16.arch1-1) * mesa (19.1.6-2 -> 19.1.5-1) And did a reboot after each step. However, none of them changed anything. Any ideas? Why does switching from i3 to KDE or even XFCE resolve the issue (partially)? Why does switching from X11 to Wayland do so as well? I'd like to continue using i3 without lag. Thanks in advance, Lukas
Hello Lukas, Firstly, could you provide output of the following command (requires mesa-demos): `glxinfo|grep Rendering` На 17 вересня 2019 р. в 18:20:53, LuKaRo (lists@lrose.de) написав:
Hello everyone,
I've got some serious lag in using graphical applications since Sunday. I was able to narrow it down quite a bit, but I can't find a solution.
I'm using a ThinkPad P50s with Intel HD 520 and NVIDIA Quadro M500M graphics (but, AFAIK, only the Intel Graphics are used) with X11 and i3. Since Sunday, when using applications like thunar, xfce-terminal, firefox, thunderbird, ... every interaction (starting, clicking a menu, a menu item, sometimes even hovering) caused the whole GUI to freeze from ~5 secs to up to 30 secs (thunar seemed to be the worst, with folders opening in no less than 30 secs). However, scrolling lists, webpages, typing text, using terminal applications... worked with no lag.
I ran multiple system updates every day, ensuring that my system was up-to-date, nothing helped.
I tried switching to KDE then, noticing that while the old applications still caused the same lag, all KDE-Applications (KDE file manager etc.) worked with no lag. When switching from X11 to Wayland with KDE (or replacing i3 with sway), even the old applications (thunar, xfce-terminal, firefox, thunderbird, ...) work with nearly no lag. However, sometimes GUI interactions in thunderbird or firefox still cause high lag. When using XFCE, though, I couldn't find any noticeable lag.
I tried downgrading the following packages (in that order):
* mesa-vdpau (19.1.6-2 -> 19.1.5-1), lib32-mesa (19.1.6-1 -> 19.1.5-1), libva-mesa-driver (19.1.6-2 -> 19.1.5-1) * gtk3 (1:3.24.11-1 -> 1:3.24.10-1) * qt5-base (5.13.1-2 -> 5.13.0-7), qt5-declarative (5.13.1-1 -> 5.13.0-1), qt5-graphicaleffects (5.13.1-1 -> 5.13.0-1), qt5-imageformats (5.13.1-1 -> 5.13.0-1), qt5-location (5.13.1-1 -> 5.13.0-1), qt5-multimedia (5.13.1-1 -> 5.13.0-1), qt5-quickcontrols2 (5.13.1-1 -> 5.13.0-1), qt5-quickcontrols (5.13.1-1 -> 5.13.0-1), qt5-script (5.13.1-1 -> 5.13.0-1), qt5-sensors (5.13.1-1 -> 5.13.0-1), qt5-speech (5.13.1-1 -> 5.13.0-1), qt5-svg (5.13.1-1 -> 5.13.0-1), qt5-tools (5.13.1-1 -> 5.13.0-1), qt5-webchannel (5.13.1-1 -> 5.13.0-1), qt5-webengine (5.13.1-2 -> 5.13.0-1), qt5-webkit (5.212.0alpha3-4 -> 5.212.0alpha3-3), qt5-x11extras (5.13.1-1 -> 5.13.0-1), qt5-xmlpatterns (5.13.1-1 -> 5.13.0-1) * nvidia-utils (435.21-1 -> 430.40-2), nvidia (435.21-4 -> 430.40-5) * linux-headers (5.2.14.arch2-1 -> 5.2.4.arch1-1), linux-hardened-headers (5.2.14.a-1 -> 5.2.8.a-1), linux-firmware (20190815.07b925b-1 -> 20190717.bf13a71-1), linux-hardened (5.2.14.a-1 -> 5.2.8.a-1), linux (5.2.14.arch2-1 -> 5.2.4.arch1-1) * linux-firmware (20190717.bf13a71-1 -> 20190628.70e4394-1), linux (5.2.4.arch1-1 -> 5.1.16.arch1-1), linux-hardened (5.2.8.a-1 -> 5.1.16.a-1), linux-hardened-headers (5.2.8.a-1 -> 5.1.16.a-1), linux-headers (5.2.4.arch1-1 -> 5.1.16.arch1-1) * mesa (19.1.6-2 -> 19.1.5-1)
And did a reboot after each step. However, none of them changed anything.
Any ideas? Why does switching from i3 to KDE or even XFCE resolve the issue (partially)? Why does switching from X11 to Wayland do so as well? I'd like to continue using i3 without lag.
Thanks in advance, Lukas
On 9/17/19 12:48 PM, Yurii Kolesnykov wrote:
Hello Lukas,
Firstly, could you provide output of the following command (requires mesa-demos):
`glxinfo|grep Rendering`
Or possibly glxinfo|grep rendering
Correct command is `glxinfo|grep -I rendering` with *small* `i`, but mine spellchecker makes me nut. На 17 вересня 2019 р. в 19:59:22, Genes Lists via arch-general (arch-general@archlinux.org) написав:
On 9/17/19 12:48 PM, Yurii Kolesnykov wrote:
Hello Lukas,
Firstly, could you provide output of the following command (requires mesa-demos):
`glxinfo|grep Rendering`
Or possibly
glxinfo|grep rendering
I had an issue like this with KDE having huge lag problems. I checked htop and determined it was caused by applications dropping into uninterruptible sleep due to I/o wait. That in turn was caused by baloo file indexer running rampant in my huge music collection. Not sure if yours would be the same problem, but you could check htop and see if there applications that are lagging are in state D .. that would mean something is using the hard drive and they have to wait. (My apologies for top posting, on mobile) On Tue, Sep 17, 2019, 1:02 PM Yurii Kolesnykov <root@yurikoles.com> wrote:
Correct command is `glxinfo|grep -I rendering` with *small* `i`, but mine spellchecker makes me nut.
На 17 вересня 2019 р. в 19:59:22, Genes Lists via arch-general ( arch-general@archlinux.org) написав:
On 9/17/19 12:48 PM, Yurii Kolesnykov wrote:
Hello Lukas,
Firstly, could you provide output of the following command (requires mesa-demos):
`glxinfo|grep Rendering`
Or possibly
glxinfo|grep rendering
Hello Lukas,
Firstly, could you provide output of the following command (requires mesa-demos): `glxinfo|grep Rendering`
$ glxinfo|grep -i rendering
I had an issue like this with KDE having huge lag problems. I checked htop and determined it was caused by applications dropping into uninterruptible sleep due to I/o wait. That in turn was caused by baloo file indexer running rampant in my huge music collection. Baloo is disabled, I already noticed the high CPU usage right after installing KDE. Furthermore, the issue appeared before installing KDE. Not sure if yours would be the same problem, but you could check htop and see if there applications that are lagging are in state D .. that would mean something is using the hard drive and they have to wait. Just ran htop to make sure, and no applications are in "D" state when something is lagging, only "R" and "S". I already checked before that the hard drive isn't the culprit (using iotop and dstat), as well as RAM (no more than 10% used). (My apologies for top posting, on mobile) No troubles, thanks for taking your time :) direct rendering: Yes
glxinfo furthermore says: Extended renderer info (GLX_MESA_query_renderer): Vendor: Intel Open Source Technology Center (0x8086) Device: Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2) (0x1916) Version: 19.1.7 Accelerated: yes Video memory: 3072MB Unified memory: yes Preferred profile: core (0x1) Max core profile version: 4.5 Max compat profile version: 3.0 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2 So indeed the HD 520 seems to be doing all the work, with the NVIDIA Quadro idling around.
On Thursday, 19 September 2019 11:37:34 CEST LuKaRo wrote:
[...]
glxinfo furthermore says:
Extended renderer info (GLX_MESA_query_renderer): Vendor: Intel Open Source Technology Center (0x8086) Device: Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2) (0x1916) Version: 19.1.7 Accelerated: yes Video memory: 3072MB Unified memory: yes Preferred profile: core (0x1) Max core profile version: 4.5 Max compat profile version: 3.0 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2
So indeed the HD 520 seems to be doing all the work, with the NVIDIA Quadro idling around.
At least NVIDIA graphics cards can go bad in that they can cause temporary hangs, accompanied by log messages, indicating that the GPU is damaged. So perhaps if you were to stress-test the graphics card, or if you were to use the other card instead, you might be able to see some interesting results.
On 19 September 2019 17:29:05 CEST, hw <hw@adminart.net> wrote:
At least NVIDIA graphics cards can go bad in that they can cause temporary hangs, accompanied by log messages, indicating that the GPU is damaged.
Where would I find such logs? I couldn't find anything in dmesg so far.
So perhaps if you were to stress-test the graphics card, or if you were to use the other card instead, you might be able to see some interesting results.
What kind of stress test comes to your mind?
On Thursday, September 19, 2019 6:23:29 PM CEST L. Rose wrote:
On 19 September 2019 17:29:05 CEST, hw <hw@adminart.net> wrote:
At least NVIDIA graphics cards can go bad in that they can cause temporary hangs, accompanied by log messages, indicating that the GPU is damaged.
Where would I find such logs? I couldn't find anything in dmesg so far.
They were showing in /var/log/messages. I'll never understand why the invaluable feature of logging all kinds of messages was removed ... If you don't see any, it doesn't mean anything because unless do see them, you don't know. For all I know, all the software may have changed since and the message could have been removed. If there is an error message, you'd know.
So perhaps if you were to stress-test the graphics card, or if you were to use the other card instead, you might be able to see some interesting results.
What kind of stress test comes to your mind?
It had been noticeable when running an OpenGL program in that the program would freeze up for a second or two and then kept going as if nothing was wrong until it froze up again. I guess you could run a few games: The more it puts the GPU to work, the better, and there may be particular features of the graphics card that might trigger the problem while others don't. I don't know if there is a particular stress test available.
On Sun, 22 Sep 2019 19:09:32 +0200, hw wrote:
On Thursday, September 19, 2019 6:23:29 PM CEST L. Rose wrote:
What kind of stress test comes to your mind?
It had been noticeable when running an OpenGL program in that the program would freeze up for a second or two and then kept going as if nothing was wrong until it froze up again. I guess you could run a few games: The more it puts the GPU to work, the better, and there may be particular features of the graphics card that might trigger the problem while others don't. I don't know if there is a particular stress test available.
Hi, I never used it myself, but perhaps it's helpful: https://wiki.archlinux.org/index.php/Benchmarking#GpuTest Regards, Ralf -- pacman -Q linux{,-rt{-pussytoes,,-cornflower,-securityink}}|cut -d\ -f2 5.3.arch1-1 5.2.14_rt7-0 5.2.10_rt5-1 5.2_rt1-0 4.19.72_rt25-0
On Sun, 22 Sep 2019 19:32:37 +0200, Ralf Mardorf wrote:
On Sun, 22 Sep 2019 19:09:32 +0200, hw wrote:
On Thursday, September 19, 2019 6:23:29 PM CEST L. Rose wrote:
What kind of stress test comes to your mind?
It had been noticeable when running an OpenGL program in that the program would freeze up for a second or two and then kept going as if nothing was wrong until it froze up again. I guess you could run a few games: The more it puts the GPU to work, the better, and there may be particular features of the graphics card that might trigger the problem while others don't. I don't know if there is a particular stress test available.
I never used it myself, but perhaps it's helpful: https://wiki.archlinux.org/index.php/Benchmarking#GpuTest
After building gputest I run 'gputest_gui.py'. Here some tests don't run at all. However, at 1920x1080 'Julia FP32' runs nearly fluently, with a little bit of stutter, but 'Voloplosion' is completely stuttering, no flow at all and even the mouse cursor is sluggish. IOW a short 'freeze' (stuttering) not necessarily indicates a broken GPU. My GPU is probably just not powerful. $ hwinfo --memory|grep Size;hwinfo --cpu|grep Model|sort -u;hwinfo --gfxcard|grep Driver\ S;gputest_gui.py Memory Size: 7 GB + 512 MB Model: 6.60.3 "Intel(R) Celeron(R) CPU G1840 @ 2.80GHz" Driver Status: i915 is active Geeks3D GpuTest - GPU monitoring Num GPU(s): 1 - GPU0: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
FWIW when running a stress test boot options might affect performance. For my current session i915 has got low priority. It might be of worth to care about this or similar pitfalls. $ grep Threadirqs /boot/syslinux/syslinux.cfg -A5 | head -5 LABEL Threadirqs MENU LABEL Arch Linux ^threadirqs LINUX ../vmlinuz-linux APPEND root=LABEL=s3.archlinux ro threadirqs INITRD ../intel-ucode.img,../initramfs-linux.img $ uname -rm 5.3.0-arch1-1-ARCH x86_64 $ rtirq status PID CLS RTPRIO NI PRI %CPU STAT COMMAND 202 FF 90 - 130 0.0 S irq/16-ehci_hcd 205 FF 90 - 130 0.1 S irq/28-xhci_hcd 208 FF 89 - 129 0.0 S irq/23-ehci_hcd 393 FF 85 - 125 0.0 S irq/16-snd_hdsp 422 FF 80 - 120 0.0 S irq/16-snd_ice1 124 FF 50 - 90 0.0 S irq/9-acpi 138 FF 50 - 90 0.0 S irq/8-rtc0 201 FF 50 - 90 0.0 S irq/1-i8042 209 FF 50 - 90 0.0 S irq/29-ahci[000 319 FF 50 - 90 0.0 S irq/5-parport0 355 FF 50 - 90 0.0 S irq/30-mei_me 406 FF 50 - 90 0.0 S irq/18-i801_smb 452 FF 50 - 90 0.0 S irq/32-i915 ^^^^^^^^^^ ^^^^ 471 FF 50 - 90 0.0 S irq/33-snd_hda_ 578 FF 50 - 90 0.0 S irq/31-enp3s0 9 TS - 0 19 0.0 S ksoftirqd/0 21 TS - 0 19 0.0 S ksoftirqd/1
participants (7)
-
Genes Lists
-
hw
-
L. Rose
-
LuKaRo
-
Matthew Sexton
-
Ralf Mardorf
-
Yurii Kolesnykov