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):
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).
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.
<twaugh> mharris: This is a kernel feature.
<twaugh> mharris: Since it does direct IO.
Reassigning to kernel component.
firstname.lastname@example.org: 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
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.