mmap有多聪明?

use*_*114 3 unix macos mmap linux-kernel

mmap 可用于在进程之间共享只读内存,减少内存占用量:

  1. 进程P1 mmapsa文件,使用映射内存 - >数据加载到RAM中
  2. 处理P2 mmapsa文件,使用映射内存 - > OS重新使用相同的内存

但是这个怎么样:

  1. 处理P1 mmapsa文件,将其加载到内存中,然后退出.
  2. 另一个进程P2 mmap同一个文件,从P1的访问访问仍然很热的内存.

是否从磁盘再次加载数据?即使"mmap count"暂时降至零,操作系统是否足够智能以重新使用虚拟内存?

不同操作系统之间的行为是否不同?(我最感兴趣的是Linux/OS X)

编辑:如果操作系统不够智能 - 如果有一个"后台进程",保持文件mmap编辑它会不会有帮助,所以它永远不会留下至少一个进程的地址空间?

当我mmapmunmap同一个文件连续快速地,可能(但不一定)在同一个过程中时,我当然对性能感兴趣.

编辑2:我看到的答案描述了完全无关紧要的要点.重申一点 - 我是否可以依赖Linux/OS X来重新加载已经驻留在内存中的数据,而不是从mmap内存段中的先前页面命中,即使特定区域不再mmap被任何进程编辑?

Cel*_*ada 7

内存中文件内容的存在与否远远少于mmap系统调用.当您mmap使用文件时,它不一定会将其加载到内存中.当munmap它(或者如果进程退出)时,它不一定丢弃页面.

有许多不同的东西可以触发文件的内容加载到内存中:映射,正常读取,执行它,尝试访问映射到文件的内存.类似地,有不同的东西可能导致文件的内容从内存中删除,主要与操作系统决定它想要内存更重要的东西有关.

在您提问的两个方案中,请考虑在步骤1和步骤2之间插入一个步骤:

  • 1.5.另一个进程分配并使用大量内存 - > mmaped文件从内存中逐出以腾出空间.

在这种情况下,如果文件的内容再次映射并在步骤2中再次使用,则可能必须将其重新加载到内存中.

与:

  • 1.5.没有任何反应 - > mmaped文件的内容在内存中徘徊.

在这种情况下,不需要在步骤2中重新加载文件的内容.

就文件内容的变化而言,您的两种情况没有太大区别.这就像第1.5步那样会产生更重要的差异.

对于不断访问文件的后台进程,以确保它保存在内存中(例如,通过扫描文件然后在循环中休眠很短的时间),这当然会强制文件保留在记忆中.但是你可能最好只让操作系统决定何时驱逐文件以及什么时候不驱逐它.