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): 2.4.21-20.ELsmp 2.4.21-27.ELsmp 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:
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 a problem.
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.
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: http://www.redhat.com/security/updates/errata/ 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.