为什么 Linux (x86) 的页面大小是 4 KB，这是如何计算的？

Why is the page size of Linux (x86) 4 KB, how is that calculated?

提问by daisy

The default memory page size of the Linux kernel on x86 architecture was 4 KB, I wonder how was that calculated, and why ?

x86 架构上 Linux 内核的默认内存页面大小是 4 KB，我想知道这是如何计算的，为什么？

采纳答案by Hristo Iliev

The default page size is fixed by what the MMU (memory management unit) of the CPU supports. In 32-bit protected mode x86 supports two kinds of pages:

默认页面大小由 CPU 的 MMU（内存管理单元）支持的内容决定。在 32 位保护模式下，x86 支持两种页面：

• normal ones, 4 KiB
• huge ones, 4 MiB

• 普通的，4 KiB
• 巨大的，4 MiB

Not all x86 processors support large pages. One needs to have a CPU with Page Size Extension (PSE) capabilities. This excludes pre-Pentium processors. Virtually all current-generation x86 CPUs implements it.

并非所有 x86 处理器都支持大页面。需要有一个具有页面大小扩展 (PSE) 功能的 CPU。这不包括前奔腾处理器。几乎所有当前的 x86 CPU 都实现了它。

4 KiB is widely popuplar page granularity in other architectures too. One could argue that this size comes from the division of a 32-bit virutal address into two 10-bit indexes in page directories/tables and the remaining 12 bits give the 4 KiB page size.

4 KiB 也是其他架构中广泛流行的页面粒度。有人可能会争辩说，这个大小来自将 32 位虚拟地址划分为页目录/表中的两个 10 位索引，其余 12 位给出了 4 KiB 的页面大小。

回答by Daniel Lopez

I got this from the wikipedia article and I quote:

我从维基百科文章中得到了这个，我引用了：

Page size is usually determined by processor architecture

页大小通常由处理器架构决定

Check out the article below:

看看下面的文章：

http://en.wikipedia.org/wiki/Page_(computer_memory)

http://en.wikipedia.org/wiki/Page_(computer_memory)

回答by Frédéric Hamidi

That depends on the processor architecture.

这取决于处理器架构。

The default page size is 4 KB on many architectures. It can generally be increased (sometimes a lot, such as AMD64's 1 GB) by switching to huge pagemode. This allows the page table to be smaller, which can result in performance improvements.

许多体系结构上的默认页面大小为 4 KB。通常可以通过切换到大页面模式来增加（有时很多，例如 AMD64 的 1 GB）。这允许页表更小，从而可以提高性能。

回答by sleepsort

The design of 4KB normal page size of 32-bit architecture is actually very interesting :)

32位架构的4KB普通页面大小的设计其实很有意思：）

And I'd like to add an extra answer to demonstrate why it is reasonable.

我想添加一个额外的答案来证明为什么它是合理的。

x86 uses '2 level page table' to translate virtual memory addresses into physical memory addresses.

x86 使用“2 级页表”将虚拟内存地址转换为物理内存地址。

So assume that both page directory and page table contain entries, and the page size is bytes. To make full use of the address, we have:

因此假设页目录和页表都包含条目，并且页大小为字节。为了充分利用地址，我们有：

Each entry in page directory/table consumes 4 bytes (32-bit), therefore:

页目录/表中的每个条目消耗 4 个字节（32 位），因此：

Thus y = 12, and page size in bytes will be = = 4KB.

因此 y = 12，页面大小（以字节为单位）将为= = 4KB。

---

---

And what about '1 level page table'? This is interesting because logically we can use a single page table for address lookup.

那么“1级页表”呢？这很有趣，因为从逻辑上讲，我们可以使用单个页表进行地址查找。

Assume that the page directory contains entries, each mapping an address to corresponding page, and page size is bytes.

假设页目录包含条目，每个条目映射一个地址到对应的页，页大小为字节。

Again, to make full use of addresses, we need:

同样，为了充分利用地址，我们需要：

And:

和：

We get y = 17, and page size is = = 128KB.

我们得到 y = 17，页面大小是= = 128KB。

---

---

