现代操作系统的内存管理

最近看内存冷热页面替换方向的论文的时候，看到有篇论文 Transparent Hardware Management of Stacked DRAM as Part of Memory 提出了一个有趣的想法，即以段为单位监测内存访问的热点情况，并为每个段分配固定大小的高速缓存。虽然这个方法具有一定的局限性，即没有考虑到段本身的冷热程度，在效率上并不能达到最优，但它成功唤起了我对于内存管理的思考。

根据计算机组成原理，通常认为内存管理是段页式的，其中段式管理提供逻辑上的内存划分（同一段内存具有相同的语义，即同属一个应用程序，或者同为代码/数据），页式管理提供物理上的内存划分（操作系统级别的最小内存管理单位，如分配/虚拟内存的换入换出等）。

然而，事与愿违，当试图在网上搜索的时候，发现大家都在说，x86和x64的操作系统放弃了使用段寄存器，而intel甚至在x64指令集中要求，将段寄存器置为0才是合理的使用方式。

那么事实为何如此呢？根据从网络上收集到的信息来看，可能主要与指令集设计者想甩掉段式管理这个历史包袱有关。早期处理器存在的问题是，处理器的寄存器宽度只有16位，而寻址范围的宽度可以上升到20位，为了应对处理器无法直接寻址超过寄存器宽度的内存地址的问题，加入了段寄存器，通过段寄存器移位的方式，对于数据段/代码段等段寄存器，扩充了程序可使用的内存地址空间。然而寄存器（指令集）大小是指数增长的，光是从16位升级到32位，就让内存花了数十年的时间才重新扩充满整个地址空间，推动64位指令集的刚需化发展。也就是说，从32位指令集开始，内存地址空间的扩张速度就已经远远追不上寻址空间的发展速度了——从这个角度来看的话，既然段式管理解决的是内存空间大于寻址空间的问题，那么在内存空间远小于寻址空间的情况下，段式内存管理似乎就没有存在的必要了（参考StackOverflow）。而从32位指令集开始，段寄存器中的使用方式已经不是之前的基地址移位了，而是变成了段表项，转换成了通过查表的方式取得段的基地址。

于是，一方面为了保障向前兼容性，另一方面为甩开包袱做好准备，指令集设计者和操作系统设计者在这个问题上默契地采用了同一种方法来应对这个问题：不取消段寄存器，但是要求所有的段的基地址都从0x00000000开始。反正指令集的寻址空间足够大，那么只要我将整个地址空间都视作一个段，不就相当于架空了段寄存器的作用，进而消除了段式管理在操作系统中的应用么？

知乎有一文对于在现代操作系统中的管理设计做了实际验证，通过各种骚操作印证了这个事实。不过文中有一处写的不够清楚，在Linux的gdt_table那里，GDT是如何从一串不规则的值映射到像0x0、0x1F这类连续0/1的数字的。这个实际上是因为GDT中的变量不是连续存放的，可能是出于硬件设计对数据做了切分，按照OSDev上的Segment Descriptor做一些简单的运算后，就能验证实际上这些变量都是具有正确的含义的。

看完这些信息后，总感觉我之前对段式内存管理的理解有些不太正确。以前一直以为，段式内存管理像malloc一样，要多少分多少，属于一种与软件相关的逻辑定义；现在才发现，段式管理更多的是一种硬件资源管理方式，段的大小似乎是由体系结构所决定的，也没有软件那种随用随分、即时释放的灵活性。

最后总结一下，由于现在寻址空间远大于内存空间，段页式内存管理中的段式管理逐渐失去其作用，被软硬件所淘汰，主流操作系统中主要依靠页式内存管理和多级页表（应用于虚拟内存）来管理内存空间。