login
Search
Hi all,
I have a question about the behavior of the page frame reclaiming algorithm.
Suppose the kernel wants to free up some more memory by victimizing something in a cache. Suppose further that on my 2GB of ram machine, I've got about 1GB of files stored in a tmpfs, and about 750 MB of regular filesystem data as dirty pages in page cache (suppose I've been writing a lot of data recently). The rest of it is program memory.
It seems like there are a few options:
1. Swap out program memory
2. Swap out tmpfs pages
3. Flush page-cache to disk and free the clean pages
Can anyone shed light on what is going to happen in this situation? It seems to me like 3 is the most desirable action, but it seems like on my machine, 2 is done more often than it should be.
In case it matters, I'm running 2.6.24.2.
Thanks!
Any of your 3 options could be chosen
Any of your 3 options could be chosen. The kernel should keep the most frequently accessed data in ram, regardless of where that data came from. In principle there's no real reason why tmpfs should be any more or less efficient than a regular filesystem, though in practice the latter tend to have overhead due to journalling, etc.
/proc/sys/vm/swappiness can be used to tweak heuristics when balancing disk cache and swap.
That makes sense
That makes sense. I would love to be able to "protect" certain data by storing it in a tmpfs to keep it in cache more of the time. I had thought about playing with swappiness but I wasn't sure it would affect tmpfs pages swapping.
If I have to, I can use ramfs, which won't swap. However, it doesn't offer the nice features of usage reporting (via df) nor any hard limits so that I could ensure my application fails before my system fails when I run out of space.
Dissatisfied with this behavior
The more I think about it, the more I'm dissatisfied with this kernel/tmpfs behavior.
#1 - The kernel _should_ keep the most frequently accessed data in ram. And if it did, I would have no need to protect certain data. What it does do is keep the the most _recently_ accessed data in ram.
#2 - What tmpfs sounds like to me now is something where you trade all of your durability in exchange for the measly speedup associated with getting rid of journaling. You might as well just use ext2.
Perhaps #2 above is not true if you are generally just reading your data. However, once writes get into the picture, my experiments generally show that tmpfs pages are quite readily dumped ahead of dirty cache pages. And swappiness seems to have no effect. I'm guessing this has to do with either tmpfs swapping not being treated the same as normal swapping, or just %swap in a memory region being distorted to only consider tmpfs pages + clean pages (and not dirty pages). I might be a good bit off base on this theory though, I haven't looked at the algorithm closely enough yet.
Tmpfs seems to be a poor successor to ramfs. It would be better to just prepatch ramfs with hard size limits that are in tmpfs.
People tend to cringe when it's suggested to get around the kernel MM heuristics. However, I think it would be right here. What we really want, if tmpfs is to have meaning, is for tmpfs pages to be higher class citizens of cache when it comes to writing dirty pages to disk/swap.