Bug 79515 - swapping a lot
swapping a lot
Status: CLOSED DUPLICATE of bug 73733
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
8.0
i686 Linux
medium Severity low
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-12-12 10:59 EST by Christopher Chan
Modified: 2007-04-18 12:49 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:50:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
XF86Config (1.82 KB, text/plain)
2002-12-12 12:07 EST, Christopher Chan
no flags Details
XFree86.0.log (21.41 KB, text/plain)
2002-12-12 12:08 EST, Christopher Chan
no flags Details
messages (23.10 KB, text/plain)
2002-12-12 12:09 EST, Christopher Chan
no flags Details

  None (edit)
Description Christopher Chan 2002-12-12 10:59:50 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.9) Gecko/20020408

Description of problem:
Running multiple mozilla browsers, sessions in konsole (or multiple gnome
terminals) with a screen history set to 100,000 causes the box to use almost all
256M of physical memory and over 300M of swap.

Switching desktops in kde or windowmaker is a pain and exiting from a terminal
renders the box almost useless as I wait for the disk activity to stop. Screen
updates are slow and cause disk activity even with a few lines in konsole or
gnome-terminal

mozilla, X and kdeinit (or gnome-terminal when I am using windowmaker and
gnome-terminal) are the largest memory hogs with kdeinit or gnome-terminal
taking the crown followed by mozilla.

I did not have it this bad in RH 7.3. I did have to close some terminals from
time to time then but I could close them pretty quickly without disk activity
temporarily rendering the box unusable.

At least it never crashed on me in 8.0

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Open some mozilla browsers
2. Open evolution
3. Open konsole
4. Set history to 100,000 lines
5. Open some terminals in konsole
6. Use it like this and later you're swapping with every line that runs down a
terminal session (disk activity before the line is drawn)
	

Actual Results:  Slow response in terminals, slow response in everything

Expected Results:  Things were much snappier in 7.3. Closing terminals to reduce
memory usage or closing browsers were done in seconds not minutes

Additional info:
Comment 1 Mike A. Harris 2002-12-12 11:26:55 EST
>Switching desktops in kde or windowmaker is a pain and exiting from a terminal
>renders the box almost useless as I wait for the disk activity to stop. Screen
>updates are slow and cause disk activity even with a few lines in konsole or
>gnome-terminal

Disable font antialiasing.  None of the drivers hardware accelerate RENDER
operations, so font antialiasing is done by your CPU.  This can noticeably
slow down some systems.

>mozilla, X and kdeinit (or gnome-terminal when I am using windowmaker and
>gnome-terminal) are the largest memory hogs with kdeinit or gnome-terminal
>taking the crown followed by mozilla.

And you're getting that information from "top", which is bogus.  The X
server consumes very little memory, contrary to what top says.  The total
memory usage given by top, includes among other things, video memory, which
is memory mapped, memory mapped I/O register space on your video board, and
perhaps other resources like video BIOS, etc.

Also, X resources are stored *inside* the X server.  Any client application
such as mozilla, etc. that allocates large pixmaps, ends up enlarging the
X server's memory space because those pixmaps are stored in the X server.
Almost all "X is memory leaking" bug reports in reality are "mozilla is
leaking pixmaps, which are X resources stored in the X server, and makes
X look like it is huge" when in fact it is not.

>I did not have it this bad in RH 7.3. I did have to close some terminals from
>time to time then but I could close them pretty quickly without disk activity
>temporarily rendering the box unusable.

The X server has not changed much at all from RHL 7.3 to 8.0 except for
bug fixes.  Any changes that you are seeing are most likely GNOME/KDE
related, or application specific bugs, and not XFree86 specific issues.
It's also possible it could be a kernel issue perhaps.

There is not really anything I can do about this as I don't believe
there is an XFree86 bug/problem at play here, and I most certainly do not
have any such problem on my own systems.





Comment 2 Mike A. Harris 2002-12-12 11:29:18 EST
Please attach your X server log, config file, and /var/log/messages file.
Make sure the messages file contains bootup information from your last
boot also, and include logrotated ones as well if need be, so I can
see your full kernel bootup sequence.
Comment 3 Michael Lee Yohe 2002-12-12 11:58:23 EST
Setting your history to 100,000 lines seems to be an awful lot of wasted space:

