Xorg performance / KDE stability work-around on Slackware64 13.0
If you've been experiencing performance issues under X or stability issues with KDE4 then you may be interested in the following. This was on Slackware64 13.0 using the 'nv' open-source Xorg driver. Other drivers may or may not be effected, I don't know.
What I found was that when running glxgears under Windowmaker, performance was extremely sluggish, even something as simple as starting a new xterm took several seconds when it should have been instant. Worse still, under KDE4, running glxgears resulted in severe slowdown and instability.
As an example, when trying to start 'konsole', after a significant delay
I got this:
Quote:
Communication problem with "konsole" , it probably crashed.
Error message was: "org.freedesktop.DBus.Error.NoReply" : " "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." "
|
In summary, I found that by giving the /usr/bin/X server a more favourable nice value all these issues went away.
Find the pid of the /usr/bin/X process with 'ps a' then issue a
"renice -4 -p <pid>". You'll need to be root to do this.
If you find this solves your problem and want to put this change in place permanently then I've written a little snippet of code which follows:
Code:
/* Xorg.reniced V1.0 (2009-09-05)
*
*
* Wrapper for /usr/bin/Xorg that calls setpriority() to increase the
* priority of the process before invoking the real Xserver binary via
* execve().
*
* This wrapper was written to solve a specific performance problem
* I was experiencing with the X.org open-source 'nv' driver on
* Slackware64 13.0.
*
* Specifically,
* When running a mesa/opengl program such as glxgears, subsequent
* desktop performance and application startup was extremely slow.
*
* Though also evident in lightweight window manager environments,
* this was particularly bad in KDE4 where applications generally
* interact with other components of the desktop and would actually
* fail to start citing, "communication problem/timeout errors".
*
* I discovered that running glxgears with a less favourable
* niceness would avoid the performance problem, however,
* it's not an ideal solution. Renice'ing the Xserver to give
* it a more favourable priority is arguably the more
* reliable approach.
*
* To avoid having to run renice (as root) manually each time X is
* (re)started, I created this little wrapper process.
*
* I get the feeling that this is treating the symptom rather than the
* cause. I'm not sure why glxgears running on equal priority is
* causing such a severe impact (especially on a dual core box) but
* it probably makes sense to have the Xserver running with higher
* priority than normal user applications anyway and this quick-fix
* will do the job for now.
*
*
* To Build:
* cc -Wall -o Xorg.reniced Xorg.reniced.c
*
* To Install:
* install -s -o root -g root -m 4755 -t /usr/local/bin Xorg.reniced
*
* Then, either,
* ln -sf /usr/local/bin/Xorg.reniced /usr/bin/X
*
* or specify it directly via your startx/xinit command or,
* ~/.xserverrc and /etc/X11/xdm/Xservers files.
*
*/
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <errno.h>
#include <sys/time.h>
#include <sys/resource.h>
#define XORG_BINARY_PATH "/usr/bin/Xorg"
/* XORG_BINARY_PATH - Hardcoded name of Xserver binary.
* As this will be running suid root, hardcoding seemed less
* of a security risk than dealing with parameters
*/
#define RENICE_VALUE -4
/* RENICE_VALUE - The desired nice value for the Xserver.
* Some important system tasks already run at -5,
* probably safest to not go that far.
* udevd runs at -4
*/
int main( int argc , char *argv[] , char *envp[] )
{
static char x_server_binary[] = { XORG_BINARY_PATH } ;
errno = 0 ;
if ( setpriority( PRIO_PROCESS , 0 , RENICE_VALUE ) != 0 )
perror( "Xorg.reniced setpriority() failed" ) ;
/* Whether setpriority() worked or not, we might as well
* try and start the Xserver, as we'll be no worse off than
* we were originally.
*/
errno = 0 ;
(void) execve( x_server_binary , argv , envp ) ;
/* execve() doesn't return on success.
* If we get this far then we know something bad has happened.
*/
perror( "Xorg.reniced execve() failed" ) ;
return 1 ;
}
I can't overstate how much of a difference this made to my system, especially in KDE which was unusable without it.
P.S. My net connection has been down for 4 days now so I'm not sure whether this may be relevant to any other ongoing discussions. |
