| Summary: | KDED/Ksmserver consume high CPU time during system idle | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Darrell <darrella> |
| Component: | other (any) | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ac586133, bugwatch, darrella, kb9vqf |
| Priority: | P5 | ||
| Version: | R14.0.0 [Trinity] | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Attachments: | kded and ksmserver debug info, on Ubuntu 13.04 with TDE R14 nightlies of May 18, 2013 | ||
|
Description
Darrell
2013-05-18 17:05:00 CDT
gdb --pid `pidof kded`:
#0 0xb5f5b738 in ___newselect_nocancel () from /lib/libc.so.6
#1 0xb64cdcb4 in TQEventLoop::processEvents (this=0x9ee4700, flags=4) at kernel/qeventloop_x11.cpp:297
#2 0xb6500920 in TQEventLoop::enterLoop (this=0x9ee4700) at kernel/qeventloop.cpp:227
#3 0xb65008a4 in TQEventLoop::exec (this=0x9ee4700) at kernel/qeventloop.cpp:174
#4 0xb64ed81c in TQApplication::exec (this=0xbff72d10) at kernel/qapplication.cpp:2949
#5 0xb5c55c77 in kdemain (argc=-514, argv=0xfffffdfe) at /dev/shm/tdelibs/kded/kded.cpp:978
#6 0xb76f37b3 in tdeinitmain (argc=2, argv=0x9efecf8) at /dev/shm/tdelibs.build/kded/kded_tdeinit_module.cpp:3
#7 0x0804f6ec in launch (argc=2, _name=0x8054b1a "kded", args=0xbff72ed4 "Hñï\tÐðí\t[\016&¶", cwd=0x0, envc=0, envs=0x0,
reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0xfffffdfe <Address 0xfffffdfe out of bounds>,
startup_id_str@entry=0x2 <Address 0x2 out of bounds>) at /dev/shm/tdelibs/tdeinit/tdeinit.cpp:673
#8 0x0804c97d in main (argc=3, argv=0xbff73204, envp=0xbff73214) at /dev/shm/tdelibs/tdeinit/tdeinit.cpp:1856
gdb --pid `pidof ksmserver`:
#0 0xb5f53738 in ___newselect_nocancel () from /lib/libc.so.6
#1 0xb64c5cb4 in TQEventLoop::processEvents (this=0x8e15568, flags=4) at kernel/qeventloop_x11.cpp:297
#2 0xb64f8920 in TQEventLoop::enterLoop (this=0x8e15568) at kernel/qeventloop.cpp:227
#3 0xb64f88a4 in TQEventLoop::exec (this=0x8e15568) at kernel/qeventloop.cpp:174
#4 0xb64e581c in TQApplication::exec (this=0xbf877108) at kernel/qapplication.cpp:2949
#5 0xb5b7ef2d in kdemain (argc=148977056, argv=0x8df8468) at /dev/shm/tdebase/ksmserver/main.cpp:247
#6 0xb76eb733 in tdeinitmain (argc=3, argv=0x8df8468) at /dev/shm/tdebase.build/ksmserver/ksmserver_tdeinit_module.cpp:3
#7 0x0804f6ec in launch (argc=3, _name=0x8debeb4 "ksmserver", args=0xbf8772a4 " \205ß\bà]Û\b0", cwd=0x8debed3 "/home/users/slacky",
envc=73, envs=0x8decf31 "", reset_env=true, tty=0x8decf31 "", avoid_loops=80,
startup_id_str=0xfffffdfe <Address 0xfffffdfe out of bounds>, startup_id_str@entry=0x3 <Address 0x3 out of bounds>)
at /dev/shm/tdelibs/tdeinit/tdeinit.cpp:673
#8 0x080507bc in handle_launcher_request (sock=<optimized out>, sock@entry=5) at /dev/shm/tdelibs/tdeinit/tdeinit.cpp:1240
#9 0x08050dd1 in handle_requests (waitForPid=waitForPid@entry=0) at /dev/shm/tdelibs/tdeinit/tdeinit.cpp:1433
#10 0x0804cc3d in main (argc=5, argv=0xbf877934, envp=0xbf87794c) at /dev/shm/tdelibs/tdeinit/tdeinit.cpp:1909
"Address ... out of bounds" looks suspicious. :-) Nothing looks out of the ordinary in the backtraces. My initial suspicion is that this is related to the switch to the glib main event loop, and if so, that it may not be (easily) fixable. (In reply to comment #2) > "Address ... out of bounds" looks suspicious. :-) Not really--in my experience, the further one goes from the active frame, the higher the chance of gdb errors (not errors in the program, just errors in obtaining valid call stack data). Created attachment 1280 [details]
kded and ksmserver debug info, on Ubuntu 13.04 with TDE R14 nightlies of May 18, 2013
I checked on my PCLinuxOS non-official TDE remaster (PCLinuxOS 2013 with TDE 3.5.13.1), and kded and ksmserver CPU use is so low that I don't even see it listed in ''top''. Thanks! -Alexandre Disabling all KDED services and restarting Trinity makes no difference.
> My initial suspicion is that this is related to the switch to the glib main event loop
That is a tad over my head. Is that related to tdehw libs?
(In reply to comment #7) > Disabling all KDED services and restarting Trinity makes no difference. > > > My initial suspicion is that this is related to the switch to the glib main event loop > > That is a tad over my head. Is that related to tdehw libs? No, it is related to how TQt3 is built. TQt3 can either use its own, internal event loop (the only option in TDE 3.5.13.x and earlier), or it can integrate with the glib main loop (default in R14 and later). This integration allows use of GTK libraries in TDE applications and provides other benefits IIRC. Falling back to the internal event loop would require extensive retesting to ensure that none of the threading modifications broke the internal event loop; this is something I do not want to do at the moment. For test purposes only, you could try recompiling/reinstalling TQt3 with the glib event loop integration configure option turned off to see if it even makes any difference... Hmm. That might be part of the problem. I was unaware of any such configuration option. I had been building tqt3 without -glibmainloop. I must have missed the memo. I rebuilt tqt3 with -glibmainloop. top now shows a slightly higher CPU time consumption at about 5% average rather than about 4%. Perhaps I need to rebuild the entire package set after rebuilding tqt3 this way? Rebuilding the core modules and tqt3 with -glibmainloop made no difference. I still see about 5% usage time with kded and ksmserver. Are there any new configuration options needed with all other modules other than tqt3 and -glibmainloop? (In reply to comment #10) > Rebuilding the core modules and tqt3 with -glibmainloop made no difference. I > still see about 5% usage time with kded and ksmserver. > > Are there any new configuration options needed with all other modules other > than tqt3 and -glibmainloop? No, and a rebuild of anything other than TQt3 is not needed when the configuration option is toggled. Since you can reproduce this bug with the glib main loop support disabled, it seems something else has changed in TDE to cause this issue. Just so that we are not accidentally overlooking something, when you build TQt3 without -glibmainloop set, can you please verify that QT_USE_GLIBMAINLOOP is not set in any of the files (e.g. any of the Makefile files) or specified as a compiler flag (e.g. -DQT_USE_GLIBMAINLOOP)? Thanks! Yes, that is the case. When I wasn't using -glibmainloop, my build logs had the following: Configuration ....... nocrosscompiler dlopen_opengl minimal-config small-config medium-config large-config full-config styles tools kernel widgets dialogs iconview workspace inputmethod network canvas table xml opengl sql opengl release dll thread largefile stl ipv6 system-mng system-jpeg jpeg system-png png no-glibmainloop gif system-zlib nis cups bigcodecs x11sm xshape xinerama xcursor xrandr xrender xftfreetype tablet xkb inputmethod STL support ......... yes PCH support ......... no IPv6 support ........ yes Thread support ...... yes NIS support ......... yes CUPS support ........ yes Large File support .. partial GIF support ......... yes MNG support ......... plugin (system) JPEG support ........ yes (system) PNG support ......... yes (system) Glib main loop support ......... no ... With my recent build using -glibmainloop, the build log shows the following: Configuration ....... nocrosscompiler dlopen_opengl minimal-config small-config medium-config large-config full-config styles tools kernel widgets dialogs iconview workspace inputmethod network canvas table xml opengl sql opengl release dll thread largefile stl ipv6 system-mng system-jpeg jpeg system-png png glibmainloop gif system-zlib nis cups bigcodecs x11sm xshape xinerama xcursor xrandr xrender xftfreetype tablet xkb inputmethod STL support ......... yes PCH support ......... no IPv6 support ........ yes Thread support ...... yes NIS support ......... yes CUPS support ........ yes Large File support .. partial GIF support ......... yes MNG support ......... plugin (system) JPEG support ........ yes (system) PNG support ......... yes (system) Glib main loop support ......... yes () ... Additionally, when using -glibmainloop, I see many instances of -DQT_USE_GLIBMAINLOOP. I do not find that in any previous build logs when I was not using -glibmainloop. Do you see the same thing with top? BTW, I'll add kicker and kmix to the list. Usage is not the same ~5% as kded and ksmserver, but both are now always near the top of the list at about 2% during idle. The Trinity process manager shows the same usage numbers. Well, at least you (inadvertently) answered my standing question of whether or not the internal event loop broke with all the threading updates--it appears to be perfectly fine! ;-) I may have misspoke earlier when I said there was no way for the TDE hardware library to affect these processes. ksmserver and the media manager in particular are TDE hardware library enabled, which means that if there are large numbers of udev events occurring on your system, they may consume CPU simply handling (and eventually ignoring) those events. Even without large numbers of udev events, the CPU polling loop could theoretically wake up any hardware-aware applications more often than would be desirable. One way to see if this is the case is to recompile and reinstall tdebase without TDE hardware library support (IIRC there is a CMake flag to do this). If the CPU usage drops to pre-R14 levels, then we found the culprit. Yes, as far as I can tell, nothing seemed broken or acted awry when I was building without knowledge of the new -glibmainloop configure option. I rebuilt tdebase with -DWITH_TDEHWLIB=OFF. ksmserver, kmix, kicker remain at the same usage. kded no longer appears anywhere in the top output. (In reply to comment #15) > Yes, as far as I can tell, nothing seemed broken or acted awry when I was > building without knowledge of the new -glibmainloop configure option. > > I rebuilt tdebase with -DWITH_TDEHWLIB=OFF. > > ksmserver, kmix, kicker remain at the same usage. kded no longer appears > anywhere in the top output. That might make some sense, as kded would include the media manager AFAIK and some of the other usages of the TDE hardware library (in ksmserver, etc.) are not guarded by compile time checks (by design). This should be resolved in GIT hash f04d5a3 (tdelibs). Thanks for reporting! Rebuilt with the latest GIT as of today, kded and ksmserver no longer remain at the top of top. They no longer appear in top. Kicker and kmix now hold those spots, hovering at about 2% on my dual core system but almost always at the top of top. Hi everyone! I had some time to test back R14 nightlies on Ubuntu 13.03 (June 8, 2013) and yes, CPU use is back to normal, very similar to 3.5.13.1! But, I have the following behavior: Sometimes, for no special reason, kdesktop starts to eat 80% of CPU time. Then, I can reboot and I don't have this problem. At first, I though that activating the TDE compositor was what cause the CPU use to drop (a little like on KDE4 it does), but after activating/un-activating it while rebooting between this changes, I saw that there is no link with the TDE compositor. I'll try to provide some more debug info in the next few days! -Alexandre |