When locking the screen the kscreenlocker_greet process constantly consumes around 20% CPU time. The exact amount depends on the CPU, of course. The X process is active, too. I have tested the behaviour on 2 PCs. Reproducible: Always Steps to Reproduce: 1. Lock the screen Actual Results: around 20% CPU consumation. Expected Results: No CPU consumption while no input comes. Interesting is, that the CPU consummation drops to nothing after switching to a text vt. Even more interesting is the fact, that after switching back to X11 the CPU consummation stays low.
Does this still happen? If so, you might be able to get some insight into what's happening with sysprof - http://sysprof.com/
I have this problem also on Archlinux with KDE 4.10.2. 'top' shows me PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19892 <omit> 20 0 2697368 43344 2796 R 29.87 1.072 294:38.59 kscreenlocker_g
This still happens. ATM it might even be worse, as my laptop now consumes 43 % CPU time. I will try to find the time for profiling, soon.
I will need to do a cleaner profiling session than I am able to do right now, which I should upload then, I assume. Right now it looks like 7% (of 35% overall ATM) are spent in convert_ARGB_PM_to_ARGB(…) and another 6% are spent in blend_transformed_tiled_argb…. although the system just shows a simple screen lock without me doing any input.
Created attachment 79410 [details] Short run of sysprof on the kscreenlocker_greet pid A quite huge 2h 20 min run on the whole system showed almost the same behaviour. Please take this bug seriously, as it may only be detected by logging into your system via ssh. As soon as you open another terminal, the CPU load of kscreenlocker_greet is down to zero!
Sorry, I didn't realize that sysprof still has trouble with reliable frame pointers on 64-bit. There's no information on who calls convert_ARGB_PM_to_ARGB etc. - I assume you have all relevant debuginfo packages for kde-workspace, but I don't think that would be the problem anyway. I'm not sure which profilers have proper unwinding support - I think systemtap does or there's running under valgrind/callgrind - http://valgrind.org/docs/manual/cl-manual.html - which should be reliable but will be extremely slow. Actually, I think I'm overthinking things - just sample the backtrace with pstack (it comes with gdb). Do it from ssh or from the desktop like "sleep 60; pstack `pidof kscreenlocker_greet`" so that it happens after you lock. Do it a few times and you have a very rudimentary profile.
I have same problem on Kubuntu 12.10 and 13.04 32 bit. KDE from 4.10.0 till current version (4.10.2). High CPU load in simple and screensaver mode. But widgets mode works fine. > Interesting is, that the CPU consummation drops to nothing after switching to a text vt. Even more interesting is the fact, that after switching back to X11 the CPU consummation stays low. I found out that it loads CPU only when the password input field is in focus.
Created attachment 79591 [details] Screenshot htop
*** This bug has been confirmed by popular vote. ***
Created attachment 79623 [details] callgrind output on kscreenlocker_greet
I did some---more or less random---poking on the locker's qml files. It looks like the Text-Field-Focus-Forcing is leading to all the repaints. If I comment out the lines 108 and 109 of Greeter.qml (the onTriggered-Action of the focusTimer), the CPU usage drops to reasonable values. If I instead set the timers interval to 10000, the CPU usage stays reasonable for 10 seconds, then jumps up. As long as CPU usage is low, the text field is not focussed. This is the inversion of comment 7. :-) So I guess everybody who is not using the widget mode is hit by this bug. Any Ideas on how to fix the force-focus-issue?
Thank you Jan, this worked for me. What I did is comment out the entire Timer{} block (lines 103-111) and also the function resetFocus() (lines 41-43, because it references the Timer). Everything works normally, but the CPU now stays idle until I click the text field. When I start typing, there is considerable lag between each keystroke and the corresponding dot appearing in the text field, and the CPU is fully loaded. So the real question remains: why would rendering such a simple dialog take so much computation? (In reply to comment #11) > I did some---more or less random---poking on the locker's qml files. It > looks like the Text-Field-Focus-Forcing is leading to all the repaints. > > If I comment out the lines 108 and 109 of Greeter.qml (the > onTriggered-Action of the focusTimer), the CPU usage drops to reasonable > values. > > If I instead set the timers interval to 10000, the CPU usage stays > reasonable for 10 seconds, then jumps up. > > As long as CPU usage is low, the text field is not focussed. This is the > inversion of comment 7. :-) > > So I guess everybody who is not using the widget mode is hit by this bug. > Any Ideas on how to fix the force-focus-issue?
For comparison: The password dialog of plasma-overlay is not using 30 % + of my cpu cycles.
Confirmed for 4.12.4 (Gentoo)
How hard it can be to fix this problem? The solution is obvious. Do not force focus 100 times per second.
Confirmed on kde5 on ubuntu 14.10
Are you sure this still happens on 5? The Breeze look and feel package uses a completely rewritten lockscreen theme which only has a forceActiveFocus Timer that fires once. I also don't see any Timers in the fallback implementation (which is the one used in 4.x)
Created attachment 90202 [details] kscreenlocker_greet htop screenshot
I'm not able to reproduce with Plasma 5.2. In case you are still experiencing this problem with our latest release, please reopen.
Created attachment 93791 [details] htop kde 5 on fedora 22 (kscreen-5.3.2-1.fc22.x86_64)
Confirmed with plasma5-workspace 5.4.2 (OpenSUSE Leap 42.1). Switching to text console (Ctrl+Alt+F1) does not help (workaround mentioned in initial report).
Also seen with plasma5-workspace-5.4.3-1.1.x86_64.
I just locked the desktop, switched to another vt, run top and I couldn't even find kscreenlocker_greet in the list. Those experiencing the problem need to help us: please gdb into the process and get a backtrace, so that we can see where it consumes the CPU.
(In reply to Martin Gräßlin from comment #23) > I just locked the desktop, switched to another vt, run top and I couldn't > even find kscreenlocker_greet in the list. I suggest you not to debug locally then. Also, could someone reopen this please?
(In reply to Martin Gräßlin from comment #23) > > Those experiencing the problem need to help us: please gdb into the process > and get a backtrace, so that we can see where it consumes the CPU. This id a gdb bt on kubuntu 15.10 (kernel 4.5) and plasma 4:5.5.4-0ubuntu1~ubuntu15.10~ppa1 #0 0x00007f8689b5e88d in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f86830ee1ec in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007f86830ee2fc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007f868a48c4ef in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x00007f868a43350a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x00007f868a43b5ec in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x000000000040ae87 in main ()
On OpenSUSE Leap 42.1 (steps: find pid, e.g. from "top", run gdb -p pid and enter "backtrace" on the "(gdb)" prompt) #0 0x00007fa9073eebbd in poll () at /lib64/libc.so.6 #1 0x00007fa90446de64 in () at /usr/lib64/libglib-2.0.so.0 #2 0x00007fa90446df7c in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0 #3 0x00007fa907f30d6c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5 #4 0x00007fa907ed7d53 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5 #5 0x00007fa907edf8f6 in QCoreApplication::exec() () at /usr/lib64/libQt5Core.so.5 #6 0x0000000000415a41 in main ()
Thanks for the backtraces. Both show the main thread in the event loop. Which means we don't see anything. Could you please get all thread traces. Use "t a a bt" for that.
Thanks for providing the command. Note to others: "help t", "help t a", etc. on the gdb prompt tells you what it does. (gdb) help t a a Apply a command to all threads. (gdb) t a a bt Thread 7 (Thread 0x7fa8fd3b0700 (LWP 3556)): #0 0x00007fa9073eebbd in poll () at /lib64/libc.so.6 #1 0x00007fa909e11422 in () at /usr/lib64/libxcb.so.1 #2 0x00007fa909e1300f in xcb_wait_for_event () at /usr/lib64/libxcb.so.1 #3 0x00007fa8ffbb43c9 in () at /usr/lib64/libQt5XcbQpa.so.5 #4 0x00007fa907cfe32f in () at /usr/lib64/libQt5Core.so.5 #5 0x00007fa9062cd0a4 in start_thread () at /lib64/libpthread.so.0 #6 0x00007fa9073f6fed in clone () at /lib64/libc.so.6 Thread 6 (Thread 0x7fa8f0973700 (LWP 3557)): #0 0x00007fa8dcd434e6 in () #1 0x0000000000000000 in () Thread 5 (Thread 0x7fa8f0172700 (LWP 3558)): #0 0x00007fa8dcd41354 in () #1 0x3f4ccccd3f4ccccd in () #2 0x3f4ccccd3f4ccccd in () #3 0x3f8000003f800000 in () #4 0x3f8000003f800000 in () #5 0x0000000000000000 in () Thread 4 (Thread 0x7fa8ef971700 (LWP 3559)): #0 0x00007fa9062d1cdc in pthread_barrier_wait () at /lib64/libpthread.so.0 #1 0x00007fa8f73a4a68 in () at /usr/lib64/dri/swrast_dri.so #2 0x00007fa8f73a45a7 in () at /usr/lib64/dri/swrast_dri.so #3 0x00007fa9062cd0a4 in start_thread () at /lib64/libpthread.so.0 #4 0x00007fa9073f6fed in clone () at /lib64/libc.so.6 Thread 3 (Thread 0x7fa8ef170700 (LWP 3560)): #0 0x00007fa9062d1cdc in pthread_barrier_wait () at /lib64/libpthread.so.0 #1 0x00007fa8f73a4a68 in () at /usr/lib64/dri/swrast_dri.so #2 0x00007fa8f73a45a7 in () at /usr/lib64/dri/swrast_dri.so #3 0x00007fa9062cd0a4 in start_thread () at /lib64/libpthread.so.0 #4 0x00007fa9073f6fed in clone () at /lib64/libc.so.6 Thread 2 (Thread 0x7fa8ee737700 (LWP 3561)): #0 0x00007fa9073eebbd in poll () at /lib64/libc.so.6 #1 0x00007fa90446de64 in () at /usr/lib64/libglib-2.0.so.0 #2 0x00007fa90446df7c in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0 #3 0x00007fa907f30d6c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5 #4 0x00007fa907ed7d53 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5 #5 0x00007fa907cf961a in QThread::exec() () at /usr/lib64/libQt5Core.so.5 #6 0x00007fa909090df8 in () at /usr/lib64/libQt5Qml.so.5 #7 0x00007fa907cfe32f in () at /usr/lib64/libQt5Core.so.5 #8 0x00007fa9062cd0a4 in start_thread () at /lib64/libpthread.so.0 #9 0x00007fa9073f6fed in clone () at /lib64/libc.so.6 Thread 1 (Thread 0x7fa90a2047c0 (LWP 3555)): #0 0x00007fa9062d103f in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0 #1 0x00007fa8f73a4e4b in () at /usr/lib64/dri/swrast_dri.so #2 0x00007fa8f73b1d73 in () at /usr/lib64/dri/swrast_dri.so #3 0x00007fa8f73b27f3 in () at /usr/lib64/dri/swrast_dri.so #4 0x00007fa8f6f92ec4 in () at /usr/lib64/dri/swrast_dri.so #5 0x00007fa905361517 in () at /usr/lib64/libGL.so.1 #6 0x00007fa8fc59329a in () at /usr/lib64/qt5/plugins/xcbglintegrations/libqxcb-glx-integration.so #7 0x00007fa908469df2 in QOpenGLContext::swapBuffers(QSurface*) () at /usr/lib64/libQt5Gui.so.5 #8 0x00007fa9097818fb in () at /usr/lib64/libQt5Quick.so.5 #9 0x00007fa9097826a5 in () at /usr/lib64/libQt5Quick.so.5 #10 0x0000000002066220 in () #11 0x0000000000000000 in () (gdb)
Maybe useful to see which of the above threads consumes CPU (command "top" + H for threads): PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3557 sddm 20 0 894200 130688 72500 S 1.997 5.438 338:29.66 llvmpipe-0 3560 sddm 20 0 894200 130688 72500 S 1.952 5.438 323:40.13 llvmpipe-3 3558 sddm 20 0 894200 130688 72500 S 1.861 5.438 324:36.87 llvmpipe-1 3559 sddm 20 0 894200 130688 72500 S 1.816 5.438 323:58.09 llvmpipe-2 3555 sddm 20 0 894200 130688 72500 S 0.726 5.438 128:34.67 sddm-greeter
According to the backtrace: you are using llvmpipe, which means OpenGL is emulated on the CPU. Of course that's not going to be efficient.
This is a more complete bt Thread 9 (Thread 0x7f8678664700 (LWP 21290)): #0 0x00007f8689b5e88d in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f868984bbd2 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #2 0x00007f868984d74f in xcb_wait_for_event () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #3 0x00007f867a38a779 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 #4 0x00007f868a254a6e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x00007f868520a6aa in start_thread (arg=0x7f8678664700) at pthread_create.c:333 #6 0x00007f8689b69e9d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 8 (Thread 0x7f8676ff5700 (LWP 21291)): #0 0x00007f8689b5e88d in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f86830ee1ec in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007f86830ee2fc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007f868a48c4ef in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x00007f868a43350a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x00007f868a24fac4 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x00007f868a254a6e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x00007f868520a6aa in start_thread (arg=0x7f8676ff5700) at pthread_create.c:333 #8 0x00007f8689b69e9d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 7 (Thread 0x7f8674d11700 (LWP 21292)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007f86761babf3 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #2 0x00007f86761baa57 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #3 0x00007f868520a6aa in start_thread (arg=0x7f8674d11700) at pthread_create.c:333 #4 0x00007f8689b69e9d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 6 (Thread 0x7f866dc0e700 (LWP 21293)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007f86761babf3 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #2 0x00007f86761baa57 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #3 0x00007f868520a6aa in start_thread (arg=0x7f866dc0e700) at pthread_create.c:333 #4 0x00007f8689b69e9d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 5 (Thread 0x7f866d40d700 (LWP 21294)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007f86761babf3 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #2 0x00007f86761baa57 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #3 0x00007f868520a6aa in start_thread (arg=0x7f866d40d700) at pthread_create.c:333 #4 0x00007f8689b69e9d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 4 (Thread 0x7f866cc0c700 (LWP 21295)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007f86761babf3 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #2 0x00007f86761baa57 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so ---Type <return> to continue, or q <return> to quit--- #3 0x00007f868520a6aa in start_thread (arg=0x7f866cc0c700) at pthread_create.c:333 #4 0x00007f8689b69e9d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 3 (Thread 0x7f8667fff700 (LWP 21296)): #0 0x00007f8689b5e88d in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f86830ee1ec in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007f86830ee2fc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007f868a48c4ef in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x00007f868a43350a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x00007f868a24fac4 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x00007f868ba0ec35 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #7 0x00007f868a254a6e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #8 0x00007f868520a6aa in start_thread (arg=0x7f8667fff700) at pthread_create.c:333 #9 0x00007f8689b69e9d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 2 (Thread 0x7f865ffff700 (LWP 21299)): #0 0x00007f8689b5e88d in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f86830ee1ec in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007f86830ee2fc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007f868a48c50b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x00007f868a43350a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x00007f868a24fac4 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x00007f868bc5c2a6 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5 #7 0x00007f868a254a6e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #8 0x00007f868520a6aa in start_thread (arg=0x7f865ffff700) at pthread_create.c:333 #9 0x00007f8689b69e9d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 1 (Thread 0x7f867a862840 (LWP 21289)): #0 0x00007f8689b5e88d in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f86830ee1ec in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007f86830ee2fc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007f868a48c4ef in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x00007f868a43350a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x00007f868a43b5ec in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x000000000040ae87 in main ()
(In reply to Martin Gräßlin from comment #30) > According to the backtrace: you are using llvmpipe, which means OpenGL is > emulated on the CPU. Of course that's not going to be efficient. This is a default install of OpenSUSE 42.1 in a VM. Hardware graphics acceleration is not an option. I've a few VMs and I'd like keep runlevel 5 as it's handy to have a graphical login on occasions. On a machine with hardware graphics acceleration, if the screen is re-drawn as soon as the previous drawing is finished, this will still be a huge waste of power on the GPU (not visible in the CPU usage stats of "top"). A simple way to check this (without a power meter) may be to check how often per second the screen is re-drawn. Ideas for workarounds (in no particular order): (0) I tried setting screen energy saving to 2 minutes in KDE system settings and locking the screen (rather than logging out) hoping that re-drawing would stop after 2 minutes. No success. (1) Send SIGSTOP/SIGCONT as needed (seems to work but have to remember why the login screen is frozen) (2) Pick brains of cgroups expert how to apply cpu.cfs_period_us and cpu.cfs_quota_us to this situation (3) Check source code and add sleep(0.02) in the re-drawing loop (4) Lower the blinking frequency of the cursor (if this is what causes the re-drawing) (5) Learn how to configure a non-KDE login screen in OpenSUSE that can still start KDE (6) Find out whether kscreenlocker can show a simple framebuffer-based login screen To the gdb experts here: Can I easily find out how often the screen is re-drawn and how, for example by obtaining a list of functions and how often they have been called in the last second or since the last query? Any suggestions?
> This is a default install of OpenSUSE 42.1 in a VM. Hardware graphics acceleration is not an option Hardware graphics acceleration in VM is nowadays an option. VMware, VBox, KVM all support hardware acceleration.
(In reply to Martin Gräßlin from comment #30) > According to the backtrace: you are using llvmpipe, which means OpenGL is > emulated on the CPU. Of course that's not going to be efficient. But, what if that's all you've got to work with? Please take this bug more seriously, it's a bit ridiculous that the reason the "downgrade" to the latest release of Kubuntu is a disaster on my hardware is because the screen locker requires graphics acceleration in order to flash the cursor without pegging the CPU at 100%. Whatever its doing that causes such dire performance must surely also be broken for remote sessions? Something about blinking the cursor is really badly implemented and dismissing it as the hardware being too underpowered to blink a cursor is, well, quite poor form?
(In reply to david.sainty from comment #34) > (In reply to Martin Gräßlin from comment #30) > > According to the backtrace: you are using llvmpipe, which means OpenGL is > > emulated on the CPU. Of course that's not going to be efficient. > > But, what if that's all you've got to work with? I'm sorry that you have a bad experience with it. If you are using llvmpipe this mostly means that either you don't have a GPU driver installed or that your installed driver is broken. Both are setup issues. Any (desktop) hardware released during the last 15 years does have drivers which do not require llvmpipe. On such old hardware an up to date Plasma 5 would not work anyway. Thus let's concentrate on the actual problem: you want to have proper drivers installed. We shouldn't invest a huge amount of work in our software to workaround broken drivers or setup issues. > Whatever its doing that causes such dire performance must surely also be broken for remote sessions? Remote sessions have been broken since toolkits started to render everything on client side and use either OpenGL or shared-memory to provide the next frame to the X server. In case of Qt that's since 2007 (so almost a decade). I know that this is important to some users, but we should face the truth: remote X has been broken with todays toolkits for about a decade. Moving to OpenGL doesn't make anything worse in that regard. Remote glx btw. has been broken since the introduction of shaders (OpenGL 2/1.4+extension) - the spec is stuck at OpenGL 1.3 and glx has been disabled by default nowadays due to security issues. Again this has been broken for more than a decade (OpenGL 1.4 got released in 2002). Please let's not bring up remote X in any discussion about modern rendering. It's broken. Please use technologies like VNC or rdp which can support this properly.
@david.sainty I have felt your pain, even with desktops effects working properly on opengl 3.1, kscreenlocker was eating my cpu ALL the time. I upgraded to the latest KDE Neon User Edition - problem is gone .. drastic measure, but works
(In reply to Martin Gräßlin from comment #35) > I'm sorry that you have a bad experience with it. If you are using llvmpipe > this mostly means that either you don't have a GPU driver installed or that > your installed driver is broken. Both are setup issues. Any (desktop) > hardware released during the last 15 years does have drivers which do not > require llvmpipe. That's the reality with GMA500 Intel graphics. You might still be correct, because it's a laptop not a desktop. But I don't quite imagine why you'd make that caveat? It's slow graphics. But usable. Kubuntu 14.04 was acceptable performance though. Kubuntu 15 is awful, because it takes many seconds to get though the lock screen. Actually, once logged in, performance seems acceptable. > Please let's not bring up remote X in any discussion about modern rendering. > It's broken. I'm not sure how to take the idea of modern, yet broken rendering. Nor do I want to discuss it - I'm just a user experiencing awful regression in performance. But even if you feel that KDE should be considered incompatible with remote X or sub-par graphics, surely all of this is an indication that there's something worth fixing. Just because people don't notice the slowdown on high spec desktops doesn't mean that it isn't eating up a whole heap of unnecessary watts and affecting their battery life and/or power bill every time they go to the lock screen.
(In reply to Matias Barletta from comment #36) > @david.sainty > > I have felt your pain, even with desktops effects working properly on opengl > 3.1, kscreenlocker was eating my cpu ALL the time. > > I upgraded to the latest KDE Neon User Edition - problem is gone .. drastic > measure, but works Hmmm... Perhaps it has actually been fixed in the code?
> That's the reality with GMA500 Intel graphics. You might still be correct, because it's a laptop not a desktop. But I don't quite imagine why you'd make that caveat? The caveat was not meant for laptop but for smartphones and embedded devices like raspberrypi, odroid, etc. > It's slow graphics. But usable. Kubuntu 14.04 was acceptable performance though. Kubuntu 15 is awful, because it takes many seconds to get though the lock screen. Actually, once logged in, performance seems acceptable. I'm sorry that you have such a bad experience with it. Please try again with Plasma 5.8 - there is a new design and maybe that is better suited for your GPU. > Just because people don't notice the slowdown on high spec desktops doesn't mean that it isn't eating up a whole heap of unnecessary watts and affecting their battery life and/or power bill every time they go to the lock screen. Sorry, but you are jumping to the wrong conclusions here. If you have a GPU, rendering is cheap. That's why one has a GPU and does not do everything on the CPU. The problem here is that your GPU is not well supported and gets emulated on the CPU (sorry Poulsbo was never really supported on Linux and is the odd one. Although being from Intel it doesn't share anything with normal Intel hardware and according to Arch wiki doesn't support OpenGL https://wiki.archlinux.org/index.php/Intel_GMA_500). That is unfortunate for you but doesn't allow to say anything in general as it works just fine if you have a supported GPU. I'm sorry to say but with that hardware you will not have fun with any modern desktop. Be it Plasma, GNOME, Unity, Cinnamon, E18, Elementary, etc. etc. You want a desktop which doesn't use OpenGL - which is nowadays hardly any. Consider maybe a bare openbox setup. Keep away from GTK and Qt based applications, keep away from browsers. They all need OpenGL and you don't want that emulated on the CPU. I'm sorry for you that you picked up the one device which doesn't support Linux.
I think this bug has reappeared. kscreenlocker-5.10.4-1 on Fedora 26 From top 27119 XXX 20 0 1176496 129236 86500 S 100.0 0.4 87:29.62 kscreenlocker_g I installed the debuginfo and tried to run gdb as described. As soon as gdb starts, the load on kscreenlocker drops to normal. As soon as gdb is closed, the process load goes to maximum again. I have two or three different desktop sessions open. Switch between them normally with ctrl+alt+F(X) I have tested this multiple times and each time I try to run the gdb, the load drops. As soon as I stop gdb, the load shoots up to 100% on a single core. 27119 XXXX 20 0 1176496 129236 86500 S 99.7 0.4 89:18.63 kscreenlocker_g As soon as I start gbd, the load drops for kscreensaver. 27119 XXXX 20 0 1176496 129236 86500 t 71.2 0.4 91:07.51 kscreenlocker_g If this is not reopened, I will submit a new bug. I will try to test on a different machine this weekend.
(In reply to Robin Laing from comment #40) > I think this bug has reappeared. > I'm pretty sure no effort was ever made to fix it - it was dismissed as "not a problem because modern machines are fast enough". > > If this is not reopened, I will submit a new bug. > Good luck. For me the attitude to this very bug was breaking point - I bought a MacBook :)
Whatever problem anyone expriences now, cannot be related with this bug report. The code base significantly evolved. Any new issues needs to be investigated again and thus needs a dedicated report.
Okay, I will create a new bug and keep trying to get any more information. Just wanted to confirm before opening a new bug report.
(In reply to Robin Laing from comment #43) > Okay, I will create a new bug and keep trying to get any more information. > > Just wanted to confirm before opening a new bug report. Did you open a new bug? I'm affected by this as well (libkscreenlocker5 5.10.5).
And just for the reference, it only happens when screen locker is using image slideshow. With static image CPU usage is minimal.
(In reply to Shmerl from comment #44) > (In reply to Robin Laing from comment #43) > > Okay, I will create a new bug and keep trying to get any more information. > > > > Just wanted to confirm before opening a new bug report. > > Did you open a new bug? I'm affected by this as well (libkscreenlocker5 > 5.10.5). No I didn't yet. I am waiting for it to happen again. As it stands, it hasn't happened for over a week so maybe one of the updates fixed the problem I was having.
(In reply to Shmerl from comment #45) > And just for the reference, it only happens when screen locker is using > image slideshow. With static image CPU usage is minimal. I wasn't using a slide show or anything other than the sddm login screen as default. I did have multiple sessions running though.
It's also still around 9.5% CPU usage in a VM with KVM and both guest and host using current OpenSUSE Leap 42.3 in a default setup. That's KDE 5.8.7. For sddm-greeter instead of kscreenlocker_greet, it's slightly better: 6.5%. On the host with hardware graphics, it's below 0.1%. (I'm still curious how much more power the graphics card consumes when the greeter is active compared to (a) an idle desktop and (b) text mode.) An alternative route to a partial solution may be to add a feature request to Mesa 3D's Gallium llvmpipe software rasteriser to not waste CPU while the output is not visible. Then one could save power by switching to a virtual terminal where kscreenlocker/sddm-greeter is not active. Opinions?
If slideshow is the cause, and you are using Qt 5.9.1, then it probably is a duplicate of bug 381000.
(In reply to Christoph Feck from comment #49) > If slideshow is the cause, and you are using Qt 5.9.1, then it probably is a > duplicate of bug 381000. Yep, I figured that's the reason. Using static images works around that issue.
Sorry this is still not fixed in 5.18 after all these years: ps output showing lots of CPU time clocked up: 11105 ? Sl 1104:21 /usr/lib64/libexec/kscreenlocker_greet --graceTime 5000 --ksldfd 28 Line from top showing about 20% CPU usage: 11105 me 20 0 3120948 258816 113664 S 23.26 0.789 1104:42 kscreenlo+ Platform is non-VM desktop on Ryzen x86_64 workstation. No slideshow or anything else running, just waiting for a login. One thing I noticed is that moving the mouse or clicking on the keyboard will cause the CPU usage to spike then return to normal. Switching the console to a text VT doesn't change anything.
I'm running KDE with Debian on Windows VMWare Workstation and enabling 3D acceleration works well for me.
I am also seeing this issue. I am running Kubuntu 2020.4 on a home server with a Ryzen 3600. When SSH'ed into a locked screen, I see kscreenlocker_g at about 20-30% cpu, with spikes up to 300%. kwin_x11 is also around 13% CPU. After I login, I don't see a single process above 1%.
The bug's still turning up which means the machine consumes ernergy for nothing. May by I'm a bit naive with my workaround: Simply chosing "change user" and the load drops.
Same issue on an ARM64 system (Hardkernel Odroid N2 running Debian Buster). 2 other workarounds for the issue to help solve it : - press tab to unselect the password field, but the CPU load will go up again if you select it again - kill the kscreenlocker_greet process (using ssh or vt for example) the ksm server will restart it and this time without the high CPU load It looks like SDDM has the same issue BTW.
I ended up here, because I accidentally noticed that running KDE in a vnc session consumes almost 100% CPU for me. kscreenlocker uses over 60% and kwin_x11 is at around 30%. I guess VNC is out of question with KDE at this point.....
Looks like I was a bit too pessimistic. I'm a running a VNC session for use A and that is not actually using up much CPU. However, when I physically log into the same machine as user B, then kscreenlocker_g and kwin_x11 shoot up to basically 100%. I suspect this has something to do with running two kde sessions at the same time. I don't know what happens if I have 2 VNC KDE sessions going.
I am running into the situation where kscreenlocker goes to 99% on a regular basis. I did updates on the weekend and have not seen it since. It seemed to happen more often the longer I was running between reboots as if it is a memory leak. I constantly run multiple users on this machine to isolate work from home and my personal stuff so both are logged in at the same time. There are times that I have more than three users logged into the machine at the same time. I also found that I couldn't login to the user where the process was running at 99% until I killed the kscreenlocker process. I am using Fedora 35. I am using gdm at this time. I have not had time to look into this issue either.
This is from journal logs with one process kscreenlocker_greet at 99% Apr 06 22:37:36 darkstar.tardis.localdomain kscreenlocker_greet[63511]: Qt: Session management error: networkIdsList argument is NULL Apr 06 22:37:37 darkstar.tardis.localdomain kscreenlocker_greet[63511]: file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/UserList.qml:42:9: Unable to assign [undefined] to bool Apr 06 22:37:38 darkstar.tardis.localdomain kscreenlocker_greet[63511]: file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/UserList.qml:42:9: Unable to assign [undefined] to bool This is all that appears with strace. futex(0x55586340c2d0, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY
This solved it for me on KDE neon inside Hyper-V: # Add to: /etc/security/pam_env.conf # Avoid high cpu usage with sddm-greeter # https://github.com/sddm/sddm/issues/323 QT_QUICK_BACKEND DEFAULT=software
Still see this in KVM Fedora 36 guests, independent of the choice of QXL and Virtio graphics and X11 or Wayland logon. Editing: /etc/security/pam_env.conf and adding: QT_QUICK_BACKEND DEFAULT=software is still needed
(In reply to tagwerk19 from comment #61) > Still see this in KVM Fedora 36 guests, independent of the choice of QXL and > Virtio graphics and X11 or Wayland logon. > > Editing: > /etc/security/pam_env.conf > and adding: > QT_QUICK_BACKEND DEFAULT=software > is still needed This looks like something that instructs something to do something in software rather than using hardware. How does emulating hardware functionality in software make things faster / less CPU intensive?
(In reply to Szczepan Hołyszewski from comment #62) > ... How does emulating hardware > functionality in software make things faster / less CPU intensive? ... The reference I remember was related to the "blinking text cursor" https://github.com/sddm/sddm/issues/323#issuecomment-220375807 It's a while ago now....