【阅读总结】Improving IPC by kernel design

  该篇文章由Jochen liedtke所写，他发现自己L3操作系统还有很多可以提升的地方，主要就是IPC的效率提升，所以写了此文。该篇文章的确是引导做研究的好文章，在整体结构上，该篇文章首先抛出了IPC困境，IPC提升了操作系统灵活度，进程间交流通过IPC方便了不少，可是IPC的通讯压力又太大。然后，该文介绍了设计改进，并最后20倍地提升了IPC速度。

    内容上该篇文章首先分析了背景， L3操作系统特点，进而介绍了本文的设计研究原则，之后介绍了期望达到的性能目标。然后是架构、算法、接口、代码层面的改进，最后是实验结果。

  这里把技术总结放到最前面，本文所用技术及提升方案如下表所概述。

提升方面	技术内容	个人理解
架构	新增系统调用	创建了新的RPC函数，reply&receve next，将RPC通信的消息传递过程从4次变为2次。
–	消息结构设计	设计L3中的IPC消息包含直接字符串、非直接字符串和内存对象。直接字符串存放一些操作码/指令；非直接字符串放具体消息的地址，内存对象设计用于特别的传输。
–	通过临时映射直接传递消息	IPC过程需要严格控制的一个点是保证用户态下的进程只能访问到自己的地址空间。初步设计为线程A->内核->线程B的消息传递，2次复制过程。 再考虑可能采取共享内存的方式实现单次复制，同时需要考虑系统安全，需要内核的介入。 所以，为了实现内核介入的单次复制过程，文章提出的发送消息方式在进程的地址空间划分内核段，发送方发送消息到自己地址空间的内核段，内核段直接映射到接收方的接收空间所映射的物理地址上。 进程留予的内存用于IPC的那段空间成为Communication Window，为了让每个线程都得到完全的使用，在线程切换时将unmap物理地址，切换回去的时候再交由发生的缺页中断重新映射上之前的物理地址。
–	面向进程	上一技术在进程的地址空间里设计了一段内核独享的空间，那么本节的技术就是将进程内线程TCB和线程的内核栈全都放在这一空间里。结构简单、清晰，这就是为什么这个技术叫做面向进程吧。
–	控制块作为线程栈虚拟对象	该技术主要将TCB的构成，TCB保存了线程与硬件相关的信息，在CPU切换线程前后TCB的任务就是保存/恢复现场。TCB在进程空间里的设计具有很多好处： 1. [TCB+内核栈]们连在一起，可以基地址+偏移进行快速检索。 2. TLB查找少了：TCB快速检索的特性使得它不需要再用一个表保存他们的位置，在索引时就节省了TLB一次使用，再由于TCB和线程内核栈放在内存的一页里，又减少了内核栈的TLB查找。 3. 线程持久化实现了。 4. 线程加锁简单化（不映射TCB块）。 5. IPC与内存管理正交（过程不需要外加特定的MMU配合）。
算法	线程描述符的设计	64位线程的uid设计使得地址空间可以经由位运算快速检索。
–	虚拟队列的处理	内核根据线程类型，工作任务建立了很多存放TCB指针的队列，这个时候对于这些队列中的TCB需要维护，线程结束运行后需要及时移除。避免缺页中断（避免已经不存在的线程带来发生缺页的事故）。
–	超时与唤醒	IPC过程会设计超时，本文这里按照超时时间的不同划分了多个队列减少顺序检索开销。对于特别长超时的消息（t>天）设计base+offset的方式存储到特殊队列。
–	懒调度	IPC过程对于线程的就绪ready、等待wait状态是有队列保存的，通信过程中需要时常删除或加入TCB到不同队列。 本文根据TCB中线程state确定线程的状态信息，可以晚些甚至无需总是开销时间在维护队列上，特别在IPC频繁的时候这样的队列操作很多。此外，对于被中断切下的线程需要存储到Ready队列中方便下次CPU再切回。这样的中断包括3种：1)时间片耗尽、2)硬件中断、3)send操作（阻塞）
–	直接进程切换	按照IPC过程的队列，切换进程到ready线程。直接切换过程只需要调整栈指针和地址空间，速度很快。
–	短消息由寄存器发送	利用寄存器发送一些常量（ack/error_code等）
接口	避免没有必要的消息拷贝	消息按类型划分，避免解析过程开销等。
–	参数传递	尽可能使用寄存器传递消息
代码	缓存MISS降低	少用Jump，亲和性强的代码放在一个Cache Line
–	降低TLB MISS	IPC常用的消息放到内存同一页里，避免多次TLB查询
–	少用段寄存器	段寄存器加载时间过长，发送消息时限制长度，少用段寄存器
–	通用寄存器	分析存储消息地址的段寄存器(16bits)和计数使用的一般寄存器(8bits)长度，设定消息发送的长度。
–	进程切换	综和架构设计，程序采用改变栈指针和地址空间的方式即可快速切换进程。

一、背景与目标

    首先本文所提到比较的操作系统包括L3操作系统和Mach操作系统，这两个系统均为微内核（MicroKernel）架构，微内核相较与Monolithic的单内核严重依赖IPC通信，所以该文整体目标就是提升IPC通信的速度。

1. 该篇文章在L3操作系统上进行设计，该系统有以下特点：

1. 上的一个task（进程）数据结构包含了线程和内存对象，内存划分为地址空间和数据空间，由地址空间索引相关数据。
2. L3操作系统内核的IPC通信非常直接，采用一个全局线程和任务唯一标号协同实现IPC。
3. 逻辑和物理设备驱动都是在用户态的task（进程），他们之间的通信完全依靠IPC。

2. 研究、设计原则

1. IPC速度是提升目标，但是其它性能指标不可被严重影响
2. 一切设计需要被落地并评估
3. 如果某些表现太差，寻找新的技术
4. 协同效应需要被考虑，技术之间的关系，影响
5. 设计需要覆盖所有的架构、并且落地到代码
6. 设计必须基于一个具体的理论
7. 设计需要有一个具体的目标

3. 性能目标

测试场景：以一个空消息传递过程为例，threadA通过IPC发送给threadB一个空消息，两个线程均在用户态下，存储在不同的地址空间，他们通信的过程描述如下：

---

name	operating process
thread A(user mode)	1. load id of B 2. set msg length to 0 3. call kernel
kernel	1. access thread B 2. switch stack pointer 3. switch address space 4. load id of A 5. return to user
thread B(user mode)	1.inspect received msg

---

    所有的操作都忽视参数传递、测试、调度以及传递非空信息时所需操作。虽然这个例子不是那么的现实，但是对于本文测试IPC而言，是很好的用例。
    假设完全没有读写延迟以及cache不中，这些操作大概需要127个cycles（应该是时间片吧），其中107个cycles都是因为陷入内核和离开内核所造成。因为486的MMU（memory manage unit）在改变地址空间的时候会刷新，产生至少5个TLB的miss，每个miss大概产生9个cycles，所以这个例子以127+5*9=172作为ipc通信最小值。因此，当开始实验之前，我们目标达到每个消息传递消耗350个cycles，实际上，最终我们获得了250个cycles的实验结果，大概5μ秒，这个时间记为T。

二、从架构层分析设计进行优化

    架构层面的改进方法包括1）系统调用的同步转异步。2）对IPC传递消息划分，分为三个部分，直接消息、间接消息和内存对象。3）避免消息传递拷贝而采用地址临时映射，直接将指向的数据空间指向到消息源&