> For the complete documentation index, see [llms.txt](https://book.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://book.bsdcn.org/4.3-bsd-unix-cao-zuo-xi-tong-she-ji-yu-shi-xian/di-er-bu-fen-jin-cheng/5.2.-4.3bsd-cun-chu-guan-li-de-yan-jin.md).

# 5.2 4.3BSD 存储管理的演进

4.3BSD 的存储管理系统从 PDP-11 小型机上的早期 UNIX 版本一路演进而来。在介绍 4.3BSD 存储管理系统之前，先回顾其若干前身的面貌。

**第七版 UNIX**

第七版（Version 7）是贝尔实验室为 PDP-11——一台 16 位小型机——发布的最后一个 UNIX 版本。PDP-11 采用分段内存体系结构：进程的虚拟地址空间分为 8 段，每段至多 8 KB。这一 64 KB（2¹⁶ 字节）的虚拟地址空间上限不仅适用于每个用户进程，也适用于内核（内核在独立的特权保护模式下执行）。

早期 PDP-11 支持的主存上限是 248 KB；PDP-11/70 等较晚的型号则允许近 4 MB 内存。有些型号还支持指令与数据空间分开，这一特性实际上使最大程序规模翻倍。

PDP-11 虚拟地址范围有限，促使凯斯西储大学、普渡大学、加州大学伯克利分校和几所欧洲大学的开发者为用户程序和内核创建软件覆盖方案。内核的覆盖尤其有用，因为要在 PDP-11 上提供联网等设施，地址空间太小通常正是最大的问题。不过即便有软件覆盖，PDP-11 上单个程序的最大规模与通常可用的主存量相比仍然很小。而且覆盖只扩展有效的正文空间，不扩展数据空间（至少不损失寻址透明性就做不到）。更大的数据空间才是许多程序（如用 LISP 写的程序）真正的需要。

UNIX 的存储管理技术与这类机器的档次相称，特别简单。程序按整体、连续地装入物理内存。内存共享仅限于按特定方式标记的程序只读共享正文段。存储管理基于交换，用于交换的辅存限于磁盘上单一专用区。最后，进程的交换空间在进程创建时分配，以确保可用。

**UNIX 32V**

VAX-11/780 于 1978 年问世。这台 32 位小型机拥有 4 GB（2³² 字节）虚拟地址空间，设计上支持请求调页虚拟内存。

第一台运行在 VAX 上的 UNIX 系统叫 32V；它是对既有 PDP-11 版 UNIX 的直接移植。开发者起初靠在 VAX 的分页虚拟内存体系结构上仿真 PDP-11 硬件存储管理设施完成移植 \[London & Reiser, 1978]。进程仍然全部驻留并连续位于主存。唯一放宽的限制是程序的最大规模：上限从 64 KB 提高到可调的、默认 192 KB。程序虽然能比 PDP-11 上大，仍须完全驻留。因此程序的大小受机器物理内存量的限制（0.5 到 2 MB，而且其中一部分被永久驻留的 UNIX 内核占用）。

最初的移植还沿用第七版的做法：主存紧张时整个进程仍被换到辅存。此外，进程间唯一的内存共享通过纯正文段实现。

32V 发布之前，存储管理系统又经修订，在两个方面扩充了这一最初方案。第一，程序在主存中的连续布局改为分散装载（scatter-loading）方案：进程的虚拟地址空间逐页装入主存。第二，需要主存时，可以把进程的一部分（而不是整个进程）换到辅存。这两项设施分别避免了内存碎片、提供了比 PDP-11 更高的多道程序程度，却仍未完全支持 VAX 的虚拟内存体系结构。仍然无法创建虚拟内存大于机器可用物理内存的进程——进程必须完全驻留才能执行。

**3BSD**

3BSD 发行版用一套请求调页的虚拟存储管理系统取代了 32V 的分散装载和部分交换。这一系统的设计动机，一是需要运行非常大的进程（大于可用物理内存），二是为开展虚拟存储管理相关的性能评估研究提供可用的环境 \[Babaoglu et al., 1979]。

3BSD 调页系统使用：

* 请求调页的取页策略（即系统只取引发缺页的页）
* 逐页的放置策略
* 近似全局最近最久未使用（LRU）的置换算法

置换算法把全部可用物理内存视为一个由页组成的环，扫描这个环采集引用信息，并按最久未使用选择替换。此外，进程调度程序还利用调页系统维护的内存利用统计来动态调整多道程序的程度。

与之前的系统一样，全部内核正文和大部分内核数据永久驻留主存。进程虚拟地址空间的结构（正文、数据、栈段）保持不变，只是空间的最大规模不再受可用内存限制。进程间的内存共享也未变，主要是由于一项底层设计决策：尽量减少用户可见的系统变化。

3BSD 的辅存管理与 4.3BSD 没有显著差别。进程创建时为它的整个地址空间预分配存储。这一策略主要缘于辅存与主存相比容量巨大。

**4.1BSD**

4.0BSD 和 4.1BSD 的存储管理系统是集中性能调优的产物 \[Kashtan, 1980; Joy, 1980]。3BSD 引入的基本算法和数据结构几乎原封未动，只是做了针对具体性能问题的改动，并跟进硬件变化（如 VAX-11/750 的问世）。

4.1BSD 有五处值得一提的变化：

1. 调页系统改为不再直接操纵硬件页，而是处理称为簇（cluster）的逻辑页。簇的大小必须是底层硬件页大小的整数倍；引入簇是为了降低缺页处理等页相关操作的成本。使用簇还缩小了某些系统数据结构，从而在同样多的物理内存中支持更大的虚拟内存。
2. 取页策略加入了有限的预调页。一部分预调页是引入簇的副产品：系统不再为一次缺页只取一页，而是把整簇里的页都取来。
3. 通过尽可能在单次操作中写出多个脏簇，降低了把脏页移到辅存的开销。
4. 正文映像各页的设备号和块号随空闲页的描述一起保存，把最近用过的正文页缓存在内存中。
5. 进程对系统的页面置换和预调页策略获得了最低限度的控制权。控制形式是一个系统调用：进程预期表现出顺序或随机内存引用模式时，可据此通知系统。系统随后利用这一信息停用预调页（随机访问场合），或把页标记为替换的候选。

**4.3BSD**

4.3BSD 虚拟内存系统的变化面向适应硬件技术的变迁。

* 所有程序的正文映像和页表在 `exit` 之后保留在缓存里，很像旧时用来把常用程序的页强留在交换空间的粘滞位机制。
* 页面置换算法改为与主存规模无关；这一改动改善了调页系统在大主存机器上的表现。
* 使用远程文件服务器的工作站加上更大的主存，使扩充预调页的数量变得划算。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://book.bsdcn.org/4.3-bsd-unix-cao-zuo-xi-tong-she-ji-yu-shi-xian/di-er-bu-fen-jin-cheng/5.2.-4.3bsd-cun-chu-guan-li-de-yan-jin.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.