Bug 83762 - kswapd consumes cpu/memory/swap during gcc/g++ compile
Summary: kswapd consumes cpu/memory/swap during gcc/g++ compile
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 8.0
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-02-07 23:13 UTC by Scott Wells
Modified: 2007-04-18 16:50 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-06-05 14:49:09 UTC
Embargoed:


Attachments (Terms of Use)
dmesg foutput (8.05 KB, text/plain)
2003-02-22 20:15 UTC, Sam Varshavchik
no flags Details
lspci output. (2.88 KB, text/plain)
2003-02-22 20:17 UTC, Sam Varshavchik
no flags Details

Description Scott Wells 2003-02-07 23:13:28 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020830

Description of problem:
I am running Red Hat linux v8.0, kernel 18-24, running on a P4 with 750+mb of
ram and 1.5gb of swap. Sometimes when I 'make' a large package (such as alsa9),
my computer freezes and my hard drive starts spinning. I cannot move the mouse,
keyboard strokes don't work, and I can't even log on from another terminal. This
problem has occurred only while I was doing a 'make (gcc/g++) on programs. It
didn't seem to matter WHICH programs I was compiling.

After running 'top' to spy on processes, I found that, during a make,
the kernel daemon,'kswapd', was taking over 85% of the CPU time and 100% of
memory and swap space. 

Here's the output of top:
---
3:59pm up 1 day, 2:01, 2 users, load average: 22.91, 14.28, 6.48
140 processes: 129 sleeping, 9 running, 2 zombie, 0 stopped
CPU states: 2.9% user, 81.7% system, 0.0% nice, 15.2% idle
Mem: 764400K av, 757412K used, 6988K free, 0K shrd, 848K buff
Swap: 1566328K av, 1566328K used, 0K free 10620K cached

5 root 25 0 0 0 0 RW 78.7 0.0 10:38 kswapd
10560 swells 15 0 4036 3056 844 R 1.1 0.3 1:13 xmms
10568 swells 15 0 256 140 88 S 0.6 0.0 0:12 esd
1002 root 5 -10 151M 4492 780 S < 0.3 0.5 326:28 X
15702 swells 15 0 548 512 264 R 0.3 0.0 0:24 top
6289 swells 15 0 17592 8784 1420 S 0.2 1.1 3:41 galeon-bin
25907 mailman 15 0 1856 1840 576 R 0.2 0.2 0:00 python
25912 mailman 15 0 1620 1620 532 R 0.2 0.2 0:00 python
1898 swells 15 0 38372 3840 392 D 0.1 0.5 0:23 gnome-panel
1906 swells 15 0 10140 2868 584 D 0.1 0.3 2:01 rhn-applet-gui
10647 swells 15 0 3864 1492 648 D 0.1 0.1 0:12 evolution-mail
25908 mailman 15 0 1616 1616 532 D 0.1 0.2 0:00 python
25910 mailman 15 0 1620 1596 532 R 0.1 0.2 0:00 python
25916 mailman 15 0 1376 1372 520 R 0.1 0.1 0:00 python
25922 lp 15 0 472 360 276 D 0.1 0.0 0:00 lpd
1 root 15 0 88 44 28 S 0.0 0.0 0:05 init
2 root 15 0 0 0 0 SW 0.0 0.0 0:00 keventd

There are a few more processes, but they seem to be irrelevent

When the process finishes, I get:
4:08pm up 1 day, 2:09, 2 users, load average: 7.45, 21.66, 14.78
119 processes: 114 sleeping, 3 running, 2 zombie, 0 stopped
CPU states: 0.7% user, 0.5% system, 0.0% nice, 98.6% idle
Mem: 764400K av, 102644K used, 661756K free, 0K shrd, 2368K buff
Swap: 1566328K av, 146008K used, 1420320K free 30452K cached

I am using gcc/g++ version 3.2.

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


How reproducible:
Sometimes

Steps to Reproduce:
1.d/l alsa9
2.Run ./configure, then make
3.It might take a few 'makes' before it happens. If so, do a 'make clean'
between each make
    

Actual Results:  The computer freezes...kswapd eats all my resources.

Expected Results:  I have plenty of memory and 1.5gb of swap. so this should not
have happened.

