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):
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
Memory total/cached never flushed even processes exit.
Total memory should reduce each time a process exits.
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.
(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.
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.
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
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
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.