Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 84482 - Interactive performance concerns
Summary: Interactive performance concerns
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On: 84833
TreeView+ depends on / blocked
Reported: 2003-02-17 21:50 UTC by Michael Fulbright
Modified: 2007-04-18 16:51 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-09-30 15:40:32 UTC

Attachments (Terms of Use)

Description Michael Fulbright 2003-02-17 21:50:27 UTC
Arjan asked me to file this for tracking.

On a 1GHZ Athlon with 512MB RAM and a Millenium ][ video card, the GNOME desktop
feels sluggish compared to the same experience with 8.0.

I bumped the X process using renice -10, does help much.

At 1280x1024 and 1024x768, the following is noticably sluggish:

 1) open emacs with 'emacs -fn 10x20 <file>'
 2) resize to height of screen
 3) open a gnome-terminal and drag it (opaque drag in metacity) around in circles
    across the emacs window.
 4) you will see the gnome-terminal window trailing the mouse pointer, trying to
    keep up.

Comment 1 Ingo Molnar 2003-02-17 21:57:16 UTC
is interactivity with X reniced to -10 just as good as it was in 8.0?

we might as well consider using nice -10 for X, since the major complaint when
we did the nice -10 change was that 'gnome terminal is sluggish' - which turned
out to be a different bug (hopefully fixed in the next snapshot).

was there any other regression with the X server reniced to -10, other than the
gnome-terminal problem?

Comment 2 Ingo Molnar 2003-02-18 12:02:00 UTC
i'm strongly in favor of reinstating the nice -10 priority of X.

we could do this in the kernel, but the preferred way would be to do it in the X
server. Any chance to have that done now?

Comment 3 Michael Fulbright 2003-08-18 21:06:37 UTC
What was the final resolution for this issue for new kernels?

Comment 4 Mike A. Harris 2003-08-19 01:49:52 UTC
That changing the X server priority is nothing more than a hack.  Instead,
the kernel should work with interactive processes in a better manner.  Our
current kernels IMHO do this MUCH better, and allegedly 2.6.0 test series
improves upon that, however I can't confirm that personally yet.

I think this can be closed safely now, but I'll leave that to a kernel
scheduler grand wizard.  ;o)

Comment 5 Bugzilla owner 2004-09-30 15:40:32 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem

The Fedora Legacy project ( maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at:

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