我正在编写一个大量使用 mmap 的应用程序，包括来自不同的进程（不是同时发生，而是串行发送） . 性能的一个重要决定因素是TLB如何管理这些映射的用户和内核端 .
我理解Linux page cache的用户可见方面 . 我认为这种理解延伸到用户地带的性能影响1 .
我不明白的是这些页面是如何映射到内核空间的，以及它如何与TLB交互（在x86-64上） . 您可以在32位x86 world2中找到有关它如何工作的大量信息，但我没有找到64位的答案 .
所以这两个问题（相互关联，可能一次性回答）：
-
如何在x86-64的内核空间中映射页面缓存3？
-
如果你在某个进程中从一个文件中找到N页，那么再次从同一个CPU上的另一个进程再次读取那些N页，可能是所有内核端读取（在内核期间 - >内容的用户空间副本）命中在TLB？请注意，这（可能）是（1）的直接后果 .
我的总体目标是深入了解通过 mmap 或非 mmap 调用（如 read ）一次性访问缓存文件的性能差异 .
1例如，如果您将 mmap 文件放入页面缓存中的进程' virtual address space, you have effectively asked for your process page tables to contain a mapping from the returned/requested virual address range to a physical range corresponding to the pages for that file in the page cache (even if they don'中） . 如果指定了 MAP_POPULATE ，则在 mmap 调用返回之前将实际填充所有页表条目，如果不是，则会在关联页面中填充错误（有时使用fault-around等优化） .
2基本上，（对于3：1映射）Linux使用单个1 GB页面直接映射大约前1 GB的物理RAM（并将其置于虚拟内存的前1 GB），这是故事的结尾 . 内存<= 1 GB的机器（页面缓存必须在1GB映射中，因此单个1 GB TLB条目涵盖所有内容） . 对于超过1GB的RAM，页面缓存优先从"HIGHMEM"分配 - 1GB以上的区域，即1GB映射，因此使用了各种temporary mapping策略 .
3通过映射我的意思是如何为其访问设置页表，也就是虚拟< - >物理映射如何工作 .
1 回答
由于与安装的物理ram（内核为128TB）相比存在巨大的虚拟地址空间，因此常见的技巧是永久映射所有ram . 这被称为“直接 Map ” .
原则上，相关的TLB和缓存条目都可能在上下文切换和所有其他代码执行后仍然存在，但很难说这在现实世界中有多大可能 .