[Solved] All Qt apps are very slow to start

zeroxoneafour · 2023-03-26 04:51:41

Every Qt app on my system takes 2-3 seconds to start, or longer if it is a larger app. This includes display managers (sddm), konsole, kate, systemsettings, qt-designer, kwin/plasma, and all other Qt apps. Apps take less time to start when they are cached (in ram I guess), but this benefit lasts for less than a minute. These cached apps start almost instantly all the time.

An excerpt from a strace log of konsole that I took when this happened (strace was run with -tt for more precision in the timings)

23:30:22.785817 ioctl(14, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0xd6, 0x8), 0x7ffc3b0f1bd0) = 0
23:30:22.785829 ioctl(14, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0xc8, 0x900), 0x7f53944a4a60) = 0
23:30:22.785841 ioctl(14, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0x2b, 0x20), 0x7ffc3b0f1ca0) = 0              <- This single function or the one below it took 1.5 seconds
23:30:23.958116 ioctl(14, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0x2a, 0x20), 0x7ffc3b0f1260) = 0
23:30:23.959107 openat(AT_FDCWD, "/home/vaughanm/.nv/nvidia-application-profile-globals-rc", O_RDONLY) = -1 ENOENT (No such file or directory)
23:30:23.959158 openat(AT_FDCWD, "/home/vaughanm/.nv/nvidia-application-profiles-rc", O_RDONLY) = -1 ENOENT (No such file or directory)
23:30:23.959176 openat(AT_FDCWD, "/home/vaughanm/.nv/nvidia-application-profiles-rc.d", O_RDONLY) = -1 ENOENT (No such file or directory)

As is evident, some IO action causes a massive hang before the app starts. I know that this output is not exactly helpful or meaningful, but it's all I have.

I have an SSD with over 1gbps of rw, linux-zen, and the latest updates (so kernel entropy is high). sddm-greeter especially takes over 5 seconds to start. I have had this issue with sddm-greeter for a very long time but it seems like it has spread(?) to the other apps.

Non-Qt apps such as firefox, heroic, and even spotify start immediately (<1 second) every time I execute them.

Last edited by zeroxoneafour (2023-03-26 15:39:52)

seth · 2023-03-26 06:25:26

I know that this output is not exactly helpful or meaningful, but it's all I have.

Why don't you have the rest of the strace?
Knowing what fd 14 is might help you to understand the cause of the problem.

zeroxoneafour · 2023-03-26 07:19:35

I... did not think that far ahead.

Found that fd 14 points to /dev/nvidiactl and from there I found some posts from other sites on how to fix the issue.

Thank you!

zeroxoneafour · 2023-03-26 07:37:06

Further analysis has led to the conclusion that this is actually intended behavior, and that the reason for the delay is because the fine-grained runtime D3 status that automatically suspends the GPU when not being fully used is now actually functional with the 530 driver update. This leads to a short delay when launching applications on the nvidia gpu. For some reason unbeknownst to me, all Qt apps read the status of the nvidia gpu when started (even when started on an igpu), causing the delay when the gpu starts up.

Having an application run on the nvidia card stops the delay entirely but defeats the point. At that point you should probably just disable runtime d3.

sddm-greeter is still slow all the time and honestly I don't think theres anything I can do about that.

seth · 2023-03-26 10:06:29

all Qt apps

strace qarma --error foo 2>&1 | grep nvidiactl
strace sqriptor --error foo 2>&1 | grep nvidiactl
strace qt5ct --error foo 2>&1 | grep nvidiactl

No they don't?
Not even "all qt6" clients I tried, but eg. "qml6" does, might be related to that?
Ftr, everything you listed, but qt-designer, is actually some KDE stuff and qt-designer will also load soem KDE/plasma plugins.

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

I guess it's QML related?

nikrtyd · 2023-10-19 18:11:47

zeroxoneafour wrote:

Further analysis has led to the conclusion that this is actually intended behavior

You're absolutely correct, however this likely isn't something that NVIDIA can set themselves, and seems just a hardware limitation.

As you know, modern discrete GPUs can get pretty power-hungry, so in modern systems (especially laptops) they are often suspended to save your battery.
When they are suspended, they require some time to unsuspend (about 1.5s).

As you can see in a sample strace output running konsole, the hang is caused by some syscall waking up the NVIDIA GPU.

19:01:42.374675 (+     0.000032) openat(AT_FDCWD, "/dev/nvidiactl", O_RDWR) = 14                                <-- set file descriptor 14 @ /dev/nvidiactl
19:01:42.374708 (+     0.000032) fcntl(14, F_SETFD, FD_CLOEXEC) = 0
19:01:42.374734 (+     0.000025) ioctl(14, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0xd2, 0x48), 0x7ffdf0a748c0) = 0
19:01:42.374763 (+     0.000029) openat(AT_FDCWD, "/sys/devices/system/memory/block_size_bytes", O_RDONLY) = 15
19:01:42.374793 (+     0.000029) read(15, "8000000\n", 99) = 8
19:01:42.374818 (+     0.000025) close(15) = 0
19:01:42.374844 (+     0.000025) ioctl(14, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0xd6, 0x8), 0x7ffdf0a749d0) = 0
19:01:42.374869 (+     0.000024) ioctl(14, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0xc8, 0x900), 0x7f434a2a5a80) = 0
19:01:42.374893 (+     0.000024) stat("/proc/driver/nvidia/gpus/0000:01:00.0/numa_status", 0x7ffdf0a749d0) = -1 ENOENT (No such file or directory)
19:01:42.374924 (+     0.000031) ioctl(14, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0x2b, 0x20), 0x7ffdf0a74bb0) = 0
19:01:43.934439 (+     1.559539) ioctl(14, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0x2a, 0x20), 0x7ffdf0a74170) = 0    <-- low level NVIDIA syscall, wakes the GPU up

It kind of looks like this hang happens on my setup in every app (GTK, Qt) that uses hardware acceleration, with no relation to a graphical framework.

Here's two ways how we can mitigate that:

1. We can enable nvidia-persistenced to make dGPU always on and ready to operate.

Works great for desktop systems, but not so much for laptops, where such configurations are mainly used.
In this case the system emits more heat and consumes more energy, leaving you with drained battery way quicker.

2. We can impose using default Mesa's iGPU driver and its libraries for all new apps, setting these variables in /etc/environment:

MESA_LOADER_DRIVER_OVERRIDE=radeonsi # for AMD iGPUs
# or 
MESA_LOADER_DRIVER_OVERRIDE=iris # for recent Intel iGPUs (Broadwell+)
# or 
MESA_LOADER_DRIVER_OVERRIDE=i965 # for older Intel iGPUs

__EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json

Setting an appropriate driver and libraries seems to help reduce application startup times and increase general desktop responsiveness.
GPU-intensive apps may require additional in-app configuration, but usually they have no problem recognizing and using a discrete graphics card.

Sources:
https://github.com/kovidgoyal/kitty/blo … nux-system

Arch Linux

#1 2023-03-26 04:51:41

[Solved] All Qt apps are very slow to start

#2 2023-03-26 06:25:26

Re: [Solved] All Qt apps are very slow to start

#3 2023-03-26 07:19:35

Re: [Solved] All Qt apps are very slow to start

#4 2023-03-26 07:37:06

Re: [Solved] All Qt apps are very slow to start

#5 2023-03-26 10:06:29

Re: [Solved] All Qt apps are very slow to start

#6 2023-10-19 18:11:47

Re: [Solved] All Qt apps are very slow to start

Board footer