On Tue, August 19, 2008 11:31, ABBAS KHAN wrote: > As by the time, I've learned that Linux works by caching apps by using a > lot > of RAM and then it reallocates the new stuff by cleaning the old cached > pages from memory as compared to other OSs. With 2 gigs of RAM often I see > the free memory only as 100-400MB. Using TOP or PS, it doesn't look like > any > program or process is using excessive memory (the highest process is seen > with 1-2% total memory). *So, my questions are:* > > what programs are using that much of memory? (or cached memory) It's very likely being used as disk cache. You can get some more numbers by running top, and looking at the last two lines of the headers. I routinely see over 1GB of cache on a not very active 4GB system. Your meminfo output is the same numbers, and looks completely normal to me. Free memory is *bad*; it means it's being wasted completely. Memory used for disk caching is instantly available if it's suddenly needed for a program. > Is that really due to a lot of cache in the memory > *if yes, then, is there a way to parse the cache to findout what > applications are eating up the cache?* It's only indirectly tied to an application; it's cached disk blocks. You could say the process that read that file last is responsible, but the *next* process to read those blocks is the one that would benefit. > *how to free the cached memory?* Why do you want to? As I said, "free" memory is memory that's going to waste. Unless you have severe real-time issues with a process becoming runnable where the difference between discarding a clean cached page, and just allocating a free page, will make a difference, there's no point. If you DO have that level really extreme real-time performance issues, you need to understand the whole virtual memory system an order of magnitude better than you seem to. That's off in a far corner of the Linux application space -- Linux can do some real-time stuff, but it's not the first choice for hard real-time environments last time I talked to any of those people. -- David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info