Bug 58681 - Apparent memory leak with athlon architecture when copying large files/directories.
Apparent memory leak with athlon architecture when copying large files/direct...
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.2
athlon Linux
high Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-22 17:22 EST by Michael J. Ayers
Modified: 2005-10-31 17:00 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-09 13:58:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michael J. Ayers 2002-01-22 17:22:13 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)

Description of problem:
All available system memory fills up when copying large folders or directories 
(either locally or via nfs).  It seems to be a memory leak somewhere in the IO 
subsystem.  This error is reproduceable on EVERY system we have (over 10) that 
is running the 2.4.9-13athlon kernel.


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


How reproducible:
Always

Steps to Reproduce:
1. Install the 2.4.9-13athlon rpm kernel.
2. Reboot.
3. Copy a large file or folder anywhere locally on the system.
4. Memory is full with about 5 megs free.
	

Actual Results:  All system memory filled up.  This is very visible by running 
top.

Expected Results:  Files should have copied and released all memory used during 
the copy process once it completed.

Additional info:


System Specs:
Motherboard:          MSI K7T266 Pro2
Processor:            AMD Athlon 1700+ XP (1.47GHz)
Memory:               1GB DDR SDRAM (Samsung)
Video:                MSI GeForce 2MX 400
Network:              3Com 3c509c TX-M
Audio:                AC97 onboard audio.
Comment 1 Arjan van de Ven 2002-01-22 17:25:39 EST
This is called "disk cache". If you need the data again it's already in memory
and doesn't have to come from disk -> lots faster.
If something actually needs the memory it's released immediatly.
Comment 2 Michael J. Ayers 2002-01-22 17:34:14 EST
Understood.  But it causes the system to hang after a period of time without 
releasing the memory back.  The memory NEVER gets released back....even after a 
period of hours.
Comment 3 Arjan van de Ven 2002-01-22 17:39:11 EST
It should be. You can easily test his with the following:

dd if=/dev/zero of=/tmp/testfile bs=1M count=1024 ; rm /tmp/testfile

which basically asks for memory and then gives it back. This should basically
free the cache by being nasty to the system...
Comment 4 Michael J. Ayers 2002-01-22 18:02:43 EST
That does force it to give back most of the memory that it took up, but there 
is still some left resident.  And if it is using disk-cache, is there not some 
sort of timeout before it releases the memory completely back to the system.  
Because the memory does get release back only when other processes request it.  
But it still always stays completely full (barring me forcing the machine into 
memory submission) until the system slows then locks up.  If there isn't some 
sort of timeout or clearing method (somewhat like a garbage collector)....that 
seems really inefficient to me.
Comment 5 Alan Cox 2003-06-09 13:58:50 EDT
Later 2.4.x errata are better about giving back memory efficiently when they
should. 

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