随着 Linux 内核的发展和成熟，更多的用户期待着 Linux 可以运行非常大的系统来处理科学分析应用程序或者甚至海量数据库。这些企业级的应用程序通常需要大量的内存才能好好运行。2.4 Linux 内核有识别相当大数量的内存的功能，但是 2.5 内核发生了很多改变，使其有能力以更有效的方式处理更大量的内存。
在 Linux 内存管理器中，页表保持对进程使用的内存物理页的追踪，它们将虚拟页映射到物理页。这些页中有一些可能不是长时间使用，它们应该被交换出去。不过，在它们可以被交换出去之前，必须找到映射那个页的每一个进程，这样那些进程中相应页的页表条目才可以被更新。在 Linux 2.4 内核中，这是一项令人生畏的任务，因为为了确定某个页是否被某个进程映射，必须遍历每个进程的页表。随着在系统中运行的进程数量的增加，将这些页交换出去的工作量也会增加。
反向映射，或者说是 RMAP，就是为解决此问题而在 2.5 内核中实现的。反向映射提供了一个发现哪些进程正在使用给定的内存物理页的机制。不再是遍历每个进程的页表，内存管理器现在为每一个物理页建立了一个链表，包含了指向当前映射那个页的每一个进程的页表条目（page-table entries, PTE）的指针。这个链表叫做 PTE 链。PTE 链极大地提高了找到那些映射某个页的进程的速度，如图 1 所示。
当然，没有什么是免费的：用反向映射获得性能提高也要付出代价。反向映射最重要、明显的代价是，它带来了一些内存开销。不得不用一些内存来保持对所有那些反向映射的追踪。PTE 链的每一个条目使用 4 个字节来存储指向页表条目的指针，用另外 4 个字节来存储指向链的下一个条目的指针。这些内存必须使用低端内存，而这在 32 位硬件上有点不够用。有时这可以优化到只使用一个条目而不使用链表。这种方法叫做 p页直接方法（page-direct approach）。如果只有一个到这个页的映射，那么可以用一个叫做“direct”的指针来代替链表。只有在某个页只是由一个惟一的进程映射时才可以进行这种优化。如果稍后这个页被另一个进程所映射，它将不得不再去使用 PTE 链。一个标记设置用来告诉内存管理器什么时候这种优化对一个给定的页有效。
反向映射还带来了一些其他的复杂性。当页被一个进程映射时，必须为所有那些页建立反向映射。同样，当一个进程释放对页的映射时，相应的映射也必须都删除掉。这在退出时尤其常见。所有这些操作都必须在锁定情况下进行。对那些执行很多派生和退出的应用程序来说，这可能会非常浪费并且增加很多开销。
尽管有一些折衷，但可以证明反向映射是对 Linux 内存管理器的一个颇有价值的修改。通过这一途径，查找定位映射某个页的进程这一严重瓶颈被最小化为只需要一个简单的操作。当大型应用程序向内核请求大量内存和多个进程共享内存时，反向映射帮助系统继续有效地运行和扩展。当前还有更多对反向映射的改进正在研究中，可能会出现在未来的 Linux 内核版本中。
典型地，内存管理器在 x86 系统上处理的内存页为 4 KB。实际的页大小是与体系结构相关的。对大部分用途来说，内存管理器以这样大小的页来管理内存是最有效的。不过，有一些应用程序要使用特别多的内存。大型数据库就是其中一个常见的例子。由于每个页都要由每个进程映射，必须创建页表条目来将虚拟地址映射到物理地址。如果您的一个进程要使用 4KB 的页来映射 1 GB 内存，这将用到 262,144 个页表条目来保持对那些页的追踪。如果每个页表条目消耗 8 个字节，那些每映射 1 GB 内存需要 2 MB 的开销。这本身就已经是非常可观的开销了，不过，如果有多个进程共享那些内存时，问题会变得更严重。在这种情况下，每个映射到同一块 1 GB 内存的进程将为页表条目付出自己 2 MB 的代价。如果有足够多的进程，内存在开销上的浪费可能会超过应用程序请求使用的内存数量。
解决这一问题的一个方法是使用更大的页。大部分新的处理器都支持至少一个小的和一个大的内存页大小。在 x86 上，大内存页的大小是 4 MB，或者，在物理地址扩展（PAE）打开的系统上是 2 MB。假定在前面的中使用页大小为 4 MB 的大内存页，同样 1 GB 内存只用 256 个页表条目就可以映射，而不需要 262,144 个。这样开销从 2 MB 变为 2,048 个字节。
大内存页的使用还可以通过减少 变换索引缓冲（translation lookaside buffer, TLB）的失败次数来提高性能。TLB 是一种页表的高速缓存，让那些在表中列出的页可以更快地进行虚拟地址到物理地址的转换。大内存页可以用更少的实际页来提供更多的内存，相当于较小的页大小，使用的大内存页越多，就有越多的内存可以通过 TLB 引用。
在 32 位机器上页表通常只可以存储在低端内存中。低端内存只限于物理内存的前 896 MB，同时还要满足内核其余的大部分要求。在应用程序使用了大量进程并映射了大量内存的情况下，低端内存可能很快就不够用了。
现在，在 2.6 内核中有一个配置选项叫做 Highmem PTE，让页表条目可以存放在高端内存中，释放出更多的低端内存区域给那些必须放在这里的其他内核数据结构。作为代价，使用这些页表条目的进程会稍微慢一些。不过，对于那些在大量进程在运行的系统来说，将页表存储到高端内存中可以在低端内存区域挤出更多的内存。
更好的稳定性是 2.6 内存管理器的另一个重要改进。当 2.4 内核发布时，用户几乎马上就开始遇到内存管理相关的稳定性问题。从内存管理对整个系统的影响来看，稳定性是至关重要的。问题大部分已经解决，但是解决方案必须从根本上推翻原来的内存管理器并重写一个简单的多的管理器来取代它。这为 Linux 的发行者改进自己特定发行版本的 Linux 的内存管理器留下了很大的空间。不过，那些改进的另一方面是，在 2.4 中的内存管理部件由于使用的发行版本不同而很不相同。为避免再发生这样的事情，内存管理成为 2.6 中内核开发的最细致的一部分。从很低端的桌面系统到大型的、企业级的、多处理器的系统，新的内存管理代码已经在它们上面都已经进行了测试和优化。
Linux 2.6 内核中内存管理的改进远远不只本文中提到的这些特性。很多变化是细微的，却相当重要。这些变化一起促生了 2.6 内核中的内存管理器，它的设计目标是更高的性能、效率和稳定性。有一些变化，比如 Highmem PTE 和大内存页，目的是减少内存管理带来的开销。其他变化，比如反向映射，提高了某些关键领域的性能。之所以选择这些特别的例子，是因为它们举例说明了 Linux 2.6 内核得到了怎样的调整和增强，以便更好地处理企业级的硬件和应用程序。
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
- Martin Bligh 和 David Hansen 的论文“ ”发表于 2003 Linux Symposium。
- Red Hat 的 Rik van Riel 在 2003 Ottawa Linux Symposium 上一篇名为 的演示文稿中，讨论了虚拟内存子系统的一些缺点，这些缺点导致虚拟内存子系统在拥有许多 GB 内存的机器上不能很好地工作。
- Mel Gorman 给出了对 Linux 虚拟内存管理器的 。这也已经由 Prentice Hall 以 书的形式 出版。
- Kernel/Analysis HOWTO 中有 的一页。
- LWN.net 有一篇关于 的文章，以及另一篇关于 （基于对象的反向映射 VM，这已经融入到 2.5 内核中）的文章。
- 在 IBM Systems Journal 您可以读到很多关于 的文章。
- IBM 提供 。
- IBM 的 Linux Technology Center直接与 Linux 开发社区合作。
- 站点提供整个 IBM 的 Linux 新闻和资料。
- 在 2.6 发布之前，IBM developerWorks 发表的 走向 Linux 2.6 考虑了新内核的一些重要特性，包括新的调度器和 Native Posix Threading Library (NPTL)（ developerWorks，2003 年 9 月）。
- 阅读 测试 Linux 的可靠性（ developerWorks，2003 年 12 月）。
- Paul Larson 还考虑了 2.6 内核的 从 2.4 到 2.6 内核开发中的改进（ developerWorks，2004 年 2 月）。
- 要了解 2.6 内核的迅速发展，请阅读 2.4 和 2.6 上的 Web 服务（ developerWorks，2004 年 2 月）。
- 在 developerWorks Linux 专区 可以找到更多为 Linux 开发者准备的参考资料。
- 在 Developer Bookstore 的 Linux 区上可以找到很多精选的 Linux 书籍。
Paul Larson 为 IBM Linux Technology Center 的 Linux Test 团队工作。过去一年中，他从事的项目包括 Linux 测试项目、2.5/2.6 内核稳定性以及内核代码复盖分析。可以通过 与他联系。
快来添加第一条评论