[Not sure of the protocol here: should I have posted to Bug 690? or sent this email?]
3.5.13 kdm_greet eats lots of CPU.
I see this was marked as fixed (Bug 690) and looking at the source of Slavek's kdm-trinity, I'm using his ppa on wheezy so the version of kdm-trinity installed is 4:3.5.13-2debian0~pre26+7~wheezy, the patches for kgreeter.cpp and sakdlg.cc are in place... but the bug's still there.
It seems worse when a remote display connects but also happens with just a display on the machine's console.
This is happening on my little laptop test mule (Intel Core 2) and a larger 16 core server (AMD Opteron).
A few observations:
/tmp/ksocket-global exists and is mode 0644. Curiously it's owned by what appears to be a random user-id. If I stop kdm, remove the /tmp/ksocket-global directory and restart kdm it recreates ksocket-global mode 0644 but owned by user id 1000... as that's the uid for the kdm_greet process (eh? why is kdm_greet changing its process uid? kdm is running as root. can't even see setuid being used in the kfrontend code).
/tmp/ksocket-global is an empty directory.
An strace on kdm_greet shows the following loop:
read(-1, 0xbfcdd300, 2048) = -1 EBADF (Bad file descriptor) recv(4, 0x993e5f0, 4096, 0) = -1 EAGAIN (Resource temporarily unavailable) nanosleep({0, 500000}, NULL) = 0 gettimeofday({1358766636, 578738}, NULL) = 0 recv(4, 0x993e5f0, 4096, 0) = -1 EAGAIN (Resource temporarily unavailable) gettimeofday({1358766636, 578825}, NULL) = 0 select(9, [4 5 8], [], [], {0, 0}) = 0 (Timeout) gettimeofday({1358766636, 578940}, NULL) = 0 read(-1, 0xbfcdd300, 2048) = -1 EBADF (Bad file descriptor)
The read from -1 is obviously wrong.
/var/log/kdm.log contains errors as follows:
Jan 21 11:17:52 kdm_config[30569] info: Cannot open master configuration file /etc/trinity/kdm/kdmdistrc
<fair enough: it doesn't exist>
X.Org X Server 1.12.4 Release Date: 2012-08-27 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32-5-amd64 i686 Debian Current Operating System: Linux lapcat 3.2.32lls-rt48 #2 SMP Wed Dec 12 10:32:35 GMT 2012 i686 Kernel command line: BOOT_IMAGE=Linux ro root=UUID=7b9e9723-c08f-426c-96a6-4ad9aeee1e5d Build Date: 29 November 2012 08:52:43PM xorg-server 2:1.12.4-4 (Julien Cristau jcristau@debian.org) Current version of pixman: 0.26.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Mon Jan 21 11:17:52 2013 (==) Using system config directory "/usr/share/X11/xorg.conf.d" (II) [KMS] Kernel modesetting enabled. QWidget::setMinimumSize: The smallest allowed size is (0,0) QWidget::setMaximumSize: (unnamed/QDialog) Negative sizes (-1,-1) are not possible sh: warning: setlocale: LC_ALL: cannot change locale (en_GB) QSettings::sync: failed to open '/etc/qt3/qt_plugins_3.3rc.tmp' for writing
This file does exist mode 0644 uid root, gid root. /etc/qt3 is mode 0755, root.root /etc is 0711, root.root
QSettings: error creating /tmp/1468675921/.qt
/tmp/1468675921/.qt does exist. Mode 0775, root.root. Nothing in there though.
QSettings::sync: failed to open '/etc/qt3/qt_plugins_3.3rc.tmp' for writing QSettings: error creating /tmp/1468675921/.qt QSettings::sync: failed to open '/etc/qt3/qt_plugins_3.3rc.tmp' for writing QSettings: error creating /tmp/1468675921/.qt QSettings::sync: failed to open '/etc/qt3/qt_plugins_3.3rc.tmp' for writing QSettings: error creating /tmp/1468675921/.qt QSettings::sync: failed to open '/etc/qt3/qt_plugins_3.3rc.tmp' for writing QSettings: error creating /tmp/1468675921/.qt QSettings::sync: failed to open '/etc/qt3/qt_plugins_3.3rc.tmp' for writing QSettings: error creating /tmp/1468675921/.qt QSettings::sync: failed to open '/etc/qt3/qt_plugins_3.3rc.tmp' for writing
I'm very happy to test/debug/try code.
Original Bug Ref: http://bugs.trinitydesktop.org/bugzilla/show_bug.cgi?id=690
Quoth Russell Brown.....
3.5.13 kdm_greet eats lots of CPU.
As a followup to my own post (bad form I know :-)....
I've made a change to kdm that adds an option 'UseKDMCTL' (like UseSAK) in kdmrc that can turn off the monitoring of the kdmctl FIFO (defaults to true so it won't change anything).
Turning off this monitoring (and thence the loop where Tim's 500usec sleep was inserted to try and reduce the load) drops the CPU usage of idle kdm_greet processes from significant to undetectable (as background I'm trying to configure a 30+ Xterminal system and having 30 kdm_greets trying to eat ~10% CPU each isn't good).
The downside is that with this option set to 'true', kdmctl will obviously no longer work; but at least folk have the option and it's pretty clear what the choices are.
The files modified are: config.def, kfrontend/kgapp.cpp and kfrontend/kgreeter.cpp
Where and in what format should I send the patches for review?
You can send patches to the mailing list. Send a patch as an attachment using git diff
Thanks!
On 24 January 2013 12:59, Russell Brown russell@lls.lls.com wrote:
Quoth Russell Brown.....
3.5.13 kdm_greet eats lots of CPU.
As a followup to my own post (bad form I know :-)....
I've made a change to kdm that adds an option 'UseKDMCTL' (like UseSAK) in kdmrc that can turn off the monitoring of the kdmctl FIFO (defaults to true so it won't change anything).
Turning off this monitoring (and thence the loop where Tim's 500usec sleep was inserted to try and reduce the load) drops the CPU usage of idle kdm_greet processes from significant to undetectable (as background I'm trying to configure a 30+ Xterminal system and having 30 kdm_greets trying to eat ~10% CPU each isn't good).
The downside is that with this option set to 'true', kdmctl will obviously no longer work; but at least folk have the option and it's pretty clear what the choices are.
The files modified are: config.def, kfrontend/kgapp.cpp and kfrontend/kgreeter.cpp
Where and in what format should I send the patches for review?
-- Regards, Russell
| Russell Brown | MAIL: russell@lls.com PHONE: 01780 471800 | | Lady Lodge Systems | WWW Work: http://www.lls.com | | Peterborough, England | WWW Play: http://www.ruffle.me.uk |
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Quoth Calvin Morrison.....
You can send patches to the mailing list. Send a patch as an attachment using git diff
Tis attached.
Quoth Russell Brown.....
3.5.13 kdm_greet eats lots of CPU.
As a followup to my own post (bad form I know :-)....
I've made a change to kdm that adds an option 'UseKDMCTL' (like UseSAK) in kdmrc that can turn off the monitoring of the kdmctl FIFO (defaults to true so it won't change anything).
Turning off this monitoring (and thence the loop where Tim's 500usec sleep was inserted to try and reduce the load) drops the CPU usage of idle kdm_greet processes from significant to undetectable (as background I'm trying to configure a 30+ Xterminal system and having 30 kdm_greets trying to eat ~10% CPU each isn't good).
Thank you for tracing the problem. Given the high CPU load observed I probably have no choice but to rework the SAK pipe code in tdm to use a TQSocketNotifier to avoid busywaiting. Opening a bug report on this issue would help us track the problem and any potential fixes that are committed to GIT; you can also attach your patch to the new bug report.
Thanks!
Tim
Quoth Timothy Pearson.....
Quoth Russell Brown.....
3.5.13 kdm_greet eats lots of CPU.
Thank you for tracing the problem. Given the high CPU load observed I probably have no choice but to rework the SAK pipe code in tdm to use a TQSocketNotifier to avoid busywaiting.
That would be the 'proper' solution but I'm not familiar enough with QT to even attempt that!
In the meantime, the silly little changes I made allow folk to get around the issue and won't effect a future 'proper' solution.
It's also worth commenting that for most people with a single machine it's not really a big issue in the first place; I'm unusual in have lots of kdm_greets running.
Opening a bug report on this issue would help us track the problem and any potential fixes that are committed to GIT; you can also attach your patch to the new bug report.
Reopened Bug 690 and added the patch to that.
-
Calvin Morrison -
russell＠lls.lls.com -
Timothy Pearson