摘要

我们提出了ghOSt, 是将内核的调度决策委托(delegate)给用户态代码的基础设施。ghOSt旨在支持我们数据中心工作负载和平台快速演化(evolve)的需求。

改进调度决策可以显著地(drastically)提高重要工作负载的吞吐量、尾延迟、扩展新和安全性。然而内核调度器很难在大型的机群(in large feet)中实现、测试和部署。最近的研究表明自定义数据平台操作系统中的定制的(bespoke)调度策略可以在数据中心环境(setting)中提供令人信服(compelling)的结果。然而事实证明，在应用程序粒度上部署自定义的OS镜像是不切实际的，特别是在多租户的环境中，这使得上述收益(gains)难以实现，从而限制了这些新技术的实际应用。

ghOSt提供状态封装(encapsulation)、通讯和action机制, 允许在用户空间的代理中负载的复杂的表达调度策略，同时协助同步。程序员可以在使用任何语言来开发和优化调度策略，并且无需重启主机即可修改。ghOSt支持广泛的调度模型，从单CPU(per-CPU)到集中式(certralized), 从完成调度到抢占调度(run-to-completion to preemptive), 并且调度的action只产生(incurs)很低的开销. 我们展示(demonstrate)了ghOSt在学术(academic)和真实场景的工作负载上的性能, 包括Google Search和Google Snap。结果表明，使用ghOSt而非内核调度器，可以快速的实现相当的(comparable)吞吐量和延迟，同时为我们数据中心的工作负载启用策略优化、不中断(disruptive)更新和故障隔离。

1 Introduction

CPU调度在应用程序的性能和安全性方面发挥着重要的作用。针对特定工作负载类型定制(tailoring)策略可以显着(substanttially)改善关键指标，例如延迟、吞吐量、硬/软实时特性、能源效率、缓存干扰(interference)和安全性 [1-26]。比如，Shinjuku 的请求调度器 [25] 优化了高度分散(dispersive)的工作负载——混合了短请求和长请求的工作负载——将请求尾部延迟和吞吐量提高了一个数量级(by an order of magnitude.)。用于虚拟机工作负载的 Tableau 调度程序 [23] 在多租户场景下，吞吐量提高了 1.6 倍，延迟提高了 17 倍。 Caladan 调度程序 [21] 专注于前台低延迟(low-latency)应用程序和后台尽力(best-effort)服务应用程序之间的资源干扰，将网络请求尾部延迟提高了 11,000 倍。为了缓解(mitigate)最近的硬件漏洞[27-32]，运行多租户主机的云平台必须快速部署新的核心隔离（core-isolation）策略，以隔离应用程序之间的共享处理器状态。

在大型机群中设计、实现和部署新的调度策略是一项艰巨(exacting)的任务. 他要求开发者设计能够(capable of)平衡许多应用程序特定的性能需求的策略。实现必须合乎（conform with）复杂的内核架构，在很多情况下，错误会导致整个系统崩溃，或者由于意外(unintended)的副作用(side effects)而严重的(severely)影响(impede)性能. 即使成功，升级的中断特性(disruptive nature)也会带来主机和应用程序停机时间(downtime)的机会成本(opportunity cost)。这在风险最小化(risk-minimization)和技术进步(progress)之间产生了极具挑战性的冲突(conflict)。

之前通过设计用户空间解决方案来提高性能和内核复杂性的尝试存在很大的缺陷：他们需要对应用程序的实现进行大量的修改[1, 10, 21, 25, 34, 35], 需要专用(dedicated)资源才能具有高响应性 [1, 21, 25]，否则需要特定于应用程序的内核修改 [1, 2, 10, 21, 25, 34-37]。

虽然 Linux 支持多种调度实现，但是为每个应用程序定制(tailoring)、维护和部署不同的机制对于管理大型机群是不切实际的。我们的目标之一是在稳定的内核 ABI上正式确定(formalize)需要哪些内核更改才能在用户空间中进行大量的(enable a plethora of)优化（和实验）.

此外，硬件环境在不断变化(hardware landscape is ever-changing)，强调(stressing)现有的调度抽象模型 [38] 最初(originally)旨在管理更简单的系统。调度程序必须不断发展(evolve)以支持这些快速变化：增加核心数量、新的共享属性(properties)（例如 SMT）和异构(heterogeneous)系统（例如 big.LITTLE [39]）。即使是单插槽(single-socket)平台的 NUMA 属性也会继续增加（例如，chiplets [40]）。AWS Nitro [41] 和 DPU [42] 等计算卸载(Compute offloads)以及 GPU 和 TPU [43] 等特定领域(domain-specific)加速器是完全超出(beyond)经典调度程序领域的新型紧密耦合计算设备。我们需要一种范式(paradigm)来更有效地支持不断发展的问题域(problem domain)，而不是现在使用单片(monolithic)内核实现。

在本文中，我们介绍了 ghOSt 的设计及其对生产和学术用例的评估。ghOSt 是用于本机操作系统线程的调度程序，它将调度策略决策委托给用户空间。ghOSt 的目标是从根本上改变调度策略的设计、实施和部署方式。ghOSt 提供用户空间开发的敏捷性(agility)和部署的简易性(ease)，同时仍然支持 𝜇s 规模(𝜇s-scale)的调度。ghOSt 为用户空间软件提供抽象和接口，以定义复杂的调度策略，从每个 CPU 模型到系统范围（集中式）模型(per-CPU model to a system-wide (centralized) model)。重要的是，ghOSt 将内核调度机制与策略定义分离。 该机制驻留在内核中，很少更改。 策略定义驻留在用户空间并迅速变化。 我们开源了我们的实现，以支持使用 ghOSt [44, 45] 进行未来的研究和开发。

通过调度本机线程，ghOSt 无需任何更改即可支持现有应用程序。 在 ghOSt（图 1）中，调度策略逻辑运行在普通 Linux 进程中，称为(denoted as)代理，它们通过 ghOSt API 与内核交互(interact)。内核通过异步的消息队列（message queues (§3.1)）来通知代理其所管理的线程的状态改变，如线程的创建、阻塞、唤醒等。然后

代理使用基于事务(transaction-based)的同步API来提交线程的调度决策(第 3.2 节)。ghOSt 支持多个策略的并发执行(concurrent execution)、故障隔离以及将 CPU 资源分配给不同的应用程序。重要的是，为了使机群中的现有系统能够实际过渡（practical transition）到使用 ghOSt，它与在内核中运行的其他调度程序共存(co-exists)，例如 CFS（第 3.4 节）。