Red Hat Bugzilla – Bug 73309
X now runs with priority -10, sometimes causes system unresponsiveness
Last modified: 2007-04-18 12:46:17 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020809 Description of problem: Upon the latest (null) up2date, the new XFree86 package has X starting with priority -10, causing it to have a higher priority than most other running X applications. Depending on what's exactly going on with X, sometimes it will use 25-45% of the system processor causing hesitation (unresponsiveness) in other running applications. 937 root 5 -10 69116 19M 8972 S < 39.1 5.0 0:35 X ^^^^ Is there a reason for this deviation from normal (X runs at standard priority)? X, being the behemoth it is, will inevitably take advantage of its priority rendering the system act strangely. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Be up2date. 2. Check "top" listing - X should almost always be in the top 10. Actual Results: X is running at priority -10 (higher than normal). Expected Results: X in previous releases has ran at normal priority (0). Additional info:
The XFree86 package does not contain any changes that make it run at priority -10. If something is changing the priority, it was done without my knowledge of it occuring, so I have no idea what is doing it in order to reassign this bug report to the guilty party. <grin>
<twaugh> mharris: This is a kernel feature. <twaugh> mharris: Since it does direct IO. Reassigning to kernel component.
michael@yohe.net: Can you be more specific about the problem you're seeing? It's hard to see how making X *more* nice will make other X apps more responsive (since they interface the user *via* X).
It's entirely possible the "other apps" are not X apps at all. It could be povray rendering animation frames... compiling kernels, any number of things... It isn't clear if this change is a good one or a bad one at this point. I now understand (via IRC) why the change was made to the kernel, but I personally think that if we were going to change the X server nice value, it should be done by modifying the X server startup code to use a commandline option to change it's default nice level. IMHO, the kernel shouldn't dictate policy. Having it renice apps on its own, is setting system policy, rather than making it a userland thing settable by the sysadmin/user. ;o( I think we should really think deeper about this.
Exactly - I was looking for that exact feature (to modify the priority of the X server) because as of the latest up2date, "null" does not seem nearly as snappy as it did prior to the change. Sometimes X will go off and do something causing galeon to render as if this P2-400 was a 386/20. The longer X runs, the greater its footprint and processor requirements.
If you change font rendering to 'monochrome' (in Preferences->Font), can you still reproduce the problem? More importantly, if you change X's priority back to 0 using renice, does that make the problem go away?
Doh, didn't change components...
ping ping ping.... Not hard to test this with nice=0 by using renice to change priority. Please test and update status.
I have changed the priority and X does seem to calm down. But even still, after about fifteen minutes of operation - X seems to take much more processor time to render graphics. For example (when I'm browsing the web with Galeon) - X average usage at system start up averages about 1-5% on my dual 400MHz P2 system. After fifteen minutes, X starts stepping up processor usage even to render a page that's extremely simple (i.e. Google). X begins to rise up into the 10-20% range. Galeon is noticeably slower (you can actually see the elements of the web page being moved into their proper position). Correction? Restart X to get it to feel normal again. Restart the computer to get it snappy again. Possible kernel problem?
It's probably a kernel problem i tested under kernel-2.4.18-12.5 with renice -10 and performance is almost the same for normal use. Although if i start ico 3-4 times dragging windows is noticeably slower same for opening menus etc. i imagine the Xserver starves the window manager (WindowMaker) for some reason. I can't imagine that anyone in his right mind will run ico but i am sure there are usefull programs that hit the Xserver hard.
Most of these "X uses more cpu" issues are likely to be caused by AntiAliased fonts being used now......
The 'X slows down with use' problem sounds like it might be a memory leak of some sort. There were some large memory leaks fixed in vte recently (used in gnome-terminal). Are you using gnome-terminal? As Arjan said, the heavy use of AA now will certainly make the X server work harder for most video cards. If you try the test above concerning Preferences->Fonts and 'Monochrome', does that make things snappier?
Ever since I reported the gnome-terminal bug (Bug 73226) I have been using xterm for terminal purposes (which does not use anti-aliased fonts). Also, I use Galeon as the web browser (and Mozilla is still based on GTK+ 1.2 - no use of anti-aliased fonts there). I will attempt to compare the differences in strace's on a fresh XFree86 startup versus a well-worn XFree86 session - it seems that X is polling for something more often as you use it, causing things to bog seriously down.
X no longer runs with -10.