Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 73309 - X now runs with priority -10, sometimes causes system unresponsiveness
X now runs with priority -10, sometimes causes system unresponsiveness
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i686 Linux
medium Severity low
: ---
: ---
Assigned To: Arjan van de Ven
David Lawrence
Depends On:
Blocks: 67218 79579
  Show dependency treegraph
Reported: 2002-09-02 16:54 EDT by Michael Lee Yohe
Modified: 2007-04-18 12:46 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-02-13 12:55:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michael Lee Yohe 2002-09-02 16:54:20 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:

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:
Comment 1 Mike A. Harris 2002-09-03 11:28:07 EDT
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.

Comment 2 Mike A. Harris 2002-09-03 11:30:28 EDT
<twaugh> mharris: This is a kernel feature.
<twaugh> mharris: Since it does direct IO.

Reassigning to kernel component.
Comment 3 Tim Waugh 2002-09-03 11:34:37 EDT
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).
Comment 4 Mike A. Harris 2002-09-03 11:46:31 EDT
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.
Comment 5 Michael Lee Yohe 2002-09-03 13:52:14 EDT
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.
Comment 6 Tim Waugh 2002-09-03 14:09:45 EDT
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?
Comment 7 Mike A. Harris 2002-09-03 15:14:33 EDT
Doh, didn't change components...
Comment 8 Mike A. Harris 2002-09-05 08:45:46 EDT
ping ping ping....

Not hard to test this with nice=0 by using renice to change priority.

Please test and update status.
Comment 9 Michael Lee Yohe 2002-09-05 12:25:39 EDT
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?
Comment 10 Kostas Georgiou 2002-09-05 13:05:19 EDT
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.

Comment 11 Arjan van de Ven 2002-09-05 13:13:38 EDT
Most of these "X uses more cpu" issues are likely to be caused by AntiAliased
fonts being used now......
Comment 12 Tim Waugh 2002-09-05 13:19:23 EDT
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?
Comment 13 Michael Lee Yohe 2002-09-05 15:19:08 EDT
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.
Comment 14 Bill Nottingham 2003-02-13 12:55:24 EST
X no longer runs with -10.

Note You need to log in before you can comment on or make changes to this bug.