<top report after running ls -R / in konsole>

25990 myohe     15   0 81408  40M 10484 R     5.0  5.3   0:13 konsole
Comment 4 Christopher Chan 2002-12-12 12:07:10 EST
Created attachment 88624 [details]
XF86Config
Comment 5 Christopher Chan 2002-12-12 12:08:21 EST
Created attachment 88625 [details]
XFree86.0.log
Comment 6 Christopher Chan 2002-12-12 12:09:18 EST
Created attachment 88626 [details]
messages
Comment 7 Christopher Chan 2002-12-12 12:19:14 EST
Michael, never you mind the 100,000 lines. I use that for a reason. Besides, the
effect of that on 7.3 was not too adverse. Oh, I use the Nvidia driver for the
Asus Combat (whatever) TNT-Vanta card and not the XFree86 one.

Mr. Harris,

Can you explain why lines sent to a terminal cause disk activity? tailing logs
on 8.0 is really choppy compared to 7.3 (not that I could follow the stuff on
7.3) I now run with no history and so I do not have problems now.
Comment 8 Michael Lee Yohe 2002-12-12 12:22:31 EST
I am almost positive that this bug will be handed off to Bug 78616 - "A binary
only kernel module was in use when something bad happened".  You should see if
you have the same behaviour with the stock XFree86 nVidia driver (the one that
is supported by Red Hat).
Comment 9 Arjan van de Ven 2002-12-12 12:26:26 EST
it's probably going to be 73733 :)
however since the erratum 7.3 kernel and 8.0 kernels are identical... we can
rule out kernel interaction
Comment 10 Mike A. Harris 2002-12-13 23:59:40 EST
Arjan's synopsis is correct.  You are using proprietary kernel modules
that Red Hat did not ship, and Red Hat does not support.



*** This bug has been marked as a duplicate of 73733 ***
Comment 11 Christopher Chan 2002-12-14 08:16:15 EST
gee. I have quite a few colleagues that downgraded from 8.0 back to 7.3. They
didn't use any proprietory drivers but they all ran into similar problems. Like
Arjan said, we can rule out kernel interaction (hmm does that count third-party
drivers?). Anyway, I used the same Nvidia drivers in 7.3 and 8.0 if that helps
at all in this particular case....
Comment 12 Mike A. Harris 2002-12-14 09:08:24 EST
No, it does not rule out 3rd party drivers.  Arjan is ruling out Red Hat kernel
which does not contain 3rd party drivers.  3rd party drivers can do absolutely
anything to the kernel, and even if they're rmmod'd they could have modified
anything in the running kernel prior to that.

The binary only Nvidia kernel code is compiled with egcs 2.91.66, and Nvidia
so far has refused to use any other compiler.  The Red Hat kernel is compiled
with gcc 3.2 in RHL 8.0.  The Linux kernel does not have a kernel module ABI,
and as such gives no ABI guarantees.  All of the code in a running kernel must
be compiled by the same major version of the gcc compiler.  It is a known
fact, that gcc 2.x compiled kernel code is not compatible with gcc 3.x kernel
code.  Once Nvidia acknowledges this, and recompiles their drivers with
gcc 3.x for use in gcc 3.x compiled kernels instead of ignoring the problem,
perhaps users won't have so many problems when using their drivers.

Comment 13 Christopher Chan 2002-12-14 10:35:05 EST
Well then is this bug still open? Or do I have to pull out the Nvidia driver
from loading during start up and use the XFree86 provided driver?
Comment 14 Christopher Chan 2002-12-14 10:40:38 EST
oh, if this is not a kernel nor a XFree86 bug will it be moved to an appropriate
section?
Comment 15 Mike A. Harris 2002-12-14 10:42:47 EST
This bug is closed period.  Contact Nvidia at support@nvidia.com for support
for their driver.
Comment 16 Christopher Chan 2002-12-14 11:21:59 EST
Ok. Thanks for the information
Comment 17 Red Hat Bugzilla 2006-02-21 13:50:18 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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