We might also argue that, in '2 level page table' version, page directory and page table might have different sizes. However, this means we'll be using larger page directory, which will occupy more than one memory page. Sadly, every time a new user process is spawned, for its own page directory, OS has to allocate successive pages, which is not elegant by design.

我们也可能会争辩说，在“2 级页表”版本中，页目录和页表可能具有不同的大小。然而，这意味着我们将使用更大的页面目录，这将占用多个内存页面。可悲的是，每次产生一个新的用户进程时，操作系统必须为其自己的页面目录分配连续的页面，这在设计上并不优雅。

回答by Agguro

I add this answer/comment because the calculation of sleepsort is very interesting, I have to add it to my webpage (with mentioning the source of course). An (possible) answer to the question how you can calculate the pagesize programmatically can be found here. The way it is calculated as mentioned by sleepsort is very interesting. I did the same for x86_64 and the result wasn't what I expected. However further reading on memory management x86_64I found that for 64 bit intel, 16 bits are not used, leave it 48 bits for us to calculate. 9 bits for the memory tree branches, each branch another 9 bits, here in another 9 for branches and finally 9 bits for the leaves of the last branch. So 48 - 36 = 12 bits for each address in the memory page. 2^12 = 4096 like mentioned before by sleepsort. I just wonder how many pass this architecture is, 3 or 4 (if anyone can explain that) following sleepsort's calculation:

我添加这个答案/评论是因为 sleepsort 的计算很有趣，我必须将它添加到我的网页中（当然要提到来源）。可以在此处找到对如何以编程方式计算页面大小的问题的（可能）答案。sleepsort 提到的计算方式非常有趣。我对 x86_64 做了同样的事情，结果出乎我的意料。然而进一步阅读内存管理 x86_64我发现对于64位的intel，没有使用16位，留48位给我们计算。9 位用于存储树分支，每个分支另外 9 位，这里另外 9 位用于分支，最后 9 位用于最后一个分支的叶子。所以 48 - 36 = 12 位用于内存页中的每个地址。2^12 = 4096 就像之前sleepsort 提到的那样。我只是想知道按照 sleepsort 的计算，这个架构有多少遍，3 或 4（如果有人能解释的话）：

2^x * 2^x * 2^x * 2^x * 2^y = 2^48
4x + y = 48

this time we have 8 bytes for each address (8 bytes * 8 bits / byte = 64 bits)

2^y / 2^3 = 2^x
y - 3 = x
filled in in previous equation:

4(y - 3) + y = 48
4y - 12 + y = 48
5y = 60
y = 12
because 2^y represents the pagesize, the size = 2^12 = 4096 bytes

Leave me with the question "what about those huge pages in Linux"?

留给我的问题是“Linux 中的那些大页面怎么样”？

回答by Hadi Brais

Introduction

介绍

The first Intel processor that supported the paging virtual memory technique was the Intel 80386. The processor supported a single page size, 4 KB. Since it was released in 1985, we have to go back to that period of time to understand why Intel chose that particular page size.

第一个支持分页虚拟内存技术的英特尔处理器是英特尔 80386。处理器支持单页大小，4 KB。自从它于 1985 年发布以来，我们必须回到那段时间来了解英特尔为什么选择这种特定的页面大小。

Atlaswas the first computer to support paging with a page size of 3 KB and it had a profound influence on the design of virtual memory and motivated related research. The system was designed between 1958-1962. It's interesting to note that the page size supported by the 80386 is somewhat close to the page size supported by the Atlas, even though the 80386 was designed about 20 years later and computers (and the workloads they ran) have evolved radically during that period of time! In fact, many computers from that period used page sizes that range between 0.5-5 KB. Researchers at that time actually spent a substantial amount of effort studying virtual memory systems (paging and segmentation).

Atlas是第一台支持页面大小为 3 KB 的分页的计算机，它对虚拟内存的设计和相关研究产生了深远的影响。该系统是在 1958-1962 年间设计的。有趣的是，80386 支持的页面大小与 Atlas 支持的页面大小有些接近，尽管 80386 是在大约 20 年后设计的，并且计算机（以及它们运行的​​工作负载）在那个时期发生了根本性的发展。时间！事实上，那个时期的许多计算机使用的页面大小范围在 0.5-5 KB 之间。当时的研究人员实际上花了大量精力研究虚拟内存系统（分页和分段）。

