为什么是在Linux（x86）的4 KB的页面大小，如何实现这计算的？(Why is the pag

x86架构的Linux内核的默认内存页面大小为4 KB，不知怎么着计算的，为什么？

Answer 1:

默认页面大小是由什么CPU的MMU（内存管理单元）支持固定。在32位保护模式的x86支持两种类型的网页：

正常的，的4 KiB
巨大的，4 MIB

并非所有的x86处理器支持大页。一个人需要有页面大小扩展（PSE）功能的CPU。这不包括奔腾预处理器。几乎所有当前一代的x86 CPU实现它。

4 KIB其他架构广泛popuplar页粒度过。人们可以说，这个尺寸来自一个32位的当前虚拟地址划分成在页面目录/表和剩余的12位得到的4 KiB页面大小两个10位的索引。

Answer 2:

32位架构的4KB正常的页面大小的设计实际上是非常有趣:)

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

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

因此，假定这两个页目录和页表包含项，页面大小字节。要充分利用地址，我们有：

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

以字节为单位因此Y = 12，和页大小将 = = 4KB。

而关于“1级页表”什么？这很有趣，因为我们在逻辑上可以使用单一的页表查找地址。

假设页目录包含条目，每个映射的地址对应的页面，并且页面大小是字节。

再次，充分利用地址，我们需要：

和：

我们得到Y = 17，和页面大小 = = 128KB。

我们也可以认为，在“2级页表”版，页目录和页表可能有不同的尺寸。但是，这意味着我们将使用更大的页目录，这将占用一个以上的内存页。可悲的是，每一个新的用户进程产生的时间，为自己的网页目录，操作系统必须分配连续的页面，这是不是设计美观大方。

Answer 3:

这取决于处理器架构。

默认页面大小为4 KB在很多平台上。它通常可以通过切换到增加（有时很多，如AMD64的1 GB）巨大的页面模式。这使页表变得更小，这可能会导致性能改进。

Answer 4:

介绍

该支持寻呼虚拟内存技术，第一英特尔处理器是英特尔公司的80386 。的处理器支持一个单一的页大小，4 KB。因为它是在1985年发布的，我们必须回到那一段时间来理解为什么Intel选择特定页面大小。

阿特拉斯是支持分页与3 KB的页面大小的第一台计算机，它有虚拟内存的设计和动机相关的研究产生了深远的影响。该系统的设计1958 - 1962年之间。这是有趣的是，在80386支持的页面大小是有点接近由阿特拉斯支持的页面大小，即使80386约20年后，设计和计算机（他们跑了工作量）已经在此期间的急剧的变化时间！事实上，从那个时期很多计算机使用的页面大小是0.5-5 KB之间。当时研究人员实际花费的精力大量研究虚拟内存系统（分页和分段）。

其中一个大问题是：什么是最佳的页面大小？大量作品被刊登在试图研究和了解的页面大小对应用程序的性能的影响，并建议或提供关于如何选择一个页面大小的准则60和70年代。当然，还有一些是从未发表的论文。据我所知，这包括来自英特尔，说文件“......因此，页面大小应为4 KB。” 但是因素影响或页面大小和选择页面大小（或多个页面大小为此事）的流程交互是众所周知的，这正是我将在这个答案在基层讨论。我也会特别解释为什么4 KB的页面大小是合理的。

该页面大小问题

在寻呼方法中，物理存储器被组织为连续的内存区域，称为页帧，即具有相同的尺寸（这是寻呼¹的定义的特性）的序列。每一页帧可以被映射到虚拟地址空间的大小相等的块，称为虚拟页。

假设一个页面由N字节^2（这意味着一个页面帧也N字节在由定义尺寸），并认为包括一个虚拟地址空间P页（即，页号码是{0，1，2， ...， P - 1}和虚拟地址的总数是N * P ）。还假设物理地址空间包括F页面帧（即，页面帧号是{0，1，2，...， F - 1}和物理地址的总数是N * F ）。

给定虚拟地址VA ，一个机构（ 映射设备 ）是必需的，以确定的物理地址， PA ，它被映射到或者如果它不映射页面错误应该提高。映射装置使用存储在某个地方执行映射的数据结构（页表）。应该有在该表的描述页面是如何映射和潜在的一些附加属性（如保护属性）各分配的虚拟页的条目。页表项的设计，你会看到，与页面大小进行交互。我将讨论页表项的设计在Intel 80386以后。

一个虚拟地址的大小是log _2（ N * P ）和物理地址的大小为log _2（ N * F ）。的一些位VA将代表页面内的偏移，而其它位将表示页号，标识使用该映射装置的页面。

有多少选择我们对页面大小？那么，它可以作为一个一个字节高达N * P或N * F ，取其较小者。这是一个很大的选择空间。

它方便了页面大小为2的幂

