分页方式中可以每个进程分配一个页表吗

在分页方式下，每个进程分配一个页表会有什么问题？

不卖关子了，每个进程分配一个页表会有空间上的缺陷，因为操作系统上可以运行非常多的进程，那不就意味着页表数量非常多！

1B（Byte 字节）=8bit， 1KB （Kilobyte 千字节）=1024B， 1MB （Megabyte 兆字节简称“兆”）=1024KB， 1GB （Gigabyte 吉字节 又称“千兆”）=1024MB

以32 位的环境为例，虚拟地址空间范围共有 4GB，假设一个页的大小是 4KB（2^12），那么就需要大约 100 万 （2^20）个页，每个「页表项」需要 4 个字节大小来存储，那么整个 4GB 空间范围的映射就要有 4MB 的内存来存储页表。

4MB看起来不大，但是数量上来了就很恐怖了，假设 100 个进程的话，就需要 400MB 的内存来存储页表，这是非常大的内存了，更别说 64位的环境了。

为了解决空间上的问题，在对分页方式的基础上，进行优化，出现了多级页表方式

多级页表

在前面我们知道了，分页方式在32位环境下，以每页4KB来计算，一共有100万页，「页表项」需要 4
个字节大小来存储，一个页表包含100万个「页表项」，那么每个进程的页表需要占用4MB大小，多级页表要如何解决这种问题呢？

在页表的基础上做一次二级分页，把100万「页表项」分为一级页表「1024个页表项」，「一级页表项」下又关联二级页表「1024个页表项」，这样一级页表的1024个页表项就覆盖到了4GB的空间范围映射，并且二级页表按需加载，这样页表占用的空间就大大降低。

做个简单的计算，假设只有 20% 的一级页表项被用到了，那么页表占用的内存空间就只有 4KB（一级页表） + 20% * 4MB（二级页表）=0.804MB，这对比单级页表的 4MB 是不是一个巨大的节约？

接着思考，在二级的基础上是不是又可以继续分级呢，能分二级，必然也能分三级、四级，在64位操作系统是做了四级分页，分为了四个目录，分别是

全局页目录项

上层页目录项

中间页目录项

页表项

TBL

多级页表虽然解决了空间上的问题，但是我们发现这种方式需要走多道转换才能找到映射的物理内存地址，经过的多道转换造成了时间上的开销。

程序是局部性的，即在一段时间内，整个程序的执行仅限于程序的某一部分。相应的，执行所访问的存储空间也局限于某个内存区域。

操作系统就利用这一特性，把最多使用的几个页表项放到TBL缓存， CPU 在寻址时，会先查 TLB，如果没找到，才会继续查常规的页表，TLB的命中率其实很高的，因为程序最常访问的页就那么几个。