请教一个页匡回收流程的问题

vincentve

页框回收执行到最后，shink_page_list，如果能确定可以回收一个page，推测会走到free_it分支，在里面调用free_hot_cold_page就把它扔回给伙伴系统了。
但如果这个页也在缓存中呢？在这附近没找到类似remove_from_page_cache、radix_tree_delete这样的调用，那么下次访问一个文件，莫非还能从缓存中找到这个已经被释放掉的页码？
这里想不太明白，望大神出来指点，多谢~~

nswcfd

应该不会吧，如果还被LRU使用着，是不能交还给buddy system的。
大家都使用page->lru来管理不同的链表，LRU用挂在active/inactive链上，buddy system挂在free_area[order]。

话说回来，如果page被引用着，也不会被回收算法选中进入free-it分支吧？（不太确定）

vincentve

nswcfd 发表于 2015-03-18 12:03
应该不会吧，如果还被LRU使用着，是不能交还给buddy system的。
大家都使用page->lru来管理不同的链表，LR ...

“如果page被引用着，也不会被回收算法选中进入free-it分支吧？”

---那么mmap一个文件产生的vma，里面曾经拿到的page岂不是永远都收不回去了，应该是可以被回收算法解引用然后回收的吧

nswcfd

不好意思，前面的描述不太严谨。以下是个人理解：

mmap里增加了page的count和map_count，只有等到对应的引用计数释放之后才能被回收（例如在unmap里）。
也就是说，带着引用计数是不能还给buddy system的。——从buddy system返回一个新page之前，会检查这些引用计数的。

但这不意味mmap的page不能被reclaim（回收的时候会根据swappiness决定是否选择mmap页面），但回收之前一定得释放引用计数。
这个过程应该是在try_to_unmap里面完成的。

至于lz提到的从radix_tree里删除的操作，应该是在free_it之前完成的。

vincentve

感谢ls，但我的问题就是没找到在哪执行的radix_tree删除操作，并且从现象上看，我遇到的实际问题是：

我的进程mmap了一堆很大的文件，然后不停的随机读（好吧，就是mongodb），然后我发现整个进程的RES维持在20g左右，到了这个平衡点，进程就开始不停的page fault拿页面，同时不停的被系统回收页面了

但我的系统一共96g内存，基本只跑这一个有用的进程，整系统用free看到的缓存是约为80g

然后我又看了下我那一大堆文件在缓存中对应的页面（用一个叫fincore的工具，基于mincore调用，就是从文件---缓存这条路径找的），发现居然有70多g之多

到这我就想不明白了，这些文件肯定只有这一个进程用过，到底我的进程是吃了20g缓存，还是吃了70g缓存

莫非收页面的时候把页面收走了，但没在radix_tree中解掉映射，导致从页缓存角度看，认为自己还有70多g？

然后看了两眼页回收的函数，发现果然没有这个删除radix_tree相关的代码，我就疑惑了，不会真的是这样吧。。。
   

nswcfd

我发现我的解释有问题，写了一个简单的程序，mmap一个比内存大的文件，顺序遍历文件，最后的现象跟你描述的一致。
最后进程rss部分基本上相当于系统pagecache的大小，即便程序退出之后pagecache也是不回收的。
这也是合理的，这些pagecache留着命中以后的读操作呢。

假设文件是内存的两倍，进程的rss等于内存大小（理想状态）。
那么读前一半内容的时候，内存够用，不发生缺页，所有的page全部进入page cache。
读后一半文件的时候，每次都产生缺页，回收一部分旧的page，新页补充到page cache。
全部读结束之后，前半部分的page全部回收，系统保留最后一半的page cache。

回收部分的page一定是从radix_tree里删除了（否则page cache就是整个文件的大小），剩余部分还留在radix_tree里面。

但好像还是不知道该怎么解释lz的20g/70g的问题……

vincentve

回复 6# nswcfd

我擦，我想明白了，预读，预读！！

每次page fault都会带着预读

预读的页面是在缓存中的，但不映射到进程空间中，这应该就是20g/70g的由来

下午我再做几个实验证实一下