Operating Systems
LegoOS: A Disseminated, Distributed OS for Hardware Resource Disaggregation Yizhou Shan, Yutong Huang, Yilun Chen, and Yiying Zhang, Purdue University
作者首先提到了现在（数据中心里面）硬件资源的解聚非常明显，也就是CPU、内存、存储分布在不同的机器上，另外异构化的趋势也越来越明显。作者表示传统的宏内核并不能很好地利用这些资源，因为具体的计算还是由其中一台台机器跑的，受到了机器上硬件资源的限制，然后提出了splitkernel的概念，把硬件资源分成三种类型：计算、内存、存储，彼此之间用RDMA进行通讯，然后就可以想用多少资源就用多少资源。然后作者实现了LegoOS，还能兼容Linux API，跑了下benchmark性能和现有的宏内核大抵相当。这个想法看起来还是很有意思的，相当于自动把一个程序变成分布式的了。不知道怎么做的，我觉得这三种资源的抽象都需要每台机子上的CPU+内存来跑，就有点像轻量级的hyperviosr？另外作者说放弃了coherence，那是不是意味着开发者写多线程程序、共享内存的时候就要格外小心？以及不知道网络带宽和延迟的影响有多大。
The benefits and costs of writing a POSIX kernel in a high-level language Cody Cutler, M. Frans Kaashoek, and Robert T. Morris, MIT CSAIL
作者对比了用Go和C写操作系统内核有什么区别，里面主要提到的是：内存分配以及其中的安全问题（double free / use after free / out of bound access)，以及如何避免内核的堆内存不够用，以及goroutine写起来很爽。论文也提到了用Go写内核的一些挑战：比方说垃圾回收会 stop the world。最后得出来的数据是用Go写大概比用C写慢15%左右。虽然标题说的是 high-level language，但是实际上作者只提了Go，并没有泛化到所有 high-level language。不同的语言特性差别非常大，我觉得这篇文章只能代表Go的经验。作为Rust粉，我觉得如果要用一个高级语言来写内核，那也应该用Rust。
Sharing, Protection, and Compatibility for Reconfigurable Fabric with AmorphOS Ahmed Khawaja, Joshua Landgraf, and Rohith Prakash, UT Austin; Michael Wei and Eric Schkufza, VMware Research Group; Christopher J. Rossbach, UT Austin and VMware Research Group
这个工作的动机是现在有越来越多的FPGA被部署到了数据中心里面，在未来多租户共用FPGA可能会像现在共用CPU一样普遍。所以作者想要实现一层抽象来：保证多租户环境不会互相干扰、可移植性、以及弹性计算（能够动态地调整所需资源、能放到不同硬件里面跑）。作者提到了说现在有一种技术可以在跑FPGA的同时只对其中的一部分进行重新编程（所以以后可以用在多租户环境？）我完全不懂FPGA，不过感觉这个工作未来应该还是很有用的。
Failures
Capturing and Enhancing In Situ System Observability for Failure Detection Peng Huang, Johns Hopkins University; Chuanxiong Guo, ByteDance Inc.; Jacob R. Lorch and Lidong Zhou, Microsoft Research; Yingnong Dang, Microsoft
一般来说程序都有良好的层次结构，但是但是中的不同部分在互相调用的时候，调用方一般会处理被调用方出错的情况，但是很少会报告这些错误。这篇论文的大体思路就是让程序中的每个线程、每个部件都能够报告调用别的部件的时候的成功或者失败信息，然后根据每个进程会对进程内所有线程的报告进行汇总，根据这些局部的信息推测系统是不是出现了问题。不同进程之间还可以通过交换局部观察来获得更多信息。另外还有一个中心化的服务器可以进行总体的仲裁。
Finding Crash-Consistency Bugs with Bounded Black-Box Crash Testing Jayashree Mohan, Ashlie Martinez, Soujanya Ponnapalli, and Pandian Raju, University of Texas at Austin; Vijay Chidambaram, University of Texas at Austin and VMware Research
这个工作的目的是找文件系统的Crash-Consistency Bugs，感觉思路还是很好的。他们解决的两个核心问题是：没办法方便地测试crash以及状态空间太大。他们搞了一个工具叫做CrashMonkey，在内存里面模拟block device，先跑一遍记下来正常的状态是怎么样的作为oracle，然后再跑一遍跑到 crash point 之后crash掉，然后让文件系统自己去修复，再去跟oracle比较（所以是个block-box?）。他们另外一个非常核心的idea是，只在fsync()之类的检查点之后引入crash，而不是任意的时刻，这样减小的状态空间，而且文件系统的安全性保障本来就只在检查点之后。他们生成 crash point 的时候是有一个 bounded space，比方说 Maximum # of core ops in a workload is three / 2 directories of depth 2, each with 2 unique files / Overwrites to start, middle & end of file, and appends / Start with a clean file-system image of size 100MB。通过这个 space bound 和只在fsync之后crash这两个办法，他们就大大减小了状态空间。
An Analysis of Network-Partitioning Failures in Cloud Systems Ahmed Alquraan, Hatem Takruri, Mohammed Alfatafta, and Samer Al-Kiswany, University of Waterloo
这篇文章并不是做了一个系统，而是对现有的系统做了关于Network-Partitioning Failures的调查，他们找了25个热门的分布式系统，然后去他们的 issue-tracking system 里面找相关的关键字，然后再去归类整理其中的原因。以前的我会觉得这样的工作没啥意思，但现在我觉得还是有意义的，因为这样的调查归类可以提供一个背景知识，让研究人员找到研究的课题。比方说我现在接手的一个项目，想法非常直观，解决方案也非常简单粗暴，但是我就不知道原来这样的问题存在。
Scheduling
Arachne: Core-Aware Thread ManagementHenry Qin, Qian Li, Jacqueline Speiser, Peter Kraft, and John Ousterhout, Stanford University
我觉得这篇文章还是蛮有意思的，文章指出来说给服务（比方说 web server / memcached）的每一个线程分配一个固定的核并不是最优的策略，有时候适当减少服务使用的核心数量还可以增加性能、减少延迟。这点我还真从来没想到过，我觉得作者说的是有道理的。当服务的负载低的时候，服务的这些线程依然会被均匀地唤醒，也就是每个核心的占用率其实都不高，这样的情况下硬件可能会自动进入低功耗模式，然后如果这个时候有大量请求进来的话，从低功耗切换到高性能的延迟还挺大的。另外一点就是，当服务和其他的应用一起跑的时候，两者之间相当于会争抢同一个核，这样造成的额外的上下文切换会影响性能，而且对核内的cache也不友好。所以说文章提出来的方法就是在用户态做一个进程调度。在Arachne的调度之下，每一个线程与一个核绑定。应用可以通过API告诉调度器现在需要多少个核心，然后调度器就可以动态地给应用调整线程的数量。通过给每个应用独占硬件核心，这样就可以减小延迟提升吞吐，当然前提还是应用能正确估计自己需要的资源数量。
µTune: Auto-Tuned Threading for OLDI Microservices Akshitha Sriraman and Thomas F. Wenisch, University of Michigan
作者首先指出来传统的网站架构把各个组件耦合在一起，一般有很长的SLO(>100ms)，而近十年来微服务兴起，各个组件通过RPC交互，因此要求sub-millisecond级别的SLO。而RPC本身也会带来巨大的（microseconds）开销，作者指出来这上面其实花在线程调度的时间也非常可观。作者把服务的处理请求的方式分成了8类，根据以下三个方面：(1) Poll vs Block（在接收连接的时候是忙询还是block住） (2) In-line vs Dispatch（收到请求之后是直接在当前线程处理还是丢给worker pool处理） (3) Sync vs Async（处理请求的时候）。作者给了一个结论就是静态地固定了 threading model 会严重的影响性能，所以他们搞出来这么一个µTune（应该就是API+runtime)，能够根据负载自动地改变threading model。我觉得这个工作还是有道理的，因为在特别在意latency的情况下，或许线程调度真的很慢？
Data
Noria: dynamic, partially-stateful data-flow for high-performance web applications Jon Gjengset, Malte Schwarzkopf, Jonathan Behrens, and Lara Timbó Araújo, MIT CSAIL; Martin Ek, Norwegian University of Science and Technology; Eddie Kohler, Harvard University; M. Frans Kaashoek and Robert Morris, MIT CSAIL
这篇文章把数据库中常用的一个技术 materialized view 应用到 web applications 里面，也就是把计算的中间结果保存起来，增量更新。这个工作主要解决了几个问题：change queries at live, bounded memory footprint, no global coordination。（虽然没太听懂怎么做的，但是人家是用 Rust 写的，点个赞）感觉这个作品可能要看一下论文，从evaluation来看，里面可能有一些没说的东西。如果没啥catch的话，我猜这个作品应该是个好的工作？所以这个工作好像是个新的数据库？
Deconstructing RDMA-enabled Distributed Transactions: Hybrid is Better! Xingda Wei, Zhiyuan Dong, Rong Chen, and Haibo Chen, Shanghai Jiao Tong University
这篇文章讨论了 database transactions 哪种RDMA primitive比较好。从论文里面我大概了解了一下，one-sided primitive 好像就是直接读远端服务器内存，而 two-sided primitive 好像就是在RDMA上面的RPC。作者举了一个例子，比方说读取一个 key-value store，如果是 one-sided primitive，那么要进行两次通信，一次进行 lookup，（然后在本地计算？）然后第二次再把数据拉下来；而如果是 two-sided primitive，直接一次通信，远程的CPU会参与计算，然后直接返回数据。最后结论是hybird design，在transaction的不同阶段（execution, validation, logging, commit）用不同的 primitive。我完全不懂RDMA，但是无脑给交大陈海波组点个赞。
Dynamic Query Re-Planning using QOOP Kshiteej Mahajan, UW-Madison; Mosharaf Chowdhury, U. Michigan; Aditya Akella and Shuchi Chawla, UW-Madison
这篇文章的动机是，在云计算平台上，计算资源的数量会波动（比方说 AWS Spot Instance），所以说他们就想要根据计算资源的波动动态地调整分布式数据库的 query plan。一个核心科技就是检查点，把计算结果按照 query plan 的阶段保存下来，然后如果计算资源突然变化了，就可以放弃原先 query plan 执行到一半的结果，然后直接载入检查点，执行新的 query plan。感觉确实是有这样的需求的，这个idea应该还是不错的？不是做数据库的不是很懂。
Focus: Querying Large Video Datasets with Low Latency and Low Cost Kevin Hsieh, Carnegie Mellon University; Ganesh Ananthanarayanan and Peter Bodik, Microsoft; Shivaram Venkataraman, Microsoft / UW-Madison; Paramvir Bahl and Matthai Philipose, Microsoft; Phillip B. Gibbons, Carnegie Mellon University; Onur Mutlu, ETH Zurich
作者首先讲了两种（监控）视频处理的传统方法：在视频采集的就跑CNN然后把结果存进数据库，这样查起来开心但是采集的时候需要的计算量很大，非常贵；另外就是直接存视频，直到需要调监控的时候再跑CNN，这个的缺点是太慢（latency大）。他们提出了2个技巧：1. Approximate index via cheap ingest at ingest time （在采集的时候就跑一个 cheap CNN 来生成一个不准确的结果，然后保存 top-k 的结果来降低 cheap CNN 的不准确性的影响）2. Redundancy elimination （feature vector 差不多的图像看起来也差不多，在跑 cheap CNN 的时候把 feature vector 跑一个聚类，算出来cluster的中心，保存在 index 里面，后面跑 expensive CNN 的时候，只要算一个，就可以把 label 应用到整个 cluster 里面了）总的来说就是一些针对视频处理的工程优化，虽然感觉并没有什么特别大的 research novelty 或者科研价值，但是感觉这几点优化听起来都非常有道理。
Reliability
Maelstrom: Mitigating Datacenter-level Disasters by Draining Interdependent Traffic Safely and Efficiently Kaushik Veeraraghavan, Justin Meza, Scott Michelson, Sankaralingam Panneerselvam, Alex Gyori, David Chou, Sonia Margulis, Daniel Obenshain, Shruti Padmanabha, Ashish Shah, and Yee Jiun Song, Facebook; Tianyin Xu, Facebook and University of Illinois at Urbana-Champaign
作者上来先举了两个影响到Facebook的飓风的例子，抛出来一个问题：Can we run Facebook without one of our data centers? 在数据中心迁移的时候，要把流量转移到别的数据中心，Facebook 里面跑的都是微服务，就要处理好微服务之间的依赖关系（这些流量不能一下子迁移完，因为有的请求是有状态的，有的请求偏好在同一个数据中心处理）。从 big picture 来看，他们说了三个点：Dependence（要追踪微服务的依赖关系）, Automation（自动化地迁移）, Validation（验证迁移方案是否有效）。QA有人问了 geo-replication 不能解决问题吗，作者说 geo-replication 使得他们能做这样的迁移，但是他们想要 gracefully 地迁移（不让用户感知），所以需要这些额外的机制。感觉大公司面对的问题还是非常有意思的，但是可能这里面牵扯到的细节比较多，感觉talk里面只讲了讲 big picture 的东西，我觉得论文还是值得回去看一下的。
Fault-Tolerance, Fast and Slow: Exploiting Failure Asynchrony in Distributed Systems Ramnatthan Alagappan, Aishwarya Ganesan, Jing Liu, Andrea Arpaci-Dusseau, and Remzi Arpaci-Dusseau, University of Wisconsin - Madison
作者先提出来说有两 consensus 方案：一种是放硬盘的（Paxos / Raft），一种是放内存的（NoPaxos），两者分别站在 reliability 和 performance 两边，作者就说我们能不能搞个又可靠又高性能的。所以他们搞了一个系统，在节点多的时候就用内存来提高性能，在有节点挂掉的时候就赶紧写到硬盘。之所以着急着写硬盘，作者是怕在挂了一两个节点之后一群节点一块挂掉了（比方说交换机挂了？）？这个思路也是很经典的，现在有两种方案分别站在两个 spectrum 的两边，那我们就搞一个折中的方案。具体的没怎么听懂，感觉还是需要学习一下 consensus protocol，然后回来看一下这篇论文，我猜里面应该会写为啥这么搞是对的？
File Systems
Pocket: Elastic Ephemeral Storage for Serverless Analytics Ana Klimovic and Yawen Wang, Stanford University; Patrick Stuedi, Animesh Trivedi, and Jonas Pfefferle, IBM Research; Christos Kozyrakis, Stanford University
作者提出了对于Ephemeral Storage的两点要求：1. 对各种大小的object都要有高性能 2. 要能精确计费 3. 不需要容错（因为ephemeral storage生命周期很短，10~100s）。这个工作提供了一系列API，开发者可以指定hints给storage system，比方说是否对latency敏感、并发度如何，然后他们就可以调度怎么存储，里面也有 bin-packing 的算法。我觉得这个工作对于云计算平台及其用户都是有意义的。
Sharding the Shards: Managing Datastore Locality at Scale with AkkioMuthukaruppan Annamalai, Kaushik Ravichandran, Harish Srinivas, Igor Zinkovsky, Luning Pan, Tony Savor, and David Nagle, Facebook; Michael Stumm, University of Toronto
作者首先说现在Facebook的数据量太大了，已经没办法在每个数据中心放一份拷贝了，在这样的geo-distributed system 里面，数据的 locality 就非常重要（减小延迟、节约外网带宽）。他们提出了一个 micro shard 的概念，相比传统的 shard（几十GB），micro shard 一般只有几十MB，而且包含了一定程度的 locality。好吧，没听懂这个哥们在讲啥……这个 locality 是怎么挖掘的？micro shard 跟把 shard 大小调小有什么区别？
FlashShare: Punching Through Server Storage Stack from Kernel to Firmware for Ultra-Low Latency SSDs Jie Zhang, Miryeong Kwon, Donghyun Gouk, Sungjoon Koh, and Changlim Lee, Yonsei University; Mohammad Alian, UIUC; Myoungjun Chun, Seoul National University; Mahmut Taylan Kandemir, Penn State University; Nam Sung Kim, UIUC; Jihong Kim, Seoul National University; Myoungsoo Jung, Yonsei University
这篇文章的动机是数据中心中有非常多对 I/O latency 敏感的应用，比方说 web server，但是简单地把硬盘换成低延迟的SSD并不能显著地解决问题。这篇工作在内核和NVMe控制器层面做了一些优化：1. Bypass 内核的 multi-queue block layer 来减小延迟 2. 单独增加一个 latency-critical submission queue，优先处理延迟敏感的请求 3. 把NVMe控制器里面的cache控制暴露给内核，这样内核可以动态地、更细粒度地进行调度 4. 新增了一个内核的中断机制，对于对延迟敏感的应用，可以用 polling 而不是 signal 的方式来减少传统 interrupt 穿过内核各个 layer 的延迟。我对内核的 storage stack 并不了解，对 NVMe 协议和SSD也并不了解，但感觉这些办法看起来很有道理。
Debugging
Orca: Differential Bug Localization in Large-Scale Services Ranjita Bhagwan, Rahul Kumar, Chandra Sekhar Maddila, and Adithya Abraham Philip, Microsoft Research India
这个工作的动机是，现在非常普遍的一个production系统上线流程是：code、build、deploy、mointor，出了问题叫 on-call engineer 找出来 bug commit 是哪个，然后 revert 掉，这个要花好几个小时的时间，而且随着代码库越来越大，这个事情越来越难。所以他们早了一个用来找buggy commit的工具。几个核心的方法是：1. Differential Code Analysis（AST层面的分析） 2. Build Provenance Graph（异常监控可能不及时，有的bug可能只跟特定的机器/软件环境有关系，这个Provenance Graph横轴是时间或者说部署的commit版本，纵轴是机器/软件环境的cluster） 3. Commit Risk Estimation（考虑 Developer Experience, Commit complexity, …）最后他们这个系统可以告诉 on-call engineer 有哪些 commit 是有可能导致bug的。总之，这个系统实际上是作为人的辅助工具，而不是直接自动化地找出来问题，所以有很多启发式的、近似的方法。
Differential Energy Profiling: Energy Optimization via Diffing Similar Apps Abhilash Jindal and Y. Charlie Hu, Purdue University
作者首先说现在应用市场上同一种类型的应用有很多（比如音乐应用），比较相似的应用可以发现他们各自的电池消耗还是各有不同的。作者说可以比较不同应用的 calling context tree（这是啥？好像是把 call tree 里面具有相同 execution path 的节点合并、把递归调用合并？），然后就可以知道每个函数的电池消耗（就像cpu profile那样）。然后他们就有各种各样奇妙关于的 tree matching 算法，以及各种优化……然后就可以生成一个可视化的结果，帮助开发者了解为啥我的应用这么耗电。感觉这个脑洞感觉非常大。。。
wPerf: Generic Off-CPU Analysis to Identify Bottleneck Waiting Events Fang Zhou, Yifan Gan, Sixiang Ma, and Yang Wang, The Ohio State University作者先丢出来一个让大家做优化的时候都非常抓狂的问题：Where is the bottleneck?作者说 off-CPU analysis
主要是在分析是什么事件阻挡了执行，on-CPU analysis 主要是分析执行过程中的瓶颈（我觉得就是 CPU profile？），但是到目前为止没有任何 off-CPU analysis 可以准确地分析出来所有的 waiting event。另外，同样是 waiting event，有的造成的是局部的影响，有的会造成全局的影响，有的时候哪怕造成非常大的局部影响，也不一定会影响到全局的性能。然后他们的工具可以构造出来一个叫做 wait-for graph 的东西，然后他们在这个图上面开发了性质，比如说怎么一个结构一定代表了一个瓶颈，然后他们又开发了一些优化、化简这个图的方法。然后他们就可以找到一些以前找不到的瓶颈了。
Machine LearningRay: A Distributed Framework for Emerging AI ApplicationsPhilipp Moritz, Robert Nishihara, Stephanie Wang, Alexey Tumanov, Richard Liaw, Eric Liang, Melih Elibol, Zongheng Yang, William Paul, Michael I. Jordan, and Ion Stoica, UC Berkeley
作者首先表示目前的AI生态环境是AI的各个功能组件都各自构建一个 distributed system（比方说model training (TF), model serving (Clipper), data processing (MapReduce)……）有些AI应用需要紧密结合各个部分，比如RL，所以他们就搞了一个统一的框架来处理所有这些事情。对于stateless的计算，直接描述计算图就行了。对于stateful的计算，用户需要用一个类(Actor)包起来，然后用 python decorator 修饰一下，调用的时候就变成了返回 future（所以这个global state是怎么保存的？）。作者还讲了 fault tolerance 和 horizontal scalability，没太明白，还得看一下论文。现在大家都喜欢造DSL，不过我觉得计算图造DSL真的是一件非常自然、对开发者非常友好的事情。
PRETZEL: Opening the Black Box of Machine Learning Prediction Serving SystemsYunseong Lee, Seoul National University; Alberto Scolari, Politecnico di Milano; Byung-Gon Chun, Seoul National University; Marco Domenico Santambrogio, Politecnico di Milano; Markus Weimer and Matteo Interlandi, Microsoft
作者首先指出来目前的 machine learning serving system 都是把 model 当作一个黑盒，这造成几个问题：1. Resource waste（不同的model共享的部分） 2. Inconsideration for operators’ characteristics 3. Lazy initialization（training的时候有用，但在prediction的时候严重拖慢了latency）。作者提出了两种优化方法：1. End-to-end model optimization（ahead-of-time 编译） 2. Multi-model optimization（共享相同的参数、共用中间结果）具体的方法还要看一下论文，不知道这种 white-box 的方法会不会让 scheduler 的适用范围非常受限？
Networking
Splinter: Bare-Metal Extensions for Multi-Tenant Low-Latency Storage Chinmay Kulkarni, Sara Moore, Mazhar Naqvi, Tian Zhang, Robert Ricci, and Ryan Stutsman, University of Utah
作者首先提到了 kernel-bypass KV database 性能虽然很好，但是功能太过于简单，所以说应用可能需要花费多次查询，因此要支付多次网络通信的代价，简单的高性能 KV database 并不一定真的能导致应用的高性能。这个工作也是一个 KV database，但是开发者可以动态地向上面添加用rust（点个赞）写的extension，这样在 database 上面就可以做负责的查询，减少因为多次网络通信带来的代价（听起来有点像redis上面跑lua？）。作者有几个技巧：work stealing（CPU core 可以从隔壁 core steal work，减少 hotspot）；run extensions in stackless coroutines 来减少 context switch 的代价；要求 long running tasks frequently yield，防止其他任务被饿死；用一个 watchdog worker 来检查 tasks 是否经常 yield，把不听话的 extension 丢到低优先级队列里面甚至直接杀掉；跨越 trust boundary（Splinter和extension之间）的时候零内存拷贝（主要是Rust的一些技巧？没仔细讲）我觉得这个在数据库上跑计算这个思路应该是很老的思路了，可能这篇工作的novelty是保证多租户（不信任）的环境下面怎么保证安全性？
Neural Adaptive Content-aware Internet Video Delivery Hyunho Yeo, Youngmok Jung, Jaehong Kim, Jinwoo Shin, and Dongsu Han, KAIST
作者首先指出在网络条件不好情况下，现在的技术可以自动降低视频流的质量，然后又说了移动设备的计算能力近些年疯狂增长，所以说他们就提出了可以在客户端跑DNN增强画质。作者说有两个挑战：1. DNN accuracy is unreliable for new content（在服务器针对各种各样的content训练相对应的model，然后实现一个 content-aware model） 2. Client must process DNN at real-time, but computation power varies among devices（训练不同大小（不同复杂程度？）的model，根据设备的计算能力选择相适应的model）。作者还有几个额外的技巧：1. 训练跳帧的model，客户端可以先下载到DNN增强过的跳帧，然后再去补齐中间的DNN增强过的帧 2. 把DNN下载和动态比特率调整结合起来。（有点没明白作者说的下载DNN是啥意思）感觉这个工作非常实用，值得一看。
