login
Search
I recently investigated the actual output of the free command and the cat /proc/meminfo command. I guess I had suspected something was amiss because I noticed that free and meminfo reported a lot of memory in caches when I knew I was taking up a lot of memory with the ramdisks, and the ramdisks were completely full of data.
With full ramdisks, apparently the ramdisk is still counted as cache. Even though there is no hope if reclaiming it, it shows up as cached in both meminfo and free. This way of presenting the information is worse than not presenting it, because it causes people to be misled into thinking there is something wrong with the kernel, that it goes into swap hell when there are still 500 Megs in caches that it should reclaim and use before swapping aggressively and just about stopping the system cold. But in this case it can't reclaim much of what is in "caches" because it is locked for use by the ramdisk or the application using it. It can't just evict pages that hold the virtual machines in VMWare. It certainly can't just evict pages that are in ramdisk.
You know, an idea I saw recently was that since the ramdisks are in cache, maybe they could be sent to backing storage. Well, so much for the extra speed you might be expecting from using a ramdisk. I guess I am not averse to that as long as there is still a ramdisk you can't swap out, otherwise, who would ever want to use a swappable ramdisk? The ramdisk was invented to avoid hard disk or floppy access so it would about kill its usefulness to swap it out, unless you could control it so that it swaps out when you know it isn't needed, and swaps back in before it is next needed.
Whatever. I am hoping that these utilities could be modified a little so that they show reclaimable cache and locked cache. then the confusion would go away. The kernel knows what it can reclaim and what it can't, so I am sure even a new tool could be written to give the more accurate picture of memory, so we don't have people complaining about having 500 Megs in caches and still going into swap hell.
If you have 256 MB of RAM, and are tired of swap hell, and you get another 256 MB, well it will be irritating to find you still have no free memory. But it sure seems like it should stop the swap hell. Unless with the more memory the apps that lock their caches just compensate by putting more in memory because it is there, like the kernel does. If that happens, the best answer, until someone changes the mm behavior, is to buy more memory and use it to replace the swap partition on the disk. It will still go into swap hell, but it will happen fast and won't slow things down so much.
The reason I made the swap in RAM was that going from 512 MB of RAM to 1GB did not fix the waiting for swapping problem we had. So I said, if adding more RAM doesn't allow the kernel to keep my apps in memory, but just allows it to use all of it for caches and buffers, I will just restrict how much it can use to 512 MB, and lock the other 512 MB in ramdisks. After that no more waiting more than a half second for swapping. Of course, if it needed to get something from the hard drive, that wait was still there. But not having to wait for swapin was a great relief. Sure it cost a little RAM money, but for some conditions that would make little difference. If it is a home computer, well, that is one thing, but if it is a business matter, what is another $100 for a full extra GB stick as of June 05?
So, not only does the kernel use up all memory you put in, and eventually swap out your apps, but its tools to see how much memory is available give very misleading results. A compound problem.
You can see this misleading output yourself. Go to
