[MIT 6.S081] Lec 18: OS Organization 笔记

Lec 18: OS Organization

• Ref: https://github.com/huihongxiao/MIT6.S081/tree/master/lec18-os-organization-robert
• Preparation: The Performance of micro-Kernel-Based Systems (1997)

宏内核

Linux, Unix 和 XV6 等传统方式实现的操作系统成为宏内核.

宏内核优点

内核庞大且高度抽象.

• 可移植性
• 向应用程序隐藏复杂性
• 帮助管理资源.
• 所有内核子系统集成在一个程序中, 数据共享
• 内核所有代码以完整的硬件权限运行

宏内核缺点

• 庞大->复杂->容易有 Bug->带来安全问题
• 通用目的(General-Purpose)->运行变慢
• 太大而去掉非常复杂的抽象
• 缺乏可扩展性(Extensibility)

微内核

核心观点

• 进程间通信(Inter-Process Communication, IPC)
• 线程或任务
• 内核只需要支持进程/任务/线程, 以及 IPC 作为信息传递途径

微内核优点(动机)

• 微内核更小
  • 美感(sense of aesthetic), 设计小而专注
  • 更安全
  • 可验证正确性和安全性
  • 程序更易被优化, 运行速度更快
  • 更具灵活性
• 大部分功能和函数位于用户空间
  • 代码更模块化
  • 更容易定制
  • 系统更加健壮
• 模拟或运行多个操作系统

微内核的挑战

• 最小化系统调用 API
• 需要开发一些用户空间服务以支持操作系统
• IPC 的性能

L4 微内核

• 只有 7 个系统调用
  • Thread Create: 创建新线程, 若地址空间或任务不存在则会创建任务
  • Send/Recv IPC
  • Mapping: 映射内存页面到当前任务或其它任务的地址空间
  • Dev Access: 特权任务可以将硬件控制寄存器映射到本任务的地址空间中
  • 设备中断转换为 IPC 信息. 包括对 Page Fault的处理, 由每个任务关联的 Pager Task 处理
• 内核进行线程调度和上下文切换.
• 程序不大
• 只有 任务, 线程, 地址空间, IPC 这些基础的抽象

IPC 性能

传统管道实现

• 异步传输
• 需要内核缓冲区存放信息
  两个用户进程间通信需要:
• 4 个相同调用, 2 个 send, 2 个 write
• 8 次用户空间与内核空间的切换
• recv 时需要 sleep 等待数据
• 用户进程切换时需要至少一次线程调度和上下文切换

L4 fast IPC

• 同步传输: P1 调用 send 时会等待 P2 调用 recv, 当两个进程都进入内核后, 直接将消息从 P1 拷贝至 P2(相当于 P1 进入内核返回到 P2)
• 无缓冲(Unbuffered): IPC 过程无需将数据由用户空间拷贝至内核空间
• 零拷贝(Zero Copy): 当消息极小时, 可以直接在寄存器中传递, 无需拷贝
• Page Mapping: 对于极长消息, 可以在 IPC 中携带页面映射, 页面会再次映射到目标任务的地址空间
• RPC: 使用 call 系统调用, 结合 send 和 recv 系统调用: 发送消息的同时等待其它任务的请求消息

在 L4 微内核上运行 Linux

• L4 作为内核运行在底部, Linux 作为一个服务运行在用户空间(作为一个任务)
• 每一个 Linux 用户进程又作为一个独立的 L4 任务运行. Linux 进程执行系统调用时会转换为发送到 Linux 任务的 IPC 消息并返回.
• L4 只有一个内核线程运行 Linux 内核, 而非每个用户进程对应一个 L4 内核线程. 用户进程的内核线程由 Linux 内核线程实现.
• L4 控制用户进程的调度运行
• 缺点: 缺乏和 Linux 一样复杂的线程调度机制

微内核的影响

• 有关虚拟内存使用的系统调用. 导致了 mmap 等系统调用合并到 Linux 系统
• 将操作系统作为一个用户程序运行在另一操作系统之上
• Linux 演进出了可加载的内核模块
• 基于 IPC 的 Client-Server 支持