One of the big questions was: What is the optimal page size? A large number of works were published in the 60s and 70s that attempt to study and understand the impact of the page size on the performance of applications and recommend or provide guidelines on how to choose a page size. There are certainly a number of papers that were never published. As far as I know, this includes the document from Intel that says "... Therefore, the page size should be 4 KB." But the factors that influence or interact with the page size and the process of choosing a page size (or multiple page sizes for that matter) are well known, which is what I'll discuss in this answer at a basic level. I'll also explain in particular why a page size of 4 KB is reasonable.

最大的问题之一是：最佳页面大小是多少？60 年代和 70 年代发表了大量作品，试图研究和理解页面大小对应用程序性能的影响，并就如何选择页面大小提出建议或提供指导。肯定有一些论文从未发表过。据我所知，这包括来自 Intel 的文档，上面写着“......因此，页面大小应该是 4 KB”。但是，影响页面大小或与之交互的因素以及选择页面大小（或多个页面大小）的过程是众所周知的，这就是我将在此答案中从基本层面讨论的内容。我还将特别解释为什么 4 KB 的页面大小是合理的。

The Page Size Problem

页面大小问题

In the paging method, physical memory is organized as a sequence of contiguous regions of memory, called page frames, that are of the same size (which is the defining characteristic of paging¹). Each page frame can be mapped to equally-sized chunk of a virtual address space, called a virtual page.

在分页方法中，物理内存被组织为一系列连续的内存区域，称为页框，它们具有相同的大小（这是分页¹的定义特征）。每个页框都可以映射到虚拟地址空间的相同大小的块，称为虚拟页。

Suppose that a page consists of Nbytes²(which implies that a page frame is also Nbytes in size by definition) and consider a virtual address space that consists of Ppages (i.e., the page numbers are {0, 1, 2, ..., P- 1} and the total number of virtual addresses is N* P). Suppose also that the physical address space consists of Fpage frames (i.e., the page frame numbers are {0, 1, 2, ..., F- 1} and the total number of physical addresses is N* F).

假设一个页面由N字节²组成（这意味着N根据定义，页面帧的大小也是字节），并考虑一个由P页面组成的虚拟地址空间（即，页码为 {0, 1, 2, ... , P- 1} 且虚拟地址总数为N* P)。还假设物理地址空间由F页框组成（即，页框编号为 ​​{0, 1, 2, ..., F- 1} 并且物理地址的总数为N* F）。

Given a virtual address VA, a mechanism (a mapping device) is required to determine the physical address, PA, it is mapped to or a page fault should be raised in case it was not mapped. The mapping device uses a data structure (the page table) stored somewhere to perform the mapping. There should be an entry in that table for each allocated virtual page that describes how the page is mapped and potentially some additional attributes (such as protection attributes). The design of the page table entry, as you'll see, interacts with the page size. I'll discuss the design of the page table entry in the Intel 80386 later.

给定一个虚拟地址VA，需要一种机制（映射设备）来确定物理地址PA，它被映射到，或者在它没有被映射的情况下应该引发页面错误。映射设备使用存储在某处的数据结构（页表）来执行映射。对于每个分配的虚拟页面，该表中应该有一个条目，描述页面是如何映射的，以及一些可能的附加属性（例如保护属性）。正如您将看到的，页表条目的设计与页面大小相互作用。稍后我将讨论 Intel 80386 中页表条目的设计。

The size of a virtual address is log₂(N* P) and the size of a physical address is log₂(N* F). Some bits of VAwould represent the offset within the page while the other bits would represent the page number, which identifies the page using the mapping device.

虚拟地址的大小为 log ₂( N* P)，物理地址的大小为 log ₂( N* F)。的一些位VA将代表页面内的偏移量，而其他位将代表页面编号，它使用映射设备标识页面。

