尽管为数据库管理系统（DBMS）优化的定制操作系统内核这一概念由来已久，但由于硬件兼容性要求，以及用户对安装专用操作系统的抵触，该想法在很大程度上并未实现。然而，云计算和数据库即服务（Database-as-a-Service）模式的出现，首次让定制操作系统内核成为现实。在专用操作系统内核架构中，unikernel是一种基于单一地址空间运行，无需通用操作系统提供的高成本进程隔离机制。Unikernel具有消除系统调用开销、直接访问硬件和降低复杂度等优势。通过允许直接与现代硬件原语进行交互，unikernel为开发不受旧API限制的新颖抽象开辟了道路，为协同设计的高性能云原生数据处理系统和操作系统内核的新时代打开了大门(一)

1.1 操作系统与数据库系统

在2021年，Timothy Roscoe将操作系统定义为：“一种软件，它复用机器的硬件资源，抽象硬件平台，并利用硬件保护软件主体之间的隔离”。从本质上讲，操作系统为硬件提供了统一的抽象接口，并隔离了不同进程对硬件的访问。然而，硬件抽象和进程隔离是有代价的，尤其对于高性能数据库系统而言，这类系统需要对硬件进行细粒度控制，以优化性能和资源利用率。因此，长期以来研究者们都认识到，自主定制的操作系统内核能够提供更符合数据库系统需求的操作系统API，从而带来更好的性能。

1.2 定制操作系统内核的局限性

在实践中，为数据库管理系统优化的操作系统内核从未得到广泛采用，主要有以下两个原因：

1.很少有用户会购买一款要求先安装定制操作系统的数据库管理系统。

2. 由于用户的硬件设置各不相同，定制的操作系统必须为大量设备实现和维护驱动程序。

因此，除了少数特定的小众用例，数据库系统只能去适应通用操作系统的限制。

1.3 云计算带来的不同

通过向云计算的转变，能够将在数据库系统中使用定制操作系统内核变得更加现实。如今，数据库系统越来越多地以公共云托管服务的形式提供，而不是将数据库管理系统软件交付给客户进行本地安装。这一转变意味着定制内核只需由数据库管理系统供应商安装，用户无需承担管理负担。

此外，公共云通常只需要支持少数几种硬件设备。例如，亚马逊网络服务（AWS）的弹性计算云（EC2）支持启动定制操作系统内核，在任何最新的EC2实例上运行的数据库管理系统，只需要实现两个驱动程序：用于网络的AWS特定弹性Fabric适配器（EFA）驱动程序；和用于存储的通用NVMe驱动程序。这使得定制内核成为云原生数据库管理系统的现实选择。

1.4 操作系统架构的连续体

操作系统架构在隔离程度上各不相同，有如下几类：

1. 微内核：通过将操作系统组件（如文件系统）分离到不同进程中，实现了最大程度的隔离。

2. 单内核（Linux或Windows）：仅区分用户空间和内核空间，以管理员权限执行容易出错的驱动程序。

3. 基于容器的虚拟化：也属于单体内核类别，因为它依赖于命名空间隔离的重量级进程。

4. 库操作系统和针对云环境的unikernel：将所有组件放置在一个地址空间中，无需特权隔离。Unikernel是本文研究的重点。

1.5 内核集成

作者将unikernel视为云原生数据库系统的理想基础，因为其无隔离特性允许数据库管理系统与内核进行深度集成。在unikernel环境下，任何线程都可以直接访问任何内核数据结构和硬件设备。基于管理程序的虚拟化技术确保了每个虚拟机运行单个服务，从而能够在云端实现租户隔离。对于许多云服务来说，运行像Linux这样的通用操作系统的开销是多余的，因为无需与其他进程或用户进行隔离。因此，unikernel消除了这一不必要的隔离层。

1.6 Unikernel的优势

对于高性能数据库管理系统而言，unikernel具有以下显著的优势：

1.7 新的抽象

尽管unikernel拥有许多显著的优势，但是其最深远的优势，在于它能够突破POSIX API的限制。现有的操作系统API严重限制了设计空间。Unikernel可以基于现代硬件提供的原语（如页表、转换后备缓冲器（TLB）和处理器间中断）来直接、高效地开发新的抽象。

