shm_open 是否提交固定数量的物理内存？
Does shm_open commit a fixed amount of physical memory?
我的一个朋友正在为内存受限的 Linux 系统开发一个库。他提议使用 shm_open 为用户计算机上多个不同程序之间的进程间通信分配多个合理大小 (16MB) 的内存。
出现的问题是，如果分配了很多缓冲区（比如 128 个），那么 128 × 16MB 可能是可用系统内存的一个重要部分，而且很可能没有太多保留的内存实际上会被使用。例如，如果每个缓冲区中只有 128K 的内存实际用于任何事情，这种方法将使用大约 1/128 的保留内存。由于预期的访问模式，很可能每个缓冲区中只有一小部分区域在任何给定时间会“热”。
我查阅了 shm_open 的手册页，其中特别提到在 Linux 上，实现使用 tmpfs 分配内存。 tmpfs 的手册页反过来说，如果机器上有物理内存压力，分配的内存可以调出。它还说只分配 space 来存储文件系统的已用内容。
通过阅读本文，我假设以下内容是正确的：
使用shm_open分配16MB的space不一定会立即消耗机器上的16MB物理内存，因为大部分文件系统都是零页， OS 将延迟分配。使用的space将与写入的数据量成正比。
如果机器上剩下的物理 RAM 很少，OS 被允许从共享内存缓冲区调出部分。此外，如果在任何时候只有缓冲区的某些部分将被访问，那么假设这些区域——可能不是其他区域——将在给定时间被分页并不是不合理的。
这些假设合理吗？这是原则上可以根据经验进行测试的东西，但担心的是我们会陷入“是的，这在你的系统上有效，但其他 Linux 安装通常不是这样的问题。”
用户模式应用程序通常可以保留物理内存的唯一方法是使用 mlock 系列系统调用；该进程必须具有 CAP_IPC_LOCK 特权，或者它们被限制为 RLIMIT_MEMLOCK 字节。
可以使用 mlock() 将共享内存锁定到 RAM 中，但它不会自动完成，也没有理由需要这样做。它只是共享虚拟内存。
我的一个朋友正在为内存受限的 Linux 系统开发一个库。他提议使用 shm_open 为用户计算机上多个不同程序之间的进程间通信分配多个合理大小 (16MB) 的内存。
出现的问题是，如果分配了很多缓冲区（比如 128 个），那么 128 × 16MB 可能是可用系统内存的一个重要部分，而且很可能没有太多保留的内存实际上会被使用。例如，如果每个缓冲区中只有 128K 的内存实际用于任何事情，这种方法将使用大约 1/128 的保留内存。由于预期的访问模式，很可能每个缓冲区中只有一小部分区域在任何给定时间会“热”。
我查阅了 shm_open 的手册页，其中特别提到在 Linux 上，实现使用 tmpfs 分配内存。 tmpfs 的手册页反过来说，如果机器上有物理内存压力，分配的内存可以调出。它还说只分配 space 来存储文件系统的已用内容。
通过阅读本文，我假设以下内容是正确的：
使用
shm_open分配16MB的space不一定会立即消耗机器上的16MB物理内存，因为大部分文件系统都是零页， OS 将延迟分配。使用的space将与写入的数据量成正比。如果机器上剩下的物理 RAM 很少，OS 被允许从共享内存缓冲区调出部分。此外，如果在任何时候只有缓冲区的某些部分将被访问，那么假设这些区域——可能不是其他区域——将在给定时间被分页并不是不合理的。
这些假设合理吗？这是原则上可以根据经验进行测试的东西，但担心的是我们会陷入“是的，这在你的系统上有效，但其他 Linux 安装通常不是这样的问题。”
用户模式应用程序通常可以保留物理内存的唯一方法是使用 mlock 系列系统调用；该进程必须具有 CAP_IPC_LOCK 特权，或者它们被限制为 RLIMIT_MEMLOCK 字节。
可以使用 mlock() 将共享内存锁定到 RAM 中，但它不会自动完成，也没有理由需要这样做。它只是共享虚拟内存。