【阅读总结】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）避免消息传递拷贝而采用地址临时映射，直接将指向的数据空间指向到消息源，类似fork()函数的写时拷贝。4）严格过程取向，对于临时运行在内核态的线程应当与用户态无异，一个线程对应一个内核中的TCB+栈空间，虽然会带来巨大的栈空间开销，但是以前为减少内核栈空间的研究实际上是得不偿失的5）利用虚拟地址，虚拟地址连续的特点将带来很多好处。

1. 系统调用(System calls)

    系统调用开销是相当大的，40%T的时间都是内核态与用户态切换导致的，由于C/S的结构下很多操作是同步操作，所以导致了开销巨大，所以引入异步，原文中讲call后reply & receive next在一次IPC过程中，可以将一次的RPC四次系统调用变为两次的系统调用。reply & receive next代替了send(),receive(), call(), reply()（除去非阻塞的这些函数）。

TODO：这里具体的函数，具体API及Linux内部相关实现有待学习总结。
上文中提的IPC和RPC看起来有些混合，是因为他们的关系可视为包含：
远程过程调用RPC强调客户端调用了服务器端具体的函数，所以也可以视为进程间通信IPC的一种。

    由于结合了reply和receive，作为新的原子性操作，C/S的协议也会因此变得简单，因为服务器端可以确定客户端是准备好进行接收的。

---

【学习思考记录】：这里一开始不太理解，向上层应用考虑，可以参考Http1.0和2.0是否存在长连接的区别

---

2. 消息(Messages)

    由于消息传递会导致CPU对地址的频繁切换，消息的频繁读取。所以，将消息统一一次发送能够降低IPC开销。
    L3当中的消息包括direct string(mandatory) 直接字符串、indirect string(optional)非直接字符串和内存对象。其中直接字符和非直接字符串在发送过程中严格拷贝，内存对象传地址。
    非直接字符串存在的意义在于避免用户态下多余的复制操作。例如，在发送消息到显示器驱动的时候，包含的信息可能有操作码、屏幕坐标和具体的消息。编译器会将这些信息放到内存中任何可能的地方，这个时候就是将操作码和屏幕坐标放在直接字符串中，具体消息的内存地址和长度信息放在非直接字符串。

     在消息传递到客户端的时候，客户端通过设置3个buffer去存储这些信息，直接字符串中为指令相关操作，无需存储，非直接字符串和内存对象直接获取地址偏移量即可。由此便避免了复制操作。

---

【学习思考记录】：这里现在看起来非常的理所当然。当时很多设计者大概都想的到，可能是MMU的分页等技术还不成熟吧，导致技术落地有点晚。文中也有说到该设计与Hil提出的QNX类似，与Mach不同，Mach的设计更加适合传递巨大的消息，一般的消息传递开销太大。

BG：“Mach的设计更加适合传递巨大的消息。"???
Q：TODO:更加适合巨大的消息是个什么适合法？？后面也需要学习下Mach的设计。
A： 在读完全文，发现对于大消息可能是采用本文Remark中Dash-like的方式进行快速映射。

---

3. 通过临时映射进行直接传输

    简洁地来讲，IPC通信的本质就是将消息在地址空间上进行复制粘贴操作。IPC通信就是两个通信步骤，A->kernel, kernel->B。由于每一个进程只允许访问自身的地址空间，消息必须以内核作为中介，所以这个过程包含了消息的两次复制(twofold copy)。
    为了避免两次复制，首先可以想到的就是建立buffer，如果kernel中存在一个buffer供使用，那么通过传地址，只会存在一次复制。然而，在当代多线程的操作系统中，外加很多的RPC操作都是同步进行的环境下，每一个客户端都要在执行完后才返回，那么建立buffer这件事情就是多余的。

---

【学习思考记录】：这里不太理解，同步操作无非是认为发送方必须确定接收方收到才返回，文中所述不就是减少了发送接收中的中间步骤吗？？
【读完自己回复】：因为是同步操作，有buffer，同步操作同样需要等待到接收方真正接收完毕或返回错误才能返回。所以Buffer的创建没有意义。

【学习思考记录】：我想上文想要强调的应该是如果实行了该方法，那么整个内核将会忙于为各种进程的IPC通信创建Buffer，复制内容