我想处理由4Kb块组成的文件。
随着情况的发展，我将写更多的数据并映射新零件，取消映射不再需要的零件。
当要映射的文件数据总量约为4Gb时，仅4Kb的map()是否太小？ （即大约1,048,576个单独映射的块）。
我担心，即使进行了很多小的mmap()调用，即使它们完全针对我要使用的确切块，也最终没有效果。同时，它可能比每次更改一个字节都用read() / write()读写这些块更好。
在64位体系结构上不缺少地址空间。除非您的代码也必须在32位体系结构中工作（如今很少见），否则，将整个文件映射一次，并避免多个mmap调用和成千上万个额外的内核对象的开销。通过读写更改，这取决于您所需的语义。参见this answer。
在64位系统上，您应该一次就映射整个文件或至少整个范围，并让操作系统为您处理切入和切出页面。 mmap调用本身确实有一些开销。实际上，x86-64上的用户地址空间类似于128 TiB，因此您应该能够映射1 TiB文件/范围而没有任何问题。
据我所知，即使是覆盖多个连续4kb页面的单个mmap()，也需要内核（以及TLB，MMU ...）来处理与这些页面数量一样多的虚拟/物理关联（这是存储页面的目的；连续的虚拟页面可以映射到非连续的物理页面）。因此，考虑到这些映射页面的用法，一旦通过唯一调用或通过许多mmap()调用进行设置，则性能应该不会有任何差异。但是，每次对mmap()的调用可能都需要一些开销，以便选择要使用的虚拟地址空间的一部分。一个mmap()调用只需要选择一个足够大的虚拟位置即可（如其他答案所述，在64位系统上应该不难），但重复调用将多次暗示这种开销。
因此，如果我必须在64位系统上处理这种情况，我将立即使用大量页面mmap()整个文件，以减轻对TLB的压力。注意，一次映射整个文件并不意味着此时就使用相同数量的物理内存。虚拟/物理内存关联仅在首次访问每个页面时才会发生。