How many options do we have for the page size? Well, it can be as a little as one byte up to N* Por N* F, whichever is smaller. That's a lot of options.

对于页面大小，我们有多少种选择？好吧，它可以是一个字节，最多为N*P或N* F，以较小者为准。这是很多选择。

It is Convenient for The Page Size to be a Power of 2

页面大小为 2 的幂很方便

A virtual address, VA, is equivalent to a pair of page number and offset, (PN, OFF). The translation process should be as efficient as possible. It's convenient for programmers³to have the bytes within a page to be contiguous in the address space. In this way, the addresses of the items within a multi-byte data structure can be calculated with simple arithmetic on a single address, which would constitute the base address of the data structure. This can be achieved by using the least significant log₂(N) bits (rounded up) of a virtual address to represent the offset and the rest of the bits to represent the page number.

一个虚拟地址，VA，相当于一对页号和偏移量， ( PN, OFF)。翻译过程应尽可能高效。对于程序员^{3 来说}，让页面中的字节在地址空间中是连续的是很方便的。这样，多字节数据结构中的项的地址可以通过对单个地址的简单算术来计算，这将构成数据结构的基地址。这可以通过使用虚拟地址的最低有效日志₂( N) 位（向上取整）来表示偏移量和其余位来表示页码来实现。

If Nis not power of 2, there will be some bits that are shared between the offset and page number, depending on the values of these bits. By making Na power of 2, such complication does not exist. So it would neat to use page sizes that are a power of 2. All real processors that support paging use page sizes that are power of two (although the unit of addressability may not be 8 bits), which makes sense. But to be honest, it's not clear whether this really matters. Using today's technology, whether Nis a power of 2 may not have any measurable impact on performance or any other metric of interest. In fact, in the future as larger and larger page sizes are needed, it may happen that some page size that is not a power of 2 is better. But so far, this has not happened. The point I'm trying to make here is that the design option of making the page size not a power 2 should not be automatically dismissed. I believe this is a good opportunity of research in future virtual memory systems.

如果N不是 2 的幂，则偏移量和页码之间将共享一些位，具体取决于这些位的值。通过使N2 的幂，这种复杂性不存在。所以最好使用 2 的幂的页面大小。所有支持分页的实际处理器都使用 2 的幂的页面大小（尽管可寻址单位可能不是 8 位），这是有道理的。但说实话，目前还不清楚这是否真的很重要。使用当今的技术，无论N是 2 的幂可能不会对性能或任何其他感兴趣的指标产生任何可衡量的影响。事实上，将来随着需要越来越大的页面大小，可能会出现一些不是 2 的幂的页面大小更好。但到目前为止，这还没有发生。我想在这里说明的一点是，不应自动取消使页面大小不是 2 次幂的设计选项。我相信这是一个很好的研究未来虚拟内存系统的机会。

Anyway, keeping in mind that the choice of 4 KB pages was made in the 80s, such extremely small variations in page sizes were shown (both theoretically and experimentally) to be of little importance. So the convenience of power-of-2 page sizes triumphed. This reduces the number of page sizes to consider exponentially. But we still have a good range of options.

无论如何，请记住 4 KB 页面的选择是在 80 年代进行的，因此页面大小的这种极小的变化（理论上和实验上）显示出无关紧要。因此，2 次幂页面大小的便利性大获全胜。这以指数方式减少了要考虑的页面大小的数量。但我们仍然有很多选择。

Favoring Smaller Page Sizes

支持较小的页面大小

Since the mapping device works at the level of pages, the unit of allocation from the perspective of the operating system is a virtual page⁴. Even if an application needs to only allocate 1 byte, it still has to tell the OS to allocate a whole virtual page for that 1 byte. This issue is called internal fragmentation. Each application (or maybe even each component of an application) has its own virtual address space from which it allocates memory in page-size chunks. It's expected from each application to not use a single page for a single object that it allocates, but rather allocate as many objects as possible from the same page before it allocates more pages. However, because page attributes work at the level of pages, the same application may use multiple user-mode memory managers (such as when using multiple C/C++ runtimes), and it's difficult for application to share parts of the pages they are not using with other applications, internal fragmentation can occur in many pages in the system. Using smaller page sizes can help reduce the amount of wasted physical (for the whole system) and virtual (per process) memory.