虚拟地址， VA ，是相当于对页号和偏移量，（ PN ， OFF ）。翻译过程中应尽可能高效。它的方便程序员³有一个页面内的字节是在地址空间是连续的。以这种方式，多字节的数据结构内的项目的地址可以通过简单的算术上的单个地址，该地址将构成的数据结构的基地址计算。这可以通过使用至少显著日志_2（来实现N虚拟地址的）比特（四舍五入）来表示偏移量和其余位来表示页码。

如果N不是2的幂，会有被偏移量和页面数之间共享，这取决于这些位的值的一些位。通过使N 2的幂，这样的并发症不存在。因此，这将整齐使用页面大小是2的n次方，支持为二的幂（虽然寻址的单位不得为8位）使用分页的页面大小，这是有道理的所有真正的处理器。但说实话，目前还不清楚这是否真的很重要。用今天的技术，无论N是2的功率可能不会对性能或感兴趣的其他任何指标可衡量的影响。事实上，在未来的需要越来越大的页面大小，可能会发生一些页面大小不是2的幂为好。但到目前为止，这种情况并未发生。我想在这里指出的一点是，使页面大小的设计选项不是2功率不应自动解除。我相信这是未来的虚拟内存系统研究的好机会。

不管怎样，牢记4个KB的页面选择在80年代出现了，在页面大小等极其微小的变化都显示（包括理论和实验）是不太重要。所以电源的-2页大小的便利胜利。这减少了页面大小的数量成倍考虑。但是，我们仍然有一个很好的选择范围。

有利于较小的页大小

由于映射设备的工作原理在页面的水平，从操作系统的角度分配的单位是一个虚拟页面^4。即使一个应用程序需要只分配1个字节，但它仍必须告诉操作系统分配整个虚拟页面为1个字节。这个问题被称为内部碎片 。每个应用程序（或者应用的甚至每个分量）具有从它在页面大小的块分配存储其自己的虚拟地址空间。它从每个应用程序预计将不使用单页为它分配一个对象，但它分配更多的页面之前在同一页面，而分配尽可能多的对象可能。然而，由于页面在页面级属性的工作，同样的应用程序可以使用多个用户模式的内存管理器（如使用多个C / C ++运行时时），它是很难申请到分享他们使用的不是网页的部分与其他应用程序，可以发生在系统中的多个页面内部碎片。使用较小的页面大小可以帮助减少浪费物理（对整个系统）和虚拟（每个进程）的内存量。

此外，应用程序通常要经过多个阶段的整个生命周期，它们显示出在不同阶段不同的内存需求。如果页面大小，比如说，16 KB，但很多应用可能只需要较少的10 KB为他们的许多阶段，那么会有很多浪费的物理内存，这可能会导致，可能有内存不足的局势被避免，如果较小的页大小，如8个或4 KB，得到了支持。

页面大小较小，最好处理写入时复制的软页面错误，因为页面是较小的，这将花费更少的时间来创建它的一个副本。对于非常小的页面大小，这可能不作任何可测量的差异，这取决于内存总线带宽。

在70年代的计算机可用的物理存储器的典型量是在10秒或KB为100s的范围内。这是没有意义有数百KB或更大的页面大小。事实上，当时的应用工作组是典型的只有很少或几十KB的。因此，即使页面尺寸小16 KB不可能是实际的，因为只有一两页可能消耗所有可用的物理内存。页面大小应该是一致的物理内存数量。这种说法可以应用到今天的课程系统（它是没有意义有例如128 GB页）。

因此，考虑工作集大小和所述的物理存储器可用性70s和80年代初，页大小应该是2的幂的范围内2 ⁰ -2 ^14。酷，现在我们只有15可供选择的方案。

有利于较大的页大小

我们也可以说，较大的页大小更好。出于同样的工作组，较小的页面大小意味着每个应用程序页面，这就需要页表项，以使翻译数量较多。这从根本上需要较大的页表，而不管页表的结构（尽管确切的开销取决于页表项本身，我将在后面讨论的设计）。想象一下，例如4个字节的页面和典型工作组几十KB的的。那么大多数的物理内存实际上将被分配给持有页表，而不是数据。换出页表借调存储导致双页错误个别内存引用，这将是对性能绝对可怕。这样的设计显然是荒谬的。

从本质上讲，页面大小不应该是（多）比都不可能永远是最小的工作集大小小。这立即排除了大小2 ⁰ -2 ⁶页，让我们8种选择。该研究的页面尺寸大多只研究这8个选项上世纪70年代和80年代初的论文。

还有另外一个原因，使得较大的页面大小是有利的。其中的虚拟内存的好处是能够透明地使用二级存储除了主内存来保存非易失性数据。然而，辅助存储装置是机械和与批量传输的效果最好。这更多的是一种指引真的，我们不应该排除任何页面大小呢。有不同的设计和特点，并最终设备，批量传输的性能优势将会饱和在一些点。但它肯定是测量页面大小对性能的影响时，要考虑到。如果正在考虑应用程序的类型表现出一点空间位置，那么较小的页大小仍然是可取的，因为复制额外的字节或从盘是不完全是免费的。

