⚠ 转载请注明出处：作者：ZobinHuang，更新日期：Oct.20 2021
本作品由 ZobinHuang 采用 知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议 进行许可，在进行使用或分享前请查看权限要求。若发现侵权行为，会采取法律手段维护作者正当合法权益，谢谢配合。
0. Introduction
0.1 System Layout
在本文中将会归类和总结与 Operating System 相关的系统论文，部分与 Device 相关的论文将会在 微架构 & 数字逻辑设计 中进行归纳总结。
内核中最核心的部分可以被分为：Memory & Scheduler，Network Subsystem 和 Storage Subsystem，与它们分别对应的底层硬件是：CPU & 内存、网卡设备和磁盘存储设备，其中网卡设备和存储设备的软硬件交互需要通过相关厂商的 Driver 予以支持。从用户的角度来说，他们与内核交互的接口将是 System Call 层：有的 Application 会使用 System Libraries 来间接使用系统调用，有的则会直接在程序中使用系统调用。
本文我们将就上面所阐述的几大模块 (i.e. 蓝色字体部分) 对论文进行归类和总结。
系统是由上层的算法/框架的迭代更新驱动优化的时候被动优化设计的，所以在每个部分的论文归纳总结中，应该说明这些论文工作的落地场景，并且进行归类，不能盲目的按照系统模块来进行归纳论文，这样子做无法激励 Idea 的产生。有了落地场景，才能知道系统在某个场景下应该具备哪些性能，对系统所做的优化永远是基于某个场景下的新问题来做工作的。
0.2 Reference Source
Conference |
Host |
Description |
Deadline |
|---|---|---|---|
OSDI (Operating Systems Design and Implementation) |
USENIX |
TODO | 十二月底 |
SIGCOM |
|||
NSDI |
|||
SOSP |
|||
FAST |
|||
ASPLOS |
|||
ISCA |
|||
MICRO |
1. Memory & Scheduler
-
Caladan: Mitigating Interference at Microsecond Timescales (OSDI'20)
-
Problem:
传统的 CPU Scheduler 是为了给各个应用分配 cores、memory bandwidth 和 cache 等资源，方案大都是基于 partition 的：
(1) 提前预留相关资源需求 [导致较低的资源利用率]；
(2) 在上层应用需求发生变化时重新分配 [导致较高的重分配延迟]
传统的方案对于剧烈需求变化的应用十分不友好，况且如今大部分的应用都在极短时间内有剧烈的需求的变化 (e.g. Network traffic [bursty request pattern], garbage collection [phased pattern] 等)，因此传统方法无法同时保证 strict performance isolation 和 high CPU utilization。
-
Solution:
论文将应用分为 (1) 高级别的 Latency-Critical (LC) 任务 和 (2) 低级别的 Best Effort (BE) 任务。重新设计了 CPU Scheduler，包括一个用于收集控制信号的核心程序，这些控制信号是细粒度的 metric 诸如 (1) 内存占用带宽 (2) 请求服务时间。并且应用了一个 kernel module 来 bypass 原生 CPU Scheduler 以加速 scheduling operations。
-
Remark:
把共享资源竞争引起的延迟增大称为 干扰 (Interference)。文章讨论了 (1) Hyperthread (2) Memory (3) Last-level Cache 三种类型的干扰。
-
2. Network Subsystem
3. Storage Subsystem
-
CrossFS: A Cross-layered Direct-Access File System (OSDI'20)
-
Problem:
[1] 对于传统的 Kernel-level FS，存在三个瓶颈：(1) 用户态程序需要不断地陷入内核来完成 I/O 操作；(2) 即使是在访问同一个文件内的不同区域的数据，inode-level 的读写锁导致了 unnecessary 的 serialization overhead；(3) 无法完全发挥 hardware-level 的 capacity —— compute、几千条 I/O 队列、firmware-level 调度策略等。
[2] 对于 User-level FS，(1) 它们无法像 Kernel-level FS 一样保证 correctness：有的仅提供数据面的操作，而有的继承了 Kernel 的多线程/进程的控制面来实现可靠性保证；(2) 同样地，User-level FS 无法完全发挥 hardware-level 的 capacity。
[3] 对于 firmware-level FS，它们将 FS 植入了 hardware 的 firmware 中，然而它们 (1) 无法受益于主机级的多核并行性；(2) 继承了基于 inode 的请求队列、并发控制和调度设计，使得 I/O 扩展性变差。
-
Solution:
设计了一个 Cross-layered Direct-accrss FS，横跨了 User、Kernel 和 Firmware 三层来构建文件系统：
[1] FirmFS：Firmware-level File System，在硬件固件上提供了直接访问存储的能力。通过使用硬件层面的 I/O Queues、Computational Resource 和 I/O Schedule Capability，提高了底层 I/O 的性能；
[2] LibFS：User-level File System，提供标准的 POSIX 接口，基于主机多核 (host-CPUs) 在用户态上控制上层应用的 Concurrency (并发性)；
[3] OS-component：仅在初始化阶段工作，用于设置 FirmFS 和 LibFS 之间的接口。
-
Remark:
思考：
1. 文章 background 部分详细介绍了各类文件系统；
2. 是否可以 inspire 到 协同网络子系统 (synergistic network subsystem)
-
4. Driver
-
A Simpler and Faster NIC Driver Model for Network Functions (OSDI'20)
-
Problem:
由于 NIC Driver 过于通用 (e.g. 支持 NF 乱序收发包，这种强大但复杂的功能是很多 NF 不需要的)，它们降低了上层 NF 的性能，成为系统瓶颈。
-
Solution:
为 NF 重新设计了 Driver 模型，重用了 packet buffer，使得网卡驱动变得简单且高效。
-
Remark:
文章背景部分详细地分析了网卡的工作原理
-
5. Device
-
PANIC: A High-Performance Programmable NIC for Multi-tenant Networks (OSDI'20)
-
Problem:
不同的上层租户会有不同的底层卸载链 (i.e. 级联不同的卸载单元)，传统的卸载方案不支持在网卡上承载多条不同的卸载链。
-
Solution:
基于 RMT Switch Pipeline 来设计 SmartNIC 上的交换逻辑，并且设计了调度器，实现了高性能的 on-NIC 负载均衡。
-
Remark:
1. 文章对 SmartNIC 的各种种类做了分析
2. 思考：SmartNIC 上的资源利用是否可以被量化且被优化？
-