由于映射设备工作在页级别，因此从操作系统的角度来看，分配单元是虚拟页⁴。即使应用程序只需要分配 1 个字节，它仍然必须告诉操作系统为那 1 个字节分配整个虚拟页面。这个问题叫做内部碎片. 每个应用程序（或什至可能是应用程序的每个组件）都有自己的虚拟地址空间，它从中以页面大小的块分配内存。期望每个应用程序不会为它分配的单个对象使用单个页面，而是在分配更多页面之前从同一页面分配尽可能多的对象。但是，由于页面属性在页面级别起作用，因此同一个应用程序可能会使用多个用户模式内存管理器（例如在使用多个 C/C++ 运行时时），并且应用程序很难共享它们不使用的页面部分对于其他应用程序，系统中的许多页面可能会出现内部碎片。使用较小的页面大小有助于减少浪费的物理（整个系统）和虚拟（每个进程）内存量。

In addition, typically applications go through a number of phases throughout their lifetime, where they exhibit different memory requirements in different phases. If the page size is, say, 16 KB, but many applications may require only less 10 KB for many of their phases, then there would be a lot of wasted physical memory, which may lead to out-of-memory situations that could have been avoided if smaller page sizes, such as 8 or 4 KB, were supported.

此外，应用程序在其整个生命周期中通常会经历多个阶段，在这些阶段它们在不同阶段表现出不同的内存需求。如果页面大小为 16 KB，但许多应用程序的许多阶段可能只需要不到 10 KB，那么就会浪费大量的物理内存，这可能会导致内存不足的情况，这可能会导致如果支持较小的页面大小（例如 8 或 4 KB），则可以避免这种情况。

Smaller page sizes are preferable for handling copy-on-write soft page faults because the smaller the page is, it would take less time to create a copy of it. For extremely small page sizes, this may not make any measurable difference, depending on the memory bus bandwidth.

较小的页面大小更适合处理写时复制软页面错误，因为页面越小，创建它的副本所需的时间就越少。对于极小的页面大小，这可能不会产生任何可测量的差异，具体取决于内存总线带宽。