参考空间局部性鼓励使用某些页面大小。对于非常小的页面大小，这是极有可能的是，在页面的所有字节将在时间的小周期中使用。作为一个页的大小变大，所使用的是不太可能的字节数的增加。然而，对于非常大的网页，所有的工作组可以适合少数地方无关的页面中。因此，尽量减少页面故障数，页面大小应该是过小或过大，但不能在两者之间。但最终，这从一个应用程序到另一个变化。新兴编程范式，例如面向对象的编程和功能编程，和技术，如多线程可能实际上减少了空间局部性由于广泛使用联结构的，并且由于不同方式的应用与彼此交互。较大的页面大小是最好减少页面故障的数量。然而，如果页面大小较小可能是多个应用程序之间共享，以减少共享页面的内部碎片内存更好。还已经通过实验表明，可在主存储器被保持页面帧的数量与页面故障的数量相关的，有利于更小的页大小。

需要的TLB在当时是公认的。英特尔称他们为页面缓存在他们的专利（不知道是否英特尔是第一个用这个词）。因为地址转换是执行指令的关键路径上快速的TLB是非常重要的。为了让他们尽可能地快，他们应该做出微小的，但他们只能缓存少量的页表项。这促使使用较大的页面大小。

在寻找最佳的页面大小，事实证明，没有一个。它在这个时候，有必要支持多种页面大小是众所周知的。实际上，系统的Multics在1965年设计的支持64位或1024字页面（一个字面积为36位）。在范围2 ⁷ -2 ¹⁴页大小被证明是在不同情况下的最佳既凭经验且理论上。 英特尔必须观察到，4 KB页造成的，在上世纪80年代使用他们的客户应用的最佳平均性能。 对于今天的计算机和应用程序，在页面尺寸如此微小的差异没有太大的区别，因为它曾经是上世纪70年代和80年代。

英特尔80386的页表项的设计

页目录项和页表项的设计进行了详细的讨论了英特尔的专利。这是重要的，因为页表项和页表的整体结构的大小是考虑到许多研究有关的页面大小，因为它们都彼此互动。我不想详细讨论这个保持答案简短。

在近期的页面大小

英特尔已获得专利几个月前，显然提出了具有64 KB的默认页面大小的系统，但同时支持4 KB页（和其他IA-32E页面大小）的向后兼容性。我从专利引用：

作为支持64KB的页的映射成4个KB子页面的结果，VA64直接支持在4个KB页面，包括每4 KB页独立保护位和任意4 KB对齐的地址映射所有当前定义的操作。 VA64还支持4个KB边界OS内核页面管理，即使在OS内核64个KB单位分配内存。作为支持的大页面的结果，VA64支持虚拟地址范围内的所有部门到一个现有的寻呼系统，如Intel公司的IA-32E寻呼系统支持的网页。因此，VA64支持在4 KB页的Windows®操作系统内核工作，同时还要考虑的64个KB的页面充分利用时，可使用64次KB的网页应用程序和硬件设备。
VA64的能力可以逐渐被OS内核采用，而不是要求他们都在第一代VA64功能的操作系统内核的支持。例如，VA64功能的OS内核可以通过所有页面映射到当前大小启动（例如，4 KB / 2 GB / 1 TB在英特尔公司的IA-32E寻呼系统），但改变到一个新的页表格式。在页表的格式更改后，操作系统内核可以被更改为64个KB单元映射虚拟内存和更改存储在其空闲列表64次KB的页面。然后，操作系统内核可以开始使用64 KB页对齐时和保护许可证，并增加对其他VA64功能的支持。

我不知道任何关于比什么写在专利之外的VA64寻呼系统。没有什么它在互联网上的任何地方。我想我们会更很快就会找到答案。

选定参考

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

Gelenbe，E.，蒂贝里奥，P.，＆Boekhorst，JCA（1973）。页面尺寸的需求，寻呼系统。 ACTA的Informatica，3（1），1-23。

Alanko，TO，和Verkamo，AI（1983）。分段，分页和虚拟内存优化的页面大小。性能评价，3（1），13-33。

Corbató，FJ，＆Vyssotsky，VA（1965）。简介和的Multics系统的概述。在11月30日的程序 - 1965年12月1日，下跌计算机联合会议，第一部分（第185-196）。

脚注

（1）实际上是一个虚拟页面的大小可以是多个页面帧的大小的，但我们不要去那里。

（2）我们可以概括的制定和使用术语“字”，指的是内存，而不是字节的最小可寻址单元，但这里并不重要。

（3）也许不是程序员，根据不同的编程语言，但是编译器，链接器，汇编器和工具，与二进制代码工作。

（4）这当然可以设计出支持使用分页，并在同一时间nonpaging，从而有可能支持分配的多个单元的系统，但我们不要去那里。

Answer 5:

我从维基百科的文章得到了这一点，我引述如下：

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

请查看文章下面：

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

Answer 6:

我补充这个答案/评论，因为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

离开了我一个问题：“怎么样在Linux中那些巨大的页面”？