Bug 73309 - X now runs with priority -10, sometimes causes system unresponsiveness
Summary: X now runs with priority -10, sometimes causes system unresponsiveness
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 8.0
Hardware: i686
OS: Linux
medium
low
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks: 67218 79579
TreeView+ depends on / blocked
 
Reported: 2002-09-02 20:54 UTC by Michael Lee Yohe
Modified: 2007-04-18 16:46 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-02-13 17:55:24 UTC
Embargoed:


Attachments (Terms of Use)

Description Michael Lee Yohe 2002-09-02 20:54:20 UTC
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:

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

Comment 2 Mike A. Harris 2002-09-03 15:30:28 UTC
<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 15:34:37 UTC
michael: 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 15:46:31 UTC
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 17:52:14 UTC
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 18:09:45 UTC
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 19:14:33 UTC
Doh, didn't change components...

Comment 8 Mike A. Harris 2002-09-05 12:45:46 UTC
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 16:25:39 UTC
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 17:05:19 UTC
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 17:13:38 UTC
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 17:19:23 UTC
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 19:19:08 UTC
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 17:55:24 UTC
X no longer runs with -10.


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