例如，虚拟内存页表变成了一个简单的基数数据结构，可以直接进行操作，而无需依赖昂贵且功能有限的系统调用。对数据处理系统和操作系统内核的协同设计，为开发不受为单核系统和稀缺内存设计的API限制的新抽象，提供了独特的机会。

2.1 传统抽象

操作系统内核的主要任务之一是管理硬件。具体来说，操作系统为硬件提供统一的抽象，并在不同用户之间复用硬件资源。与数据库系统最相关的四种主要硬件资源是：CPU核心、主内存、存储和网络。

在传统模型中，操作系统提供执行线程的抽象，而操作系统调度器会动态地将这些线程映射到CPU核心上。存储和网络I/O通过同步、阻塞的系统调用来完成它们。当一个线程在I/O操作上阻塞时，直到设备通过中断信号通知操作完成，它才会被调度。在这个模型中，操作系统控制所有的调度决策，并接收所有的硬件信号。

2.2 传统抽象曾经行之有效

传统抽象的分工协作

如上图所示，在传统的操作系统抽象之上实现数据库管理系统的一种直接方法是，为每个客户端连接分配一个线程（或进程）。每个线程使用阻塞系统调用，在网络套接字上监听传入的请求。如果有请求到达，操作系统会调度该线程在某个CPU核心上执行。然后，该线程可以处理查询，并最终通过另一个阻塞套接字系统调用将结果返回给客户端。在查询执行过程中，缓冲池页面缺失可能会导致存储I/O系统调用，从而引发额外的上下文切换。

这种模型易于使用，概念简洁，并且清楚区分了对数据库管理系统和操作系统的关注。数据库管理系统严重依赖操作系统提供的抽象。通过阻塞系统调用（以及必要时的抢占式多任务处理），操作系统能够完全控制并确保所有硬件资源得到充分利用。在I/O相对于CPU速度较慢的时代，由于上下文切换开销可忽略不计，这种同步模型非常高效。这种同步模型在历史上非常成功，至今仍是像PostgreSQL这样广泛使用的系统的基础。

2.3 传统抽象在现代硬件上的困境

但是在现代硬件上，这种同步模型遇到了严重的性能问题。首先，现代存储设备速度极快，这意味着I/O堆栈的CPU开销可能非常大。存储设备也具有高度并行性。传统模型的第二个困境是，它没有考虑查询内并行性，而这在拥有数十个CPU核心的现代硬件上至关重要。查询内并行性具有挑战性，因为它打破了客户端连接和线程之间的一对一映射。

2.4 异步I/O和工作线程调度

为了解决同步I/O和查询内并行性带来的挑战，现代高性能数据库系统会自行调度I/O请求和CPU核心。为此，它们为每个CPU核心启动一个工作线程，依赖异步I/O接口，并避开操作系统提供的软件RAID和文件系统等服务。

在这种模型中，数据库系统必须决定为每个查询使用多少个线程，这意味着它需要一个调度器，理想情况下，该调度器要考虑其他当前正在运行的查询，以及它们是I/O密集型还是CPU密集型。数据库管理系统还必须管理I/O请求，而操作系统则变成了一个单纯的中介，将异步请求传递给异步硬件设备。这些调度和I/O决策曾经是操作系统的主要职责，但是在现代硬件上，实现良好性能的唯一途径是通过底层操作系统接口，这将大部分责任推给了应用程序。因此，操作系统不再履行其作为应用程序和硬件之间协调者的传统角色。

2.5 内核旁路 

现代数据库管理系统的内核旁路操作

现代I/O设备的高带宽仅将数据传输到CPU就会导致大量的CPU负载。这促使了使用用户空间库（如用于网络的DPDK和用于存储I/O的SPDK）来绕过操作系统的趋势。如图所示，在高吞吐量情况下，它可以显著降低CPU负载。然而，用户空间I/O依赖轮询而非中断机制，而Linux没有提供将设备中断请求作为异步事件转发到用户空间的方法。当请求率较低时，轮询会浪费CPU周期，并导致不必要的功耗。一些数据平面操作系统提供了一种通用的内核旁路API方法。然而，它们依赖于虚拟化客户操作系统中不可用的硬件特性，或者仍然保留有缺陷的POSIX API。

2.6 结论

传统的同步操作系统抽象设计在现代硬件上无法实现良好的性能。因此，高性能数据库系统不得不自行实现CPU和I/O调度。甚至可以通过用户空间I/O完全绕过操作系统设备驱动程序和更高级别的抽象。然而问题是，如果获得良好性能的唯一方法是在应用程序中完成所有操作，那么使用通用操作系统还有什么意义呢？