Typical amounts of physical memory available in computers in the 70s were in the range of 10s or 100s of KBs. It wouldn't make sense to have page sizes of hundreds of KBs or larger. In fact, the working sets of applications at that time were typically only few or tens of KBs. So even page sizes as small as 16 KB are unlikely to be practical because only a couple of pages may consume all of the available physical memory. The page size should be coherent with the amount of physical memory. This argument can be applied to today's systems of course (it wouldn't make sense to have 128-GB pages for example).

70 年代计算机中可用的典型物理内存量在 10 或 100 KB 的范围内。拥有数百 KB 或更大的页面大小是没有意义的。事实上，当时应用程序的工作集通常只有几 KB 或几十 KB。因此，即使页面大小小至 16 KB 也不可能实用，因为只有几个页面可能会消耗所有可用的物理内存。页大小应与物理内存量一致。这个论点当然可以应用于今天的系统（例如，拥有 128-GB 的页面是没有意义的）。

So considering working set sizes and physical memory availability of the 70s and early 80s, the page size should be a power of 2 in the range 2⁰-2¹⁴. Cool, now we have only 15 options to choose from.

因此，考虑到70 年代和 80 年代初期的工作集大小和物理内存可用性，页面大小应该是 2 ⁰-2 ¹⁴范围内的 2 的幂。很酷，现在我们只有 15 个选项可供选择。

Favoring Larger Page Sizes

支持更大的页面尺寸

We can also argue that larger page sizes are better. For the same working set, smaller page sizes imply a larger number of pages per application , which would require page table entries to enable translation. This fundamentally requires larger page tables irrespective of the structure of the page tables (although the exact overhead depends on the design of the page table entry itself, which I'll discuss later). Imagine having for example 4-byte pages and typical working sets of tens of KBs. Then most of the physical memory would actually be allocated to hold the page tables, not the data. Paging out page tables to seconding storage leads to double page faults for individual memory references, which would be absolutely terrible for performance. Such design is obviously ridiculous.

我们也可以说页面越大越好。对于相同的工作集，较小的页面大小意味着每个应用程序有更多的页面，这将需要页表条目来启用转换。无论页表的结构如何，这从根本上都需要更大的页表（尽管确切的开销取决于页表条目本身的设计，我将在后面讨论）。想象一下，例如有 4 字节的页面和数十 KB 的典型工作集。然后大部分物理内存实际上会被分配来保存页表，而不是数据。将页表分页到辅助存储会导致单个内存引用的双页错误，这对性能来说绝对是糟糕的。这样的设计显然是荒谬的。

Essentially, the page size shouldn't be (much) smaller than the smallest possible working set size that can possibly ever be. This immediately rules out pages of sizes 2⁰-2⁶, leaving for us 8 options. The papers of the 70s and early 80s that study page sizes mostly study only these 8 options.

本质上，页面大小不应（远）小于可能的最小工作集大小。这立即排除了大小为 2 ⁰-2 ^{6 的}页面，为我们留下了 8 个选项。70 年代和 80 年代初研究页面大小的论文大多只研究这 8 个选项。

There is another reason that makes larger page sizes advantageous. One of the benefits of virtual memory is to be able to transparently use secondary storage in addition to main memory to hold volatile data. However, secondary storage devices are mechanical and perform best with bulk transfers. This is more of a guideline really and we should not rule out any page sizes yet. There are devices with different designs and characteristics and eventually, the performance advantage of bulk transfers will saturate at some point. But it's certainly something to take into account when measuring the impact of page sizes on performance. If the type of applications being considered exhibit little spatial locality, then smaller page sizes would still be preferable because copying extra bytes to or from the disk is not exactly for free.

还有另一个原因使较大的页面尺寸具有优势。虚拟内存的好处之一是能够透明地使用除主内存之外的辅助存储来保存易失性数据。但是，辅助存储设备是机械的，在批量传输时性能最佳。这实际上更像是一个指导方针，我们不应该排除任何页面大小。存在具有不同设计和特性的设备，最终，批量传输的性能优势将在某个时候饱和。但在衡量页面大小对性能的影响时，这肯定是需要考虑的。如果所考虑的应用程序类型表现出很小的空间局部性，那么较小的页面大小仍然是可取的，因为将额外的字节复制到磁盘或从磁盘复制并不是完全免费的。

Spatial locality of reference encourages the use of certain page sizes. For very small page sizes, it's highly likely that all bytes in the page will be used in the a small period of time. As the size of a page gets larger, the number of bytes that are less likely to be used increases. However, for very large pages, all of the working set may fit within a small number of pages irrespective of locality. Therefore, to minimize the number of page faults, the page size should be either too small or too larger, but not in between. But ultimately, this varies from one application to another. Emerging programming paradigms, such as object-oriented programming and functional programming, and techniques such as multithreading may actually reduce spatial locality due to the extensive use of linked structures and due to the way different application interact with each other. Larger page sizes are preferable to reduce the number of page faults. However, smaller page sizes might be better for memory shared between multiple applications to reduce internal fragmentation of the shared pages. It has also been shown experimentally that the number of page frames that can be held in main memory is correlated with the number of page faults, favoring smaller page sizes.

参考的空间局部性鼓励使用某些页面大小。对于非常小的页面大小，页面中的所有字节很可能会在一小段时间内被使用。随着页面的大小变大，不太可能使用的字节数会增加。然而，对于非常大的页面，所有的工作集都可能适合少量的页面，而不管位置如何。因此，为了尽量减少页面错误的数量，页面大小应该太小或太大，但不能介于两者之间。但最终，这因一个应用程序而异。新兴的编程范式，例如面向对象编程和函数式编程，由于链接结构的广泛使用以及不同应用程序之间的交互方式，多线程等技术实际上可能会降低空间局部性。较大的页面大小有利于减少页面错误的数量。但是，较小的页面大小可能更适合在多个应用程序之间共享的内存，以减少共享页面的内部碎片。实验还表明，可以保存在主内存中的页框数量与页面错误数量相关，有利于较小的页面大小。

The need for TLBs was well recognized at that time. Intel called them page cachesin their patents (not sure whether Intel was first to use that term). Fast TLBs are very important because address translation is on the critical path of executing instructions. To make them as fast as possible, they should be made tiny, but then they can only cache a small number of page table entries. This motivates the use of larger page sizes.

当时人们已经充分认识到对 TLB 的需求。英特尔在他们的专利中称它们为页面缓存（不确定英特尔是否首先使用该术语）。快速 TLB 非常重要，因为地址转换是执行指令的关键路径。为了使它们尽可能快，它们应该很小，但是它们只能缓存少量的页表条目。这促使使用更大的页面尺寸。

In the search for the optimal page size, it turns out that there isn't one. It was known at that time that there is a need for supporting multiple page sizes. In fact, the Multics system designed in 1965 supported 64- or 1,024-word pages (a word is 36 bits in size). Page sizes in the range 2⁷-2¹⁴were shown to be optimal both empirically and theoretically in different scenarios. Intel must have observed that 4-KB pages result in the best average performance for the applications that their customers used in the 80s.For today's computers and applications, such tiny differences in page sizes don't make much difference as it used to be in the 70s and 80s.

在寻找最佳页面大小的过程中，结果是没有。当时就知道需要支持多种页面大小。事实上，1965 年设计的 Multics 系统支持 64 或 1,024 字的页面（一个字的大小为 36 位）。2 ⁷-2 ¹⁴范围内的页面大小在不同场景中被证明在经验和理论上都是最佳的。英特尔肯定已经观察到，对于 80 年代他们的客户使用的应用程序，4 KB 页面会带来最佳的平均性能。对于今天的计算机和应用程序，页面大小的这种微小差异并没有像过去 70 年代和 80 年代那样产生太大差异。

The Design of the Page Table Entry of the Intel 80386

Intel 80386页表项的设计

The design of the page directory entry and page table entry is discussed in detail in an Intel patent. This is important because the size of the page table entry and the overall structure of the page table were taken into account in many studies about the page size because they all interact with each other. I prefer not to discuss this in more detail to keep the answer short.

页目录项和页表项的设计在英特尔的专利中有详细讨论。这很重要，因为在许多关于页大小的研究中都考虑了页表条目的大小和页表的整体结构，因为它们都相互影响。我不想更详细地讨论这个问题，以保持答案简短。

The Page Size of the Near Future

近期页面大小

Intel has been granted a patenta couple of months ago that apparently proposes a system with a default page size of 64 KB, but at the same time supporting 4 KB pages (and other IA-32e page sizes) for backward compatibility. I quote from the patent:

英特尔在几个月前获得了一项专利，该专利显然提出了一种默认页面大小为 64 KB 的系统，但同时支持 4 KB 页面（和其他 IA-32e 页面大小）以实现向后兼容性。我引用专利：

As a result of support of the mapping of the 64 KB page into 4 KB subpages, VA64 directly supports all currently defined operations on 4 KB pages, including independent protection bits per 4 KB page and arbitrary 4 KB-aligned address mappings. VA64 also supports OS kernel page management on 4 KB boundaries, even when the OS kernel allocates memory in 64 KB units. As a result of support of large pages, VA64 supports all divisions of the virtual address range into pages that an existing paging system such as Intel Corporation's IA-32e paging system supports. Therefore, VA64 supports applications and hardware devices that work with a 4 KB-page Windows? OS kernel, while also taking full advantage of 64 KB pages when 64 KB pages can be used.

The capabilities of VA64 can be adopted gradually by the OS kernel, rather than requiring them all to be supported in the first generation VA64-capable OS kernel. For example, a VA64-capable OS kernel could start by mapping all pages to current sizes (e.g., 4 KB/2 GB/1 TB in Intel Corporation's IA-32e paging system), but changing to a new page table format. After the change in page table format, the OS kernel could be modified to map virtual memory in 64 KB units and change to store 64 KB pages in its free list. Then the OS kernel could start using 64 KB pages whenever alignment and protections permit, and add support for other VA64 capabilities.

由于支持将 64 KB 页面映射到 4 KB 子页面，VA64 直接支持所有当前定义的 4 KB 页面上的操作，包括每 4 KB 页面的独立保护位和任意 4 KB 对齐的地址映射。VA64 还支持 4 KB 边界上的 OS 内核页面管理，即使 OS 内核以 64 KB 为单位分配内存。由于支持大页面，VA64 支持将虚拟地址范围的所有划分为现有分页系统（如英特尔公司的 IA-32e 分页系统）支持的页面。因此，VA64 支持使用 4 KB 页的 Windows 的应用程序和硬件设备？OS 内核，同时在可以使用 64 KB 页面时也充分利用了 64 KB 页面。

VA64 的能力可以逐渐被操作系统内核采用，而不是要求它们在第一代支持 VA64 的操作系统内核中都得到支持。例如，支持 VA64 的操作系统内核可以首先将所有页面映射到当前大小（例如，英特尔公司 IA-32e 分页系统中的 4 KB/2 GB/1 TB），但更改为新的页表格式。页表格式改变后，操作系统内核可以修改为以 64 KB 为单位映射虚拟内存，并更改为在其空闲列表中存储 64 KB 页面。然后，只要对齐和保护允许，操作系统内核就可以开始使用 64 KB 页面，并添加对其他 VA64 功能的支持。

I don't know anything else about the VA64 paging system other than what's written in the patent. There is nothing on it anywhere on the Internet. I guess we'll find out more soon.

除了专利中写的内容之外，我对 VA64 寻呼系统一无所知。互联网上的任何地方都没有任何内容。我想我们很快就会发现更多。

Selected References

精选参考文献

Denning, P.J. (1970). Virtual memory. ACM Computing Surveys Volume 2 Issue 3, 153-189.

丹宁，PJ（1970 年）。虚拟内存。ACM 计算调查第 2 卷第 3 期，153-189。

Gelenbe, E., Tiberio, P., & Boekhorst, J. C. A. (1973). Page size in demand-paging systems. Acta Informatica, 3(1), 1-23.

Gelenbe, E., Tiberio, P., & Boekhorst, JCA (1973)。请求分页系统中的页面大小。信息学报，3（1），1-23。

Alanko, T. O., & Verkamo, A. I. (1983). Segmentation, paging and optimal page sizes in virtual memory. Performance Evaluation, 3(1), 13-33.

Alanko, TO, & Verkamo, AI (1983)。虚拟内存中的分段、分页和最佳页面大小。绩效评估，3（1），13-33。

Corbató, F. J., & Vyssotsky, V. A. (1965). Introduction and overview of the Multics system. In Proceedings of the November 30--December 1, 1965, fall joint computer conference, part I (pp. 185-196).

Corbató, FJ, & Vyssotsky, VA (1965)。Multics 系统的介绍和概述。在 1965 年 11 月 30 日至 12 月 1 日的会议记录中，秋季联合计算机会议，第一部分（第 185-196 页）。

---

---

Footnotes

脚注

(1) Actually the size of a single virtual page can be multiple of the size of a page frame, but let's not go there.

(1) 实际上单个虚拟页面的大小可以是一个页框大小的倍数，但我们不要去那里。

(2) We can generalize the formulation and use the term "word" to refer to the smallest addressable unit of memory rather than byte, but that is not important here.

(2) 我们可以概括公式并使用术语“字”来指代内存的最小可寻址单位而不是字节，但这在这里并不重要。

(3) Maybe not programmers, depending on the programming language, but compilers, linkers, assemblers, and tools that work with binary code.

(3) 也许不是程序员，这取决于编程语言，而是编译器、链接器、汇编器和使用二进制代码的工具。

(4) It's certainly possible to design a system that supports using paging and nonpaging at the same time, thereby potentially supporting multiple units of allocation, but let's not go there.

(4) 当然可以设计一个同时支持使用分页和非分页的系统，从而潜在地支持多个分配单元，但我们不要去那里。