Bug 151916 - kernel memory leaks, memory cached never flushed
Summary: kernel memory leaks, memory cached never flushed
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 3.0
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Dave Anderson
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-03-23 15:25 UTC by RichardR
Modified: 2007-11-30 22:07 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-19 19:05:51 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description RichardR 2005-03-23 15:25:50 UTC
Description of problem:
We have actually SUN servers v20z (AMD Opteron 248/2.2Ghz with 4GB memory)
running RHEL/WS3 with kernel/2.4.21-xx.ELsmp. Since days we are running "screen"
processes on them and we just realized that memory is decreasing obviously! So
to reduce and to checkout where it could come from, we decide to switch linux on
init level 1, just without only strictly processes (sh,init) and we were
astonished to see that doing "free" stuff we saw that the memory cached still
occupied mostly the entire memory whereas no processes are using memory on this
state! so I just can think it's more a kernel bug but I could be wrong.

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

How reproducible:

Steps to Reproduce
1. we had many screens run but I think any other processes who occupied memory
increasly and when they exit, memory cache is still present and memory total is
still increasing. Just make the memory increased till saturation. Do "free" and
notice the memory and its buffer/cache

2. do a telinit 1

3. kill useless process and sh and init should left. after check memory again
with "free"
Actual results:
Memory total/cached never flushed even processes exit. 

Expected results:
Total memory should reduce each time a process exits.

Additional info:

Comment 1 Jason Baron 2005-03-23 15:38:00 UTC
Processes exiting does not necessarily mean that free memory should increase.
Linux uses memory as caches for many different purposes. These caches are
independent of process creation an exit. 

Comment 2 RichardR 2005-03-23 15:49:36 UTC
(In reply to comment #1)
> Processes exiting does not necessarily mean that free memory should increase.
> Linux uses memory as caches for many different purposes. These caches are
> independent of process creation an exit. 

so can you please explain me why these caches still occupying such a huge size
whereas no anymore processes are running except init and sh! and actually when I
am running a "screen" with a loop displaying date every second in init-level 1,
my memory free stack still goes down! I just want to know if this kinda of state
or behaviour for the kernel is normal or not.

Comment 4 Dave Anderson 2005-03-30 14:28:55 UTC
I'm not sure what the problem is here.

Anonymous memory allocated by processes will be freed immediately
upon process exit.  But page cache pages (file-backed pages) will
remain cached as long as there's no need to reclaim them.

If you were to run a program that was a huge memory hog, and then
touched all of the allocated memory, then killed the program, then
you would see the cached memory counts go down.

Comment 5 Donna Burych 2005-04-20 22:35:17 UTC
I observe this behavior on all my Dell Precision 670 Workstations running the 
2.4.21-27.0.2.ELsmp kernel.  The cache grows and doesn't free up.  The
workstation eventually hangs and has to be restarted.  And that is definitely
a problem.

Comment 6 Dave Anderson 2005-04-21 12:34:31 UTC
This last description is way too vague.  Again, there is no problem
with page cache memory consuming free memory since it's reclaimable.
If anonymous memory were not to be freed after the last process referencing
it exited, then that would obviously be a problem.  But even active
anonymous memory is reclaimable unless it's wired/locked.  

That being said, if the workstation hangs, then we do need the state of 
the memory pages.  What is required in that case is the output of Alt-sysrq-m.
Please attach that console output to this bugzilla, taken at the moment of
the hang.  

Comment 7 RHEL Product and Program Management 2007-10-19 19:05:51 UTC
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

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