Unikernel的DBMS/OS共同设计思想

Unikernel是专门为云计算设计的轻量级操作系统。其主要思想是将应用程序和操作系统内核编译成一个系统镜像，在基于（系统）管理程序的虚拟化环境中运行。如图所示，管理程序允许应用程序在内核模式下运行，并与内核在相同的内存地址空间中执行。这一特性使得unikernel变得简单（代码行数仅为数万行，而非数百万行）且高效（无系统调用开销，无进程/用户隔离成本）。该方法由Mirage系统率先提出，该系统依赖于OCaml编程语言。

3.1 Unikernel的特性

3.1.1 OSv

本文选择了OSv作为unikernel的样例，因其具有良好的多核支持，并且其C++代码简洁、易读且高效。OSv支持x86_64和arm64架构，以及多种虚拟化技术，如QEMU/KVM、Xen等。

在开发过程中，基于unikernel的部署可以使用标准调试器（如gdb）进行调试。在这种设置下，调试器在主机操作系统上运行，开发人员可以轻松检查应用程序和内核代码。在生产环境中，OSv可以在KVM虚拟化的EC2实例上执行，也可以在运行Firecracker的bare-metal EC2实例上运行。前者可能适合处理基本负载，而后者适合以函数即服务的方式处理波动的工作负载。

3.1.2 POSIX与新抽象

前文介绍的OSv可以直接运行许多应用程序，或者只需进行极少的修改。然而，由于POSIX标准庞大且包含许多晦涩的特性，所有unikernel都只实现了POSIX的一个子集。若与Linux实现100%兼容，会破坏unikernel的简洁性。于是作者主张通过在虚拟化云硬件上实现特定于数据库管理系统的新颖抽象，来协同设计数据库管理系统和unikernel。只有unikernel的简洁性，才使得这种方法具有现实可行性。

3.1.3 Unikernel提供新的硬件原语

在unikernel中，数据库管理系统以内核模式运行，可以直接访问（虚拟化的）硬件和原语，而Linux由于其共享机器模型，不会将这些硬件和原语暴露给用户空间。直接且高效地访问这些原语，可以带来了显著的性能。基于unikernel的数据库管理系统可以在保持与虚拟化云环境兼容的同时，利用直接访问原语的机会。具体来说，数据库系统可以利用以下硬件原语：

3.1.4 Unikernel的安全性

由于其简洁性，unikernel的可攻击面大大减少。虽然unikernel可能缺乏标准的安全措施和常见的强化技术，但是攻击者的主要目标是非法访问数据库，而将用户空间漏洞提升到内核空间带来的额外好处有限。因此，数据库安全性主要依赖于应用程序/数据库管理系统的安全性，而非传统操作系统提供的隔离。此外，可以引入硬件辅助隔离，如用于线程或范围隔离的英特尔内存保护键（Intel MPK），以及无需地址虚拟化的特权隔离来对unikernel进行保护。毕竟，广泛使用的操作系统内核也并非没有安全漏洞。

3.2 Unikernel给计算调度带来的机遇

3.2.1 用户空间任务存在的问题

若现代数据库系统想要充分利用现代硬件，就不得不自行调度CPU任务和I/O操作。例如，LeanStore使用固定核心的工作线程，这些线程维护一个用户空间任务队列。当一个任务发生页面缺失时，它会提交一个异步I/O请求，将自己放入队列，然后切换到另一个任务。虽然这种方法效率较高，但它实际上是在用户空间重新实现了操作系统调度器，并且存在两个问题：

1.一个CPU密集型任务可能会垄断CPU核心，因为用户空间调度器无法访问原始的抢占机制。因此，抢占式的用户空间调度必须依赖大量且相对低效的内核支持，来隐藏抢占机制，或者在昂贵的操作系统抽象之上模拟裸机（裸金属）环境。

2.如果用户空间任务意外阻塞，核心将暂时被浪费，因为操作系统不知道其他等待的任务。

3.2.2 Unikernel线程轻量级且支持抢占