Additional info:

Comment 1 Arjan van de Ven 2003-02-07 23:15:45 UTC
can you use the "M" key in top to sort by biggest memory user and see what's
using most ram in teh problem case ?

Comment 2 Scott Wells 2003-02-10 18:11:14 UTC
Here is the printout of 'top' with 'M' set.

 11:53am  up 4 days, 21:55,  2 users,  load average: 12.53, 6.28, 2.95

123 processes: 115 sleeping, 5 running, 2 zombie, 1 stopped

CPU states:  0.2% user, 83.5% system,  0.0% nice, 16.1% idle

Mem:   764400K av,  757512K used,    6888K free,       0K shrd,     944K buff

Swap: 1566328K av, 1566328K used,       0K free                    4172K cached



  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND

26283 swells    15   0 1971M 651M   200 D     0.0 87.2   1:34 gnome-terminal

25561 swells    15   0 15424  15M   124 D     0.0  2.0   0:01 cc1

 1898 swells    15   0 95368 6820   220 D     0.0  0.8   1:04 gnome-panel

 1002 root       5 -10  151M 4976   208 D <   0.2  0.6  1318m X

 1906 swells    15   0 13512 4488   384 D     0.0  0.5   4:39 rhn-applet-gui

 1880 swells    15   0 28408 4260   244 D     0.0  0.5   1:08 metacity

25434 swells    15   0  3496 3492    52 S     0.0  0.4   0:00 make

24697 swells    15   0  2852 2440    92 S     0.0  0.3   0:00 evolution-addre

25564 mailman   15   0  2248 2248   416 D     0.1  0.2   0:00 python

24644 swells    15   0  2548 1840   140 D     0.0  0.2   0:00 evolution

25536 swells    15   0  1340 1340    52 S     0.0  0.1   0:00 make

24714 swells    15   0  3056 1056    92 S     0.0  0.1   0:00 evolution-mail

 1900 swells    15   0 24708  900   256 S     0.0  0.1   0:30 nautilus

 1077 swells    15   0  3740  828   140 S     0.0  0.1   0:08 gconfd-2

10594 swells    15   0  1372  580    88 S     0.0  0.0   0:00 wombat

25566 mailman   15   0   564  564   404 D     0.0  0.0   0:00 python

24047 swells    16   0   484  440   196 R     0.2  0.0   0:11 top



Comment 3 Sam Varshavchik 2003-02-22 20:14:18 UTC
METOO

I can reproduce this bug on one out of five boxes.

During a large C++ compile, kswapd occasionally pegs the CPU at 85%, and
generates constant disk activity.  The system quickly stops responding to all
mouse and keyboard input.  This does not occur on all compiles.  The bug can be
reliably reproduced by attempting to open a new gnome-terminal window while the
compile is in progress.

If I quickly CTRL-ALT-BACKSPACE as soon as I notice kswapd going off the
deepend, the system usually recovers about two minutes later.  Otherwise a
reboot is required.

The affected box is a P-II class CPU with 256MB RAM and 512MB swap partition,
and an IDE hard disk.

The boxes that never exhibit this bug are all SMP boxes with P-III class CPUs,
with either 256MB or 512MB RAM, and appropriately-sized swap, and SCSI hard drives.

Attaching dmesg + PCI listing from the box exhibit this bug.



Comment 4 Sam Varshavchik 2003-02-22 20:15:36 UTC
Created attachment 90280 [details]
dmesg foutput

Comment 5 Sam Varshavchik 2003-02-22 20:17:37 UTC
Created attachment 90281 [details]
lspci output.

This is an Intel 440BX motherboard.

Comment 6 Scott Wells 2003-02-24 18:17:36 UTC
This problem also happens eventually with gedit (Gnome Edit) as well as
Gnome Terminal.

I have a P-IV 2.0GHZ with 764MB RAM and 1.5GB swap partition, and an
IDE hard disk.

Comment 7 Alan Cox 2003-06-05 14:49:09 UTC
The ever expanding gnome terminal memory hog bug is fixed by RH 9. We've also
made changes over time to try and get better performance under thrashing loads.
In the cases above it seems the big problem with the gnome-terminal leaking
memory making g++ tip it over.




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