通常情况下，用于处理此中断的程序是 *** 作系统的一部分。如果 *** 作系统判断此次访问是有效的，那么 *** 作系统会尝试将相关的分页从硬盘上的虚拟内存文件中调入内存。而如果访问是不被允许的，那么 *** 作系统通常会结束相关的进程。
虽然其名为“页缺失”错误，但实际上这并不一定是一种错误。而且这一机制对于利用虚拟内存来增加程序可用内存空间的 *** 作系统（比如Microsoft Windows和各种类Unix系统）中都是常见且有必要的。
VA：Virtual Address 虚拟地址
PA：Physical Address 物理地址
MMU：Memory Manage Unit 内存管理单元
TLB：Translation Lookaside Buffer 旁路快表缓存/地址变换高速缓存
PTE：Page Table Entry 分页表项
CPU通过地址总线可以访问连接在地址总线上的所有外设，包括物理内存、IO设备等等，但从CPU发出的访问地址并非是这些外设在地址总线上的物理地址，而是一个虚拟地址，由MMU将虚拟地址转换成物理地址再从地址总线上发出，MMU上的这种虚拟地址和物理地址的转换关系是需要创建的，并且MMU还可以设置这个物理页是否可以进行写 *** 作，当没有创建一个虚拟地址到物理地址的映射，或者创建了这样的映射，但那个物理页不可写的时候，MMU将会通知CPU产生了一个缺页异常。
只有程序运行时用到了才去内存中寻找虚拟地址对应的页帧，找不到才可能进行分配，这就是内存的惰性(延时)分配机制。
对于一个运行中的进程来说，不是所有的虚拟地址在物理内存中都有对应的页。虚拟地址空间根据固定大小一般是4KB进行划分，物理内存可以设置不同的页面大小，通常物理页大小和虚拟页大小是一样的，都是 4KB。
CPU并不直接和物理内存打交道，而是把地址转换的活外包给了MMU，MMU是一种硬件电路，其速度很快，主要工作是进行内存管理，地址转换只是它承接的业务之一。
一起看看MMU是如何搞定地址转换的。
每个进程都会有自己的页表Page Table，页表存储了进程中虚拟地址到物理地址的映射关系，所以就相当于一张地图，MMU收到CPU的虚拟地址之后开始查询页表，确定是否存在映射以及读写权限是否正常，如图：
对于4GB的虚拟地址且大小为4KB页，一级页表将有2^20个表项，页表占有连续内存并且存储空间大，多级页表可以有效降低页表的存储空间以及内存连续性要求，但是多级页表同时也带来了查询效率问题。
我们以2级页表为例，MMU要先进行两次页表查询确定物理地址，在确认了权限等问题后，MMU再将这个物理地址发送到总线，内存收到之后开始读取对应地址的数据并返回。
MMU在2级页表的情况下进行了2次检索和1次读写，那么当页表变为N级时，就变成了N次检索+1次读写。
可见，页表级数越多查询的步骤越多，对于CPU来说等待时间越长，效率越低，这个问题还需要优化才行。
CPU觉得MMU干活虽然卖力气，但是效率有点低。有没有提升效率的办法呢？
我们知道 CPU 用的数据经常是一小搓，但是每次MMU都还要重复之前的步骤来检索，害，就知道埋头干活了，也得讲究方式方法呀！
找到瓶颈之后，MMU引入了新武器，江湖人称快表的TLB（其实，就是缓存），别看TLB容量小，但是正式上岗之后干活还真是不含糊。
当CPU给MMU传新虚拟地址之后，MMU先去问TLB那边有没有，如果有就直接拿到物理地址发到总线给内存，齐活。
TLB容量比较小，难免发生Cache Miss，这时候MMU还有保底的老武器页表 Page Table，在页表中找到之后MMU除了把地址发到总线传给内存，还把这条映射关系给到TLB，让它记录一下刷新缓存。
TLB容量不满的时候就直接把新记录存储了，当满了的时候就开启了淘汰大法把旧记录清除掉，来保存新记录，彷佛完美解决了问题。
TLB的容量毕竟有限，为此必须依靠Page Table一起完成TLB Miss情况的查询，并且更新到TLB建立新映射关系。
设想，CPU给MMU的虚拟地址，在TLB和 Page Table都没有找到对应的物理页帧，该怎么办呢？
没错，这就是缺页异常Page Fault，它是一个由硬件中断触发的可以由软件逻辑纠正的错误。
假如目标内存页在物理内存中没有对应的页帧或者存在但无对应权限，CPU 就无法获取数据，这种情况下CPU就会报告一个缺页错误。
由于CPU没有数据就无法进行计算，CPU罢工了用户进程也就出现了缺页中断，进程会从用户态切换到内核态，并将缺页中断交给内核的 Page Fault Handler 处理。
缺页异常并不可怕，只要CPU要的虚拟地址经过MMU的一番寻址之后没有找到或者找到后无权限，就会出现缺页异常，因此触发异常后的处理流程将是重点内容。
缺页中断会交给PageFaultHandler处理，其根据缺页中断的不同类型会进行不同的处理：
page cache用于缓存文件的页数据，buffer cache用于缓存块设备（如磁盘）的块数据。页是逻辑上的概念，因此page cache是与文件系统同级的；块是物理上的概念，因此buffer cache是与块设备驱动程序同级的。
page cache与buffer cache的共同目的都是加速数据I/O：写数据时首先写到缓存，将写入的页标记为dirty，然后向外部存储flush，也就是缓存写机制中的write-back（另一种是write-through，Linux未采用）；读数据时首先读取缓存，如果未命中，再去外部存储读取，并且将读取来的数据也加入缓存。 *** 作系统总是积极地将所有空闲内存都用作page cache和buffer cache，当内存不够用时也会用LRU等算法淘汰缓存页。
page cache中的每个文件都是一棵基数树（radix tree，本质上是多叉搜索树），树的每个节点都是一个页。根据文件内的偏移量就可以快速定位到所在的页，如下图所示。
IO 会产生page cache ，具体过程参考下图：
首先往用户缓冲区 buffer(这是 Userspace Page) 写入数据，然后 buffer 中的数据拷贝到内核缓冲区（这是 Pagecache Page），如果内核缓冲区中还没有这个 Page，就会发生 Page Fault 会去分配一个 Page，拷贝结束后该 Pagecache Page 是一个 Dirty Page（脏页），然后该 Dirty Page 中的内容会同步到磁盘，同步到磁盘后，该 PageCache Page 变为 Clean Page 并且继续存在系统中。
Kafka为什么不自己管理缓存，而非要用page cache？原因有如下三点：
Kafka三大件（broker、producer、consumer）与page cache的关系可以用下面的简图来表示。
producer生产消息时，会使用 pwrite() 系统调用（对应到Java NIO中是FileChannel.write() API），按偏移量写入数据，并且都会先写入page cache里。consumer消费消息时，会使用sendfile()系统调用（对应FileChannel.transferTo() API），零拷贝地将数据从page cache传输到broker的Socket buffer，再通过网络传输。
https://blog.csdn.net/sinat_22338935/article/details/114320664
https://www.jianshu.com/p/92f33aa0ff52
以32位的Linux系统为例，每个进程独立拥有4GB的虚拟地址空间，根据局部性原理没有必要也不可能为每个进程分配4GB的物理地址空间。
64位系统也是一样的道理，只不过空间寻址范围大了很多很多倍，进程的虚拟地址空间会分为几个部分：
实际上只有程序运行时用到了才去内存中寻找虚拟地址对应的页帧，找不到才可能进行分配，这就是内存的惰性(延时)分配机制。
对于一个运行中的进程来说，不是所有的虚拟地址在物理内存中都有对应的页，如图展示了部分虚拟地址存在对应物理页的情况：
虚拟地址空间根据固定大小一般是4KB进行划分，物理内存可以设置不同的页面大小，通常物理页大小和虚拟页大小是一样的，本文按照物理页4KB大小展开。
经过前面的分析，我们将面临一个问题： 如何将虚拟地址准确快速地映射到物理页呢？
CPU并不直接和物理内存打交道，而是把地址转换的活外包给了MMU，MMU是一种硬件电路，其速度很快，主要工作是进行内存管理，地址转换只是它承接的业务之一。
一起看看MMU是如何搞定地址转换的。
每个进程都会有自己的页表Page Table，页表存储了进程中虚拟地址到物理地址的映射关系，所以就相当于一张地图，MMU收到CPU的虚拟地址之后开始查询页表，确定是否存在映射以及读写权限是否正常，如图：
对于4GB的虚拟地址且大小为4KB页，一级页表将有2^20个表项，页表占有连续内存并且存储空间大，多级页表可以有效降低页表的存储空间以及内存连续性要求，但是多级页表同时也带来了查询效率问题。
我们以2级页表为例，MMU要先进行两次页表查询确定物理地址，在确认了权限等问题后，MMU再将这个物理地址发送到总线，内存收到之后开始读取对应地址的数据并返回。
MMU在2级页表的情况下进行了2次检索和1次读写，那么当页表变为N级时，就变成了N次检索+1次读写。
可见，页表级数越多查询的步骤越多，对于CPU来说等待时间越长，效率越低，这个问题还需要优化才行。
MMU和TLB的故事就这样开始了...
CPU觉得MMU干活虽然卖力气，但是效率有点低，不太想继续外包给它了，这一下子把MMU急坏了。
MMU于是找来了一些精通统计的朋友，经过一番研究之后发现CPU用的数据经常是一小搓，但是每次MMU都还要重复之前的步骤来检索，害，就知道埋头干活了，也得讲究方式方法呀！
找到瓶颈之后，MMU引入了新武器，江湖人称快表的TLB，别看TLB容量小，但是正式上岗之后干活还真是不含糊。
当CPU给MMU传新虚拟地址之后，MMU先去问TLB那边有没有，如果有就直接拿到物理地址发到总线给内存，齐活。
TLB容量比较小，难免发生Cache Miss，这时候MMU还有保底的老武器页表 Page Table，在页表中找到之后MMU除了把地址发到总线传给内存，还把这条映射关系给到TLB，让它记录一下刷新缓存。
TLB容量不满的时候就直接把新记录存储了，当满了的时候就开启了淘汰大法把旧记录清除掉，来保存新记录，彷佛完美解决了问题。
在TLB和Page Table加持之下，CPU感觉最近MMU比较给力了，就问MMU怎么做到的？MMU就一五一十告诉了CPU。
CPU说是个不错的路子，随后说出了自己的建议：TLB还是有点小，缓存不命中也是经常发生的，要不要搞个大的，这样存储更多访问更快？
MMU一脸苦笑说道大哥TLB很贵的，要不你给涨点外包费？话音未落，CPU就说涨工资是不可能了，这辈子都不可能了。
设想 CPU给MMU的虚拟地址在TLB和Page Table都没有找到对应的物理页帧或者权限不对，该怎么办呢？
没错，这就是缺页异常Page Fault， 它是一个由硬件中断触发的可以由软件逻辑纠正的错误 。
假如目标内存页在物理内存中 没有对应的页帧或者存在但无对应权限 ， CPU 就无法获取数据 ，这种情况下 CPU就会报告一个缺页错误 。
由于CPU没有数据就无法进行计算，CPU罢工了 用户进程也就出现了缺页中断 ，进程会从用户态切换到内核态，并将缺页中断交给内核的 Page Fault Handler 处理。
缺页异常并不可怕，只要CPU要的虚拟地址经过MMU的一番寻址之后没有找到或者找到后无权限，就会出现缺页异常，因此触发异常后的处理流程将是重点内容。
缺页中断会交给PageFaultHandler处理，其根据缺页中断的不同类型会进行不同的处理：
不同类型的Page Fault出现的原因也不一样，常见的几种原因包括：
本文粗浅地和大家一起学习了Page Fault的相关知识点，包括Linux虚拟地址和物理地址的关系、CPU获取内存数据的过程、MMU和TLB&页表的协同配合、缺页异常产生的原因和分类处理。
本文并没有对MMU的内部机制、内核态&用户态缺页异常、缺页异常处理函数等内容进行展开，主要是因为这部分内容相对晦涩，还得靠自己深入研究。
在程序的执行过程中，因为遇到某种障碍而使 CPU 无法最终访问到相应的物理内存单元，即无法完成从虚拟地址到物理地址映射的时候，CPU 会产生一次缺页异常，从而进行相应的缺页异常处理。基于 CPU 的这一特性，Linux 采用了请求调页（Demand Paging）和写时复制（Copy On Write）的技术1． 请求调页是一种动态内存分配技术，它把页框的分配推迟到不能再推迟为止。这种技术的动机是：进程开始运行的时候并不访问地址空间中的全部内容。事实上，有一部分地址也许永远也不会被进程所使用。程序的局部性原理也保证了在程序执行的每个阶段，真正使用的进程页只有一小部分，对于临时用不到的页，其所在的页框可以由其它进程使用。因此，请求分页技术增加了系统中的空闲页框的平均数，使内存得到了很好的利用。从另外一个角度来看，在不改变内存大小的情况下，请求分页能够提高系统的吞吐量。当进程要访问的页不在内存中的时候，就通过缺页异常处理将所需页调入内存中。
2． 写时复制主要应用于系统调用fork，父子进程以只读方式共享页框，当其中之一要修改页框时，内核才通过缺页异常处理程序分配一个新的页框，并将页框标记为可写。这种处理方式能够较大的提高系统的性能，这和Linux创建进程的 *** 作过程有一定的关系。在一般情况下，子进程被创建以后会马上通过系统调用execve将一个可执行程序的映象装载进内存中，此时会重新分配子进程的页框。那么，如果fork的时候就对页框进行复制的话，显然是很不合适的。
在上述的两种情况下出现缺页异常，进程运行于用户态，异常处理程序可以让进程从出现异常的指令处恢复执行，使用户感觉不到异常的发生。当然，也会有异常无法正常恢复的情况，这时，异常处理程序会进行一些善后的工作，并结束该进程。也就是说，运行在用户态的进程如果出现缺页异常，不会对 *** 作系统核心的稳定性造成影响。 那么对于运行在核心态的进程如果发生了无法正常恢复的缺页异常，应该如何处理呢？是否会导致系统的崩溃呢？是否能够解决好内核态缺页异常对于 *** 作系统核心的稳定性来说会产生很大的影响，如果一个误 *** 作就会造成系统的Oops，这对于用户来说显然是不能容忍的。本文正是针对这个问题，介绍了一种Linux内核中所采取的解决方法。
在读者继续往下阅读之前，有一点需要先说明一下，本文示例中所选的代码取自于Linux-2.4.0，编译环境是gcc-2.96，objdump的版本是2.11.93.0.2，具体的版本信息可以通过以下的命令进行查询：
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)
$ objdump -v
GNU objdump 2.11.93.0.2 20020207
Copyright 2002 Free Software Foundation, Inc.
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）