由于内核级线程的开销较大，这就体现了用户空间调度的必要性。在unikernel中，用户空间任务和内核级线程没有区别。线程可以自行挂起、操作其他核心上的运行队列、阻止抢占，或者像协程一样交错执行。同时，OSv调度器可以全面了解所有线程，如果某个线程垄断CPU，它可以抢占该线程。Unikernel可以消除操作系统不可见的用户空间任务，避免了调度间隙，使所有逻辑数据库管理系统作业可见，并且数据库管理系统可以跟踪系统资源的利用情况。

3.2.3 感知数据库管理系统的调度

一旦调度器获得对任务的控制权和可见性，就可以解决前文中提出的查询内并行性问题。目前，数据库管理系统必须决定为每个查询使用多少个线程。然而，如果调度器能够要求逻辑作业自行并行化，效果会更好。在这种设计中，思想是将做出良好调度决策所需的所有信息（如CPU负载、I/O利用率、作业优先级等）都集中在一处，获取成本则较低。在unikernel中，这样的调度器更容易实现，因为上下文切换成本低，并且unikernel具备了抢占式中断线程的能力。

3.3 Unikernel给虚拟内存带来的机遇

3.3.1 利用虚拟内存实现功能，而非隔离

通用操作系统主要利用虚拟内存硬件（如内存管理单元（MMU）和转换后备缓冲器（TLB））来分隔用户空间和内核空间，并隔离不同进程。由于unikernel无需进行隔离，它可以提供对虚拟内存硬件的直接控制，并实现新的应用场景。

3.3.2 缓存

通过将虚拟内存页表用作硬件辅助的间接表，虚拟内存可被用于实现高效的缓冲区管理。早期在Linux中可以通过两种方式实现这一点：使用现有的但速度较慢的系统调用（vmcache），或者通过扩展Linux以添加更快的系统调用（exmap）。而在unikernel中，实现这样的缓存设计可以变得更快且更简单。

3.3.3 感知虚拟内存的算法和数据结构

虚拟内存（VM）还被用于实现快照、动态数据结构和可变页面大小。但是这个提议并未得到广泛采用。一个主要原因是在Linux中，VM原语速度较慢且扩展性不佳。比如使用pagemap接口检查一个4GiB区域内的一个随机4KiB页面是否存在，在OSv中，这一操作比在16核CPU上从微秒级提升至纳秒级。一种降低VM操作开销的替代方法是使用大页（2MiB），但是大页对于具有随机访问模式的OLTP工作负载并不总是有益的。因此，可扩展且高效的4KiB VM操作（比如在OSv中）能够支持更多的应用场景。

3.3.4内存分配

VM的另一个应用场景是为中间查询处理结果分配内存，这在内存中查询处理时发生率很高，并且通常需要较大的连续VM范围（例如用于哈希表）。对于此类分配，现有的内存分配器有两种选择：它们可以通过mmap()和munmap()将每个（去）分配操作直接传递给操作系统，这会导致每次新分配后出现按需页面错误。

在Linux中，页面错误的扩展性很差：使用1线程安装一个4KiB页面需要1.05微秒，使用16个线程则需要4.17微秒。通用分配器因此可能会在进程内保留内存，但是由于可变的分配大小反而带来内存碎片化的风险。

在unikernel中，巨大的VM地址空间（≥256TiB）减轻了碎片化问题，并且页面错误处理更快且可能更具扩展性：使用一个无锁的页面错误快速路径来安装一个预分配的帧，在1个线程下需要0.5微秒，在16个线程下需要1.29微秒，比Linux大大加快

3.4 Unikernel给（系统）管理程序带来的机遇

让数据库管理系统访问更低层级的功能，并不一定只停留在内核层面，半虚拟化技术可以将其扩展到管理程序层面。例如，管理程序可以通过操纵操作系统状态来回收超额分配的内存，而无需客户机的干预。数据库管理系统甚至可以将其内存分配器状态暴露给管理程序，从而实现更高效的内存气球技术，进而更有效地进行内存超额配置。通过半虚拟化的CPU热插拔技术，数据库管理系统可以根据需要直接请求额外的CPU核心。通过允许数据库管理系统与系统管理程序交换信息，并动态更改内存和CPU分配，可以提高资源利用率。

3.5 Unikernel给I/O带来的机遇

3.5.1 NVMe存储

