[论文笔记]LegoOS：一种硬件资源分解的分布式操作系统

LegoOS: A Disseminated, Distributed OS for Hardware Resource Disaggregation

    文章设计了一种新型的操作系统架构—splitkernel：将处理器、内存、外存在网络上分开，所有信息交互均通过网络的形式进行。这是一种新型分布式系统，这样做的好处有：

1. 避免了水桶效应，即由于部分硬件的性能限制，使其它硬件性能无法充分发挥。
2. 易于增加或减少硬件，即拥有较好的可扩展性。
3. 避免部分硬件故障导致整体不可用。
4. 解决异构硬件难以兼容问题。

    splitkernel的实现基于一些技术的发展：网络技术。网速飞速发展，InfiniBand即将达到200Gbps的带宽和600 nanosecond的延迟。RDMA技术和新型交换机技术，网络拓扑使硬件访问网络更快；网络接口更接近硬件层，使硬件可以不经过处理器而直接访问网络；硬件本身的计算力提升。

splitkernel的整体架构

    其中每个硬件作为网络上单独的一个模块，由一个monitor进行管理。对于非CPU模块，其monitor一般是一个低性能的通用核，如ASIC或FPGA。
LegoOS 是基于该splitkernel开发的操作系统，支持Linux的系统调用。LegoOS目前只支持CPU，内存(DRAM)，外存(HDD, SSD)三类硬件，分别称为pComponent, mComponent, sComponent。除了这三类组件，LegoOS还拥有全局资源管理系统，可以对所有组件进行管理，包括组件分配，回收。
    对用户而言，他在LegoOS上使用的虚拟机器称为vNode，用户并不知道具体使用了哪些物理硬件。一个vNode可以使用多个pComponent, mComponent, sComponent，同时，一个pComponent/ mComponent/ sComponent也可以被多个vNode同时使用。

pComponent与mComponent的架构

    所有与内存相关的操作尽量交给mComponent完成，因此TLB配置在mComponent中。同时，为了尽可能减少网络通信，pComponent拥有较小的内存(如4GB)，作为最底层的Cache，称为ExCache。由于局部性原理，pComponent需要的大部分数据都可以从Excache中得到。

处理器资源管理

    当一条新的进程出现时，LegoOS使用全局策略选择一个pComponent负责该进程的执行。在该pComponent中，monitor找到负载最小的CPU core执行该进程。当CPU访问ExCache出现miss时，根据信息使用RPC从相应mComponent中获取数据并写入某ExCache行。若ExCache已满，使用FIFO或LRU策略替换ExCache行。

内存资源管理

    所有mComponent的内存单元组成一个虚拟地址空间。一个应用程序可以申请多个mComponent的内存空间，其中有且仅有一个mComponent称为该应用程序的home mComponent，作为该程序的内存优先分配。当一个新进程出现时，LegoOS使用全局内存管理(GMM)指定该进程的home mComponent。
    虚拟内存空间被分割为若干固定大小的虚拟区块，称为vRegion。若某vRegion已被分配，则称为active vRegion。每个vRegion有一个mComponent作为它的owner，表示该vRegion的物理位置在该mComponent中。vRegion可以进一步细分为若干virtual memory area(vma)。
    所有mComponent都保存一个数组vRegion array，该数组指出所有vRegion的分配情况以及其owner编号。若vRegion的owner为该mComponent，则额外保存一个vma tree，用于保存vma的信息。
    应用程序的一次内存分配申请流程如下：pComponent接到内存分配请求后，向home mComponent(mComp1)发出请求(①)，若mComp1没有足够的空间，则向GMM请求帮助(②)。GMM找到合适的mComponent(mComp2)并告知mComp1(③)。mComp1向mComp2发送内存分配请求(④)，mComp2分配内存空间后向mComp1回复完成(⑤)。mComp1向pComponent回复分配完成通知(⑥)。
    pComponent保存了home mComponent的vRegion array的副本，此后可以直接根据数组信息访问对应mComponent (a,c)。
    LegoOS在mComponent中为每个vma设置了log，记录数据变化情况。为了增加容错性，vma的log除了在本地mComponent(primary)保存，还在另外一个mComponent(secondary)保存，同时在某sComponent中也进行了存储。若primary mComponent故障，secondary mComponent可以根据log重新执行一遍操作，恢复该vma的内存数据。
    这里LegoOS引用了一项内存分配的优化技术。当应用程序申请内存分配时，仅在本地的ExCache分配该空间(p-local lines)，作为临时内存空间。只有当此p-local lines需要被置换出ExCache时，才实际地在某mComponent中分配内存并写入该数据。这种方式大大降低了内存分配申请操作需要的时间。

外存资源管理

    关于外存资源管理，LegoOS使用哈希表进行文件名-存储地址映射，其中文件的绝对路径作为key，文件在sComponent中的起始地址作为value。为了加快访问速度，每个sComponent在某mComponent中拥有一块缓存。用户进行文件读操作时，pComponent向对应的mComponent中发送请求。若mComponent的缓存中存在则直接返回该数据，否则mComponent从目标sComponent中获得该数据，写入缓存中并返回给pComponent。
    关于全局资源管理，LegoOS设置了GPM, GMM, GSM分别对pComponent, mComponent, sComponent进行管理。全局管理只进行粗粒度的资源分配，细粒度分配交给相应Component的monitor。全局管理会定期地与所有对应的Component进行通信，以获取其当前计算/存储负载，从而在执行分配时选择合适的Component。