如今，几乎所有存储设备都使用标准化的NVMe协议，这意味着存储方面仅需一个驱动程序。NVMe基于队列工作，主机CPU和存储设备都可以访问这些队列。在分配一个或多个提交队列和完成队列并向设备注册后，提交操作仅涉及向提交队列写入数据。一旦I/O操作完成，它将出现在完成队列中，并且通过直接内存访问（DMA），数据将出现在内存中的期望位置。

现代操作系统接口（如io_uring）采用的基于队列的异步I/O模型类似，虽然只是在NVMe队列之上增加了一个队列，却导致了大量的CPU开销。基于unikernel的设计可以直接将NVMe队列暴露给数据库管理系统，绕过这个不必要的层级。

3.5.2 网络

网卡不像存储设备那样标准化。在AWS EC2中，所有现代实例都使用弹性网络适配器（ENA）。网络方面的另一个挑战是，除了低级数据包接口外，数据库系统通常还需要对TCP的支持。TCP的一种替代方案是依赖Fabric适配器（EFA），它支持可扩展可靠数据报（SRD）协议。这是一种基于数据包的可靠但无序的协议。发送的数据包最终会到达，但不一定按发送顺序到达。作者认为，通过将数据库管理系统通信栈与SRD协同设计，可能是避免TCP带来的CPU开销的一种非常好的方式。

3.5.3 中断和电源管理

要在现代存储和网络中实现最高性能，需要采用轮询而非基于中断的I/O方式。轮询的问题在于，当事件发生率较低时，它在功耗方面非常浪费。在低吞吐量场景中，最好切换到中断模式并禁用轮询。与绕过内核的方法不同，unikernel允许根据工作负载动态启用、禁用和路由中断。

4.1 基准测试设置

实验在一个具有16核和12GiB动态随机存取存储器（DRAM）的虚拟机内进行基准测试。在虚拟机内，实验使用Linux（v6.1.0，Debian Unstable）或OSv（8c792811d）作为操作系统。同时，在一台配备AMD EPYC 9554P处理器的物理机上，通过QEMU（v8.0.2）和硬件辅助虚拟化（KVM）来运行虚拟机。

4.2 写时复制内存快照

内存区域的快速快照是一个有用的原语，可用于将只读的OLAP查询与OLTP事务分离。HyPer最初的设计使用fork()系统调用作为快照机制，后续也有研究提出了更细粒度的快照变体。在这些情况下，关键思想都是利用操作系统为OLAP作业创建进程的一致性写时复制快照的能力。尽管基于fork的快照是HyPer最初的关键思想，但由于涉及操作系统开销且缺乏控制，最终该想法被放弃，转而采用基于软件的多版本并发控制（MVCC）。

4.3 微基准测试

在本文的场景中，实验分配一个4GiB的匿名内存映射，n个OLTP线程使用原子性fetch-and-add操作在上面执行随机更新。每3秒实验启动一个并发的OLAP作业，该作业创建一个只读的写时复制快照，随后扫描该快照，累加32位整数；之后，它销毁该快照。在OLAP作业运行时，OLTP线程继续操作主缓冲区，这会频繁引发页面错误，以通过实际副本来解析已建立的写时复制映射。

快照写时复制基准测试

在这个基准测试中，很可能在OLAP作业完成之前，所有写时复制（CoW）映射都已被解析。如图展示了以每秒GiB为单位复制、扫描、更新或销毁的吞吐量结果。

对于实验中的两种基线：

1. Linux：对于Linux，实验使用fork()创建快照，并在一个单独的进程中以单线程运行OLAP作业。Linux每秒可建立60GiB的写时复制映射，而由于Linux的伙伴页面帧分配器扩展性较差，快照销毁速度要慢6倍。在OLAP进程运行时，由于Linux在每次CoW页面错误时都会执行一次TLB清除操作，导致OLTP线程的吞吐量降低了89%。

2. OSv：由于unikernel在设计上不支持fork()，实验为OSv扩展了一个写时复制快照原语，并将其应用于OLTP/OLAP场景。此外，实验引入了另外两种技术，以突出OSv这种unikernel协同设计方法的优势：并行快照和读端TLB无效化。

4.4 并行快照

通过并行快照，加快了快照的创建速度。在Linux中，OLTP线程与快照创建过程竞争页表锁，并频繁引发TLB清除操作，从而减缓了OLAP 线程的快照请求速度。在OSv中，在快照创建过程中，实验让触发CoW错误的OLTP线程协助 OLAP 线程进行创建。在此过程中，OLAP和OLTP线程共享页表写锁，并使用原子指令协调它们的页表复制操作。在通用操作系统中，这样的写锁共享以及从页面错误上下文贡献的CPU时间既难以实现，也不可取。

4.5 读端TLB无效化

对于已快照的区域，实验从页面错误处理程序中移除了全局TLB清除操作，通常这是为了通知其他核心已解析的CoW映射，以避免读取过期数据。在OSv中，数据库管理系统以超级用户模式运行，这允许读取者在访问快照页面之前主动刷新TLB。在基准测试中，只要快照存在，OLTP线程在每次事务中都会执行一次单页TLB无效化操作。在数据库管理系统中，可以将此TLB无效化操作放在缓冲区管理器的fix()操作中。

4.6 实验结果

快照写时复制基准测试

实验结果可以看到基于OSv的unikernel实现优于Linux，主要体现在：

4.7 分配器优化

为了进一步提高快照销毁的性能，实验还尝试对该操作进行并行化。然而，OSv的帧分配器中的竞争甚至降低了吞吐量。因此，实验中创建了一个OSv的NoFree变体，它从测量中移除了分配器，仅将释放的帧收集到一个数组中。实验结果表明，如果所有OLTP线程都提供协助，快照销毁现在与核心数量呈线性扩展，OSv（NoFree）比Linux快约96倍。

4.8 内存带宽

由于页表大小为VM空间的1/512，创建和销毁原语处理页表的速度分别为每秒1.5GiB和2GiB。由于引用计数器更新会引发随机访问模式，这低于峰值内存带宽。通过预取隐藏延迟可以显著加速这些VM操作。因此，尽管OSv已经超越了Linux，但通过使用预取等技术，VM快照的性能还可以进一步提高。

4.9 总结

以快照为例，实验展示了（经过修改的）unikernel（以OSv为例）在操作虚拟内存方面能够实现卓越的性能。并且实验中的优化仅用了不到1000行代码就得以实现。

通用操作系统的抽象与数据库系统的需求之间的矛盾，早在几十年前就已被注意到。尽管有人尝试开发特定于数据库管理系统的操作系统，例如Gamma项目的一部分，但几乎所有广泛使用的数据库系统都依赖标准操作系统。最近的数据库管理系统/操作系统协同设计项目包括DBOS、MxKernel和COD：

1. DBOS：该项目专注于云环境，特别是协调分布式计算节点。目前，DBOS基于Firecracker，并且可以与unikernel相结合。本文提出的想法与DBOS项目具有互补性。

2. MxKernel：该项目强调在异构架构上，不可中断的运行至完成任务，相较于线程在执行查询计划方面具备潜在优势。相比之下，unikernel将考虑所有重要资源（CPU、内存、I/O），并致力于设计云原生数据库管理系统，其中硬件池高度标准化。

3. COD：该项目强调需要“开放操作系统”，并在数据库管理系统和操作系统之间设计新的声明式接口。

作者在总结篇中对云原生数据库的unikernel进行了未来展望：

6.1 云中数据平面的Unikernel

许多云原生系统在内部被分解为多个组件。本文并不试图用unikernel取代所有组件中的Linux，而只是针对对性能关键且资源密集的数据平面部分。在云原生系统中，这个数据平面层通常是一个弹性且资源密集的组件。这使得unikernel的快速启动时间（<1秒）非常有用。这样一种集成的调度方法还能够平衡云提供商的定价模型和前的资源需求。

6.2通过新颖抽象实现性能提升和简化

当今高性能数据处理系统的许多复杂性，数据库系统实际上已经在承担操作系统传统的硬件管理工作，但却没有操作系统所具备的底层工具。而本文设想的基于unikernel的云原生数据库管理系统，具有协同设计的、以硬件为中心的、零成本的硬件接口。其不仅可能实现更高的效率，还可以简化数据库管理系统的关键任务，如CPU调度、内存管理和I/O。

随着时间的推移，新的unikernel级抽象将会出现，这不仅对数据库系统有用，对其他高要求的应用（如高性能计算和机器学习）也可能有用。最后需要提到的是，unikernel不仅可以更高效地利用商用硬件，还可以更有效地利用FPGA、TPU或DPU等加速器。

论文解读联系人：

刘思源

13691032906（微信同号）

liusiyuan@caict.ac.cn