摘要

计算存储设备（CSD）是包括通用、特殊用途和/或可重新配置的处理单元的存储设备，现在正从不同的供应商那里获得商业化服务。CSD能够运行通常在主机CPU上运行的软件，但在数据所在的存储设备上。因此，带有一个或多个CSD的服务器可以改善处理大量数据的软件的整体性能和能源消耗。
为了促进CSD的研究和采用，本立场文件认为，商业上可用的CSD仍然缺少丰富的功能，应该仔细考虑将其广泛部署在生产数据中心。事实上，现有的CSD忽略了（异质）资源管理问题，没有充分考虑安全性，也没有考虑多用户，也没有考虑数据一致性，更没有考虑可用性。在这里，我们讨论了一些开放性的研究问题，以及几个众所周知的编程模型在多大程度上可以帮助解决这些问题–同时考虑硬件和软件接口的设计。

1. 简介

计算存储（CS）是一种接近数据处理[16]的架构，它使数据在存储设备内得到处理，而不是被传送到主机中央处理单元（CPU）[12]。图1概括了SNIA[11]研究的几种CS架构。

CS架构引入了许多优点。a) 卸载主机CPU–因此，可以安装更便宜的CPU，或者CPU可以运行其他任务；b) 减少数据传输，提高性能–只有必要的数据需要从存储设备传输到CPU，CS设备上的通用或特殊用途的处理元件或可重新配置的单元可以代替CPU处理数据，甚至并行处理。c) 降低能耗–PCIe上的存储设备的总功耗不能超过25W[41]，因此计算存储设备（CSD）上的处理单元只消耗其中的一小部分，而服务器级主机CPU的功耗则在100W左右； d) 保留数据中心的基础设施支出–即。 e., d) 保留数据中心基础设施的开支–即在不需要投资更快的网络的情况下扩展数据中心的性能。

虽然对HDD[12, 34]和SSD[37, 31, 29, 42]的存储内处理的研究分别从20世纪90年代和2010年开始进行，但直到最近CS平台才成为商业上可行的，一些公司已经在销售具有CS功能的SSD–例如三星[9]、NGD[6]和ScaleFlux[10]。尽管CSD在市场上出现，但这些设备的编程和推理都很麻烦，这可能会阻碍它们的广泛采用。事实上，在CSD中没有软件或硬件支持异质资源管理，也没有安全、一致性和一般可用性的考虑。
基于作者最近几年在几个学术界和工业界的CS原型上的工作经验，本文试图回顾最先进的技术，列出CSD最紧迫的开放性研究问题，并分析不同的编程模型在回答这些问题上的适用性–同时不忘仍未准备好的CSD的硬件/软件接口。这项工作的重点是单个直接连接的CSD，存储和计算单元驻留在同一设备上。然而，我们相信同样的发现会广泛适用，比如说智能磁盘阵列控制器。此外，这项工作普遍关注带有通用CPU、专用CPU的CSD，以及带有可重新配置硬件（FPGA）的CSD。因此，在本文的其余部分，我们把所有这些都称为 “处理单元”。

简而言之，我们的结论是，CSD的硬件和软件还没有准备好，在硬件和软件层面上还需要做更多的工作，以充分利用该技术的规模。

2. 背景和动机

计算存储通过减轻必须在存储和计算平面之间传输的数据量，减少了输入和输出的交易互连负荷。因此，它可以更好地服务于现代工作负载，如大批量的大数据分析或人工智能任务，具有更快的性能[27]，以提高数据中心基础设施的利用率[29]，同时还有许多其他好处。我们在下面讨论几个问题。

计算型存储的一个主要好处是更快、更节能的数据处理。计算存储架构将通常由主机计算元素–CPU和最终的加速器–处理的工作卸载到存储设备上。如果没有CS，例如在数据分析的背景下，主机计算元素提出的请求需要将所有的数据从一个存储设备转移到它那里。然后，主机计算元素必须在执行其指定的任务之前减少数据的数量。在CS方法中，存储设备在将数据转移到主计算层进行处理之前，会根据主机请求的相关性对数据进行初步限定。因此，可能会减少需要由主机移动和处理的数据量。每个工作负载的主机计算指令的减少意味着主机CPU和最终的加速器有更多的处理能力可用于支持其他工作负载。

计算型存储的另一个好处是，它使共享存储环境更有利于对性能要求最高的工作负载。通常情况下，直接连接的存储方法被用来为这些工作负载服务，以避免存储网络延迟，而且还可以通过将数据分散到许多设备上来提高吞吐量。然而，这往往会导致资源利用不足，而且由于需要在多个设备上搜索相关数据，也会带来进一步的延迟。相比之下，CS允许应用程序同时在每个存储设备上执行。这就提供了一个平行处理的水平，以实现类似于微服务的方法，在所有单独的设备上运行这些应用程序。这种同时处理数据的能力大大减少了查找数据的时间，并为主机提供了所需的结果。

计算存储还可以帮助利用现有的网络基础设施更长时间，以及真正扩展下一代网络。因为计算能力使存储首先在更大的数据集上工作，它利用了现代固态硬盘更高的I/O能力，避免了性能受到网络的限制。因此，网络互连对于计算型存储来说就不那么重要了。因此，计算型存储通过使多个应用程序的性能在同一基础设施上得到加速，同时优化整个堆栈的基础设施资源的利用，来增加价值。

2.1 硬件和软件的状况

大多数固态硬盘都有专用的处理和存储元件–即嵌入式多核CPU或FPGA，以及除闪存外的DRAM。这些都是用来执行用户数据的读、写和擦除命令，以及闪存管理功能。由于SSD上有可用的计算资源，一些项目[31, 42, 29, 12, 38, 25, 35, 14, 28, 46, 36, 39, 45, 44, 24, 35, 13, 23]探索了在SSD设备本身运行用户定义的数据密集型计算任务的机会，如数据库操作。虽然观察到了性能的提高和能源的节约，但一些挑战阻碍了计算型固态硬盘的广泛使用和采用。首先，可用的处理能力受到设计的限制：低性能的嵌入式处理器，或资源有限的FPGA，以及高延迟的存储DRAM，需要额外的仔细编程来运行用户定义的代码以避免性能限制。其次，一个灵活和通用的接口和编程模型从未被定义过，以方便在SSD上执行用高级编程语言（如C/C++）编写的用户定义的代码。

此外，编程模型还需要支持多线程的各种存储应用程序的并发执行，使其成为复杂用户应用程序的有效平台。尽管如此，必须在主机和CSD上定义不同层次的硬件和软件的接口，以使平台真正可用。第三，没有人考虑如何处理多个用户。

在许多不同的硬件和软件上已经进行了大量的工作。据我们所知，到今天为止，只有两块CSD开发板可以公开使用：汉阳大学的OpenSSD[1]（实现了图1.b的架构），以及由DellEMC和NXP合作开发的DFC[26]（实现了图1.c的架构）。两者都有一个多核ARM通用处理器、加速器和可重新配置的硬件，除了一种闪存介质和DRAM之外。尽管是开源的，但它们都是基于旧的标准，不再被支持。另一方面，存储供应商使用他们自己的SSD原型[31, 38, 15]，FPGA板已经被用于研究[42, 46]。来自学术界的模拟环境也存在[30, 8, 15]，但缺乏支持。最近，市场上出现了CSD，包括具有多个64位ARM内核的NGD原位处理固态硬盘[6]、ScaleFlux CSD[10]和基于FPGA的三星SmartSSD[9]（实现图1.b中的架构）。

其他产品，如Eideticom NoLoad计算存储处理器[5]，在不同的PCIe板上实现存储和计算，如图1.c所示，由p2p DMA和NVMe的CMB[21]启用。这些产品触发了SNIA为CSD扩展NVMe协议的提议[11]–目前该提议正在进行中。因此，我们认为，为了使计算存储设备对大众更有吸引力，应该尽快做一些事情。值得注意的是，主要由于公司的知识产权问题，目前的CSD产品提供了非常有限的可定制性，因此，不能轻易用于研究目的，如接口或编程模型探索。

3. 开放式研究问题

我们认为，仅仅展示性能的提高和能源的减少还不足以说服CSD的广泛采用。因此，在这里我们提出了在现有的CS技术中发现的各种开放性研究问题，涉及a）资源管理，b）安全性，c）数据一致性，以及d）可用性。

3.1 资源管理

一个有一个或多个CSD的服务器本身就是一个单一的系统。但从软件的角度来看，由于主板上或任何CSD上的每一个（一组相同的）处理单元都运行自己的软件栈，这样的服务器看起来就像一个分布式系统。

单一系统和分布式系统中的资源管理是提供高效和公平使用硬件资源的基础，包括处理单元、内存和存储。例如，这意味着在任何给定的时间，没有任何单一的资源是过载的，也没有应用程序对资源感到饥饿。同样地，一个用户不应该垄断所有资源的使用。资源管理政策可能需要在计算资源之间平衡工作负荷，以满足性能和功率目标。然而，这在新兴的CS架构和相关工作中是缺乏的。

问题： a) 在哪里进行资源管理决策？b) 当CSD之间存在复制时，哪个复制体映射某个计算？ c) 如何在主机和CSD的可用处理单元之间保持工作负载和能源消耗信息？过载的CSD应该通知主机或其他CSD，然后呢？ e) 如何在不同的用户之间提供资源的公平性（如CPU周期、FPGA的真实空间、内存/闪存空间和闪存通道流量）？ f) 如何将数据映射到多个CSD，和/或CSD内部的不同闪存通道？ g) 对于使用单个CSD的应用程序，在主机CPU上运行和CSD上运行之间的平衡点是什么？这是否取决于工作负载？

3.2 安全问题

当一个固态硬盘存储不同用户的数据时，最基本的是拒绝用户访问对方的数据。对于今天的固态硬盘，有两种不同的方法来控制数据访问。第一种是使用文件系统–每个文件都有一个所有者，等等。第二种是使用硬件虚拟化（SRIOV）或NVMe命名空间[7]，以便将存储的不同部分分配给不同的所有者。尽管存在保护机制，但运行在CSD的处理单元（CPU、加速器、FPGA）上的代码有可能访问存储在闪存芯片上的所有数据。当使用文件系统进行访问控制时，定义安全机制和技术以保持在CSD中运行的软件和在主机CPU上运行的软件具有相同的用户概念是很重要的。
这是由于存储设备和运行在主机CPU上的软件之间存在语义上的差距–主机CPU知道文件系统和用户，但对于存储设备来说，这并不总是真的。值得注意的是，用户的知识可以是不对称的，也就是说，在大多数情况下，CSD不需要像主机CPU那样知道所有用户的细节。运行在CSD上的代码应该只访问它被允许访问的内容。
另一个问题是信任CSD本身的可重新配置的硬件、软件和固件的身份和完整性。假设存在一种只安装适当的固件和系统软件的方法，那么最根本的是，除此之外，只有且只有用户提交的代码在CSD上运行。此外，用户提交的代码不应改变CSD上的固件和系统软件的完整性。

问题。 a) 如何在CSD上将多个应用程序相互隔离？ b) 如何使它们免受侧信道攻击、拒绝服务等？ c) 不同的编程模型需要不同的隔离技术。例如，硬件虚拟化可以用来隔离不同的软件堆栈。d) 软件隔离的成本是多少？这个成本是否盖过了好处？ e) 如何确保CSD上运行的代码是合法的？不仅仅是在启动时，而且在运行时也是如此？

3.3 数据一致性

当数据被多方读取和写入时，可能会出现一致性问题。例如，同一个数据块可以被主机和CSD的CPU同时读取，而运行在这两者之一的应用程序修改了该块的内容。在这种单方面的修改之后，每个CPU将在不同的数据上运行–同时假设数据是相同的。事实上，在一个CPU修改数据后，它应该立即通知另一个。同样的问题不仅适用于文件内容，也适用于文件系统元内容。例如，当运行在主机CPU或CSD的CPU上的软件创建一个新文件时，必须通知另一个CPU创建。这也延伸到了几乎所有的文件系统操作。
显然，个人电脑的经典文件系统并没有解决这些问题。此外，常见的磁盘接口（如SATA、SAS、NVMe）也没有准备好管理这种情况–接口的建立是假设磁盘控制器严格执行主机CPU的命令。同样，数据可能在几个磁盘之间被复制或分片。为了保证一致性，对复制或分片数据的修改应该是平行进行的–这也适用于擦除码或奇偶校验块[13]。
最后，单个CSD在任何操作中都可能失败，包括存储中的数据处理。复制、分片和奇偶校验/擦除编码肯定可以用来容忍故障，而不是提高性能。这样的技术很可能在CSD之上实现。然而，为了支持这一点，CSD可能需要实现额外的功能 ，例如，向主机CPU或其他CSD通报故障。
a) 如何在主机和CSD上一致地使用相同的文件系统？ b) 文件系统的变化如何处理？
如何更新主机上关于CSD上文件修改的软件？ c) 是否需要一个新的文件系统？经典的文件系统可以被扩展来支持吗？分布式文件系统是否已经解决了这个问题？如果是的话，性能如何？ d) 如何扩展当前的存储接口以提供进入CSD的数据变化通知？是否需要通知？ e) 显式事务管理如何？
f) 硬件和软件故障怎么办？ g) 如果有复制，增加了一个新文件，如何处理？h) CSD之间如何为复制或任何其他需要在多个驱动器上协调操作的操作进行通信？ i) 通信需要通过主机CPU还是应该直接进行（例如，通过P2P DMA/RDMA）–哪一个更好？

3.4 可用性

为了扩大采用范围，可用性无疑是最重要的。CSD应该在任何级别的软件（用户级或内核级）上都能简单而快速地进行编程、部署和调试。
调试在主机和CSD的CPU之间运行的应用程序不应该是一场噩梦。例如，开发一个分布式软件后最复杂的步骤之一就是调试–这正是因为在这些环境中，程序员最终会有多个调试器，或者来自不同系统的日志记录，这些记录必须同步才能发挥作用并确定问题的来源。分布式系统的调试可以提供一些提示。
一个重要的问题是，CSD应该被看作是一个完全独立的计算机节点，还是作为计算机节点的一部分？我们认为这在很大程度上取决于CSD上可用的硬件资源–如果计算和内存资源与主机上的资源相当，用户就可以在主机和CSD上运行相同的工作负载。然而，如果资源不一样，CSD应该被认为是存储端加速器–因此，一个完整的工作负载应该只在主机CPU上执行。在此基础上，关于在CSD上运行什么工作负载的决定可以由运行在主机CPU上的软件或数据中心调度器做出。然而，在后一种情况下，CSD应该可以通过网络到达，这就要求CSD要有一个网络接口硬件，而且要有额外的成本。
问题： a) 除了可编程性，如何在CSD上轻松部署应用？c) 应用程序的资源管理器需要哪些信息来做出最佳的放置决定？ d) 如何设计一个易于使用的API，使应用程序的修改最小化？
类似POSIX的API是否容易被采用？

4. 编程模型

显然，对于希望在主机和CSD处理单元之间运行他/她的应用程序的程序员来说，可用的编程模型在很大程度上影响了第3节中问题的回答方式。我们认为，没有一个 “万能 “的编程模型适用于所有类型的应用，因此，我们希望对每个模型进行定量和定性的分析。在这一节中，我们将讨论一些编程模型，并描述我们对每个模型的设想，即如何回答上述研究问题，这在表1中进行了总结。

4.1 数据流

在数据流模型中（例如，[31，32]），为每个传输中的数据块定义了一个转换操作序列。一个转换操作接收输入的数据块，并输出转换后的数据块。一般来说，”传输中的数据 “是指在不同的硬件和软件层之间传输的数据块，不仅包括从闪存芯片传输到CSD/主机CPU的数据块，还包括流经不同内核和应用程序软件层的数据块。

当与CSD一起使用时。将数据流编程模型映射到CSD环境中是很简单的：对于每个存储命令（即磁盘块读或写），关联一个或一组转换操作，类似于[19, 13, 40]。主机和CSD的处理单元之间的通信可以通过扩展标准接口（例如，SATA、SAS、NVMe）来处理。扩展包括下载转换操作的新命令或对现有命令的修改，以便在主机和CSD的CPU之间交换每个会话或全球数据。
数据流模型很好地处理了第3节中列出的四个关注点中的大部分。这种编程模型的优点是，操作可以被定义为细粒度，并在任何地方（主机CPU或CSD的处理单元）执行，简化了资源管理。操作可以移回主机进行负载平衡，如果数据被复制，也可以透明地进行复制。此外，多个操作可以被合并、拆分以及并行化。当并行化时，对每个会话或全局数据的访问必须得到保护，以保证一致性。
为了安全起见，必须引入一种将数据与用户关联的方法。最后，数据流程序可以用任何语言来定义，尽管提供某种正式属性的语言是首选，如终止和内存安全。
不幸的是，只有一堆应用程序是在这种编程模型中实现的，当一个应用程序是在客户-服务器或共享内存模型中编写的，这就需要重写程序。因此，寻求研究能自动将应用程序转换为数据流的编译器工具。

4.2 客户端-服务器

这包括在集群内开发和部署的应用程序，如基于消息传递接口（MPI）、远程过程调用（RPC）、MapReduce等。这些应用的唯一要求是在多个计算节点之间建立网络连接–TCP/IP、UDP或RDMA是最常见的。这类应用被严格划分为多个程序，每个程序在不同的处理节点上运行。
当与CSD一起使用时。用这种编程模型开发的应用程序可以直接映射到CSD设置中，而不需要做任何修改–假设该应用程序可以在CSD提供的软件环境中运行。这可以通过在主机和CSD CPU之间和/或CSD CPU之间建立网络通道来实现[6]。然而，本地编译的应用程序可能需要重新编译为目标CSD的CPU（如ARM）的指令集架构（ISA）。
虽然不是不可能，但这个过程可能非常复杂。
事实上，它可能需要整个工具链，并重新编译程序所需的所有库–这是因为并非所有库都可用于所有的ISA。此外，许多这样的分布式应用是基于一个非常大的软件基础，涉及到几个不同的库。这在运行时通常会消耗大量的内存（除存储外），限制了可以同时在CSD上运行的实际应用数量，因此导致性能下降。
在客户-服务器模式下，资源管理的粒度是在程序层面上的–这是因为只有程序可以在CPU之间移动（假设同一程序可用于系统中存在的所有CPU ISA）。算法被嵌入到构建应用程序的不同程序中；因此，资源管理器/调度器不能以更精细的粒度行事，阻碍了自动优化。
安全性是在应用层面提供的，应用最终可以嵌入到容器中（操作系统层面的虚拟化）。标准的操作系统技术可以被用来使CSD的应用程序只访问属于特定用户的数据。

4.3 共享内存

共享内存编程模型在多核处理器上被广泛采用。它要求处理单元之间有一种（一致的）共享内存的形式。当硬件共享内存不可用时，可以使用软件共享内存，或分布式（虚拟）共享内存（DSM） [20, 33] 。共享内存编程模型的另一个假设是，所有的CPU都是相同的，或者至少是实现了相同的ISA。
当与CSD一起使用时。主机和CSD的CPU可能没有相同的ISA。事实上，许多现有的部署的特点是，主机上的x86 CPU和CSD的ARM CPU。学术项目，如Popcorn Linux[22, 18]和H-Container[17]，使为共享内存多核开发的应用程序能够透明地在异构ISA核上运行–无需修改任何应用程序。这包括在主机CPU上启动一个应用程序，然后将其所有线程迁移到CSD上。
在这种模式下，资源管理有可能在汇编指令的最细粒度上完成。这样一来，计算可以随时在主机CSD的CPU之间摆动，例如，基于计算密集度和数据的位置。
这种编程模型的问题是，当硬件共享内存不可用时，它应该由软件提供，这可能是昂贵的。然而，未来PCIe的发展可能会在PCIe上的设备CPU和主机CPU之间提供一致的共享内存[2, 3, 4]。此外，共享内存编程模型也需要注意一致性问题，这种模型中的计算不能通过外部资源管理器进行并行化或优化。最后，安全性可以通过经典操作系统中的方法来实现（如使用文件系统或第3.2节中描述的硬件虚拟化/NVMe命名空间），但要进一步研究

5. 存储接口

在这一节中，我们回顾了每种编程模型的硬件和软件接口含义。目前有不同类型的存储接口被工业界和研究界广泛采用（例如，基于块、基于文件和基于对象的接口），但我们相信我们的发现适用于任何这些接口

5.1 硬件接口

数据流编程模型需要有限的存储接口修改。正如第4.1节所讨论的，一个转换操作应该只是分配给一个数据流，对于数据流的每个数据块都要调用该操作。因此，对今天的存储接口，如NVMe，最小的要求是提供额外的命令来。1）下载程序；2）将程序附加/分离到数据流中；3）定义数据流；4）调试/记录。所有这些命令都可以通过简单地扩展现有的NVMe协议/接口来实现，作为支持传统的软件。请注意，有了这个接口，开发者不需要关心CSD的CPU上运行的是哪个软件栈，例如，它可以是Linux，也可以是一个固件。
服务器-客户端编程模型也可能需要有限的存储接口修改。如第4.2节所述，只需要一个消息传递通道来模拟网络通信–这可以用发送和接收队列来实现（类似于RDMA、NVMe等）。这种变化可以通过向NVMe协议/接口添加新的命令集来扩展它，其中不仅包括用于消息通信的命令，还包括用于下载、运行和监控存储中的程序。
共享内存编程模型（第4.3节）本身就是在需要一个高性能的实现时，要求对当前的存储接口进行更多的改变，即没有软件DSM开销。如果不需要，则要求对客户端-服务器编程模型所要求的接口进行同样的修改。这样的修改足以实现软件DSM。相反，当需要一个高性能的实现时，在主机CPU和CSD的CPU之间应该有一种硬件共享内存，例如，由新的相干外围总线互连[2, 3, 4]提供。硬件共享内存不一定是一致的–一致性可以通过软件提供。

5.2 软件接口

在数据流编程模型内编写的应用程序不需要任何特定的软件接口–事实上，程序会声明输入源以及输出源，即来自或流向存储介质的数据流。一个应用程序的开发者不会直接接触到任何CSD特定的硬件接口，而运行时系统则将程序员从这些技术性问题中屏蔽掉。
当一个应用程序是在服务器-客户端或共享内存编程模型内编写的，当在CSD上执行时，它被期望直接与闪存阵列接口。请注意，这对性能是必要的。因此，应该定义一个软件接口来访问闪存阵列。一个幼稚的解决方案是用UNIX设备来抽象每个不同的闪存阵列的通道。因此，每个用户可以被分配一个不同的通道。尽管这是一个实用的解决方案，它与底层硬件有很好的映射关系，并且可以用于保护/隔离，但由于性能的原因，不同的用户被分配到不同的NAND通道是非常不可能的–这是因为并行地写入和读取几个通道可以带来高性能。
此外，用户通过文件访问存储的数据。文件是一个文件系统的抽象，通常由主机操作系统提供，在SSD上没有必要知道。因此，需要一个更细粒度的解决方案来保护/隔离不同用户的数据，这就需要为程序员提供另一个抽象概念。流的概念，如（非连续的）闪存块的列表可能是一个解决方案，但现有的硬件并没有提供任何相关的机制。
在主机方面，同样的CS硬件接口应该可以被用户和内核级别的软件使用。这是为了支持内核空间的传统文件系统和用户空间的现代存储软件（例如SPDK）。需要一个 “对称的 “内核/用户接口。
最后，为了支持代码不能被移到CSD的情况，因此它应该在主机操作系统上运行，一个对称的软件接口应该可以在主机和CSD上实现。

6. 结论性意见

在本文中，我们简要地调查了计算存储的技术现状，并提出了几个可能需要考虑的公开挑战，以促进计算存储技术在研究和工业界的应用–现有的计算存储硬件和软件还没有准备好在生产中大规模使用。然后，我们讨论了最广泛使用的具有硬件/软件接口的编程模型如何帮助解决这些挑战。我们相信，我们在本文中的讨论和教训可以为计算存储技术的大规模应用提供更高的清晰度，即可能需要什么.

7. 参考文献

[1] The OpenSSD Project. http://www.openssd-project.org/, 2016.

[2] Cache Coherent Interconnect for Accelerators (CCIX). http://www.ccixconsortium.com/, 2017.

[3] Gen-Z Consortium. http://genzconsortium.org/, 2017.

[4] OpenCAPI Consortium. http://opencapi.org/, 2017.

[5] Eideticom. NoLoad Computational Storage Processor. https://www. eideticom.com/uploads/images/NoLoad Product Spec.pdf, 2020.

[6] NGD Systems. https://www.ngdsystems.com/, 2020.

[7] NVMe Specifications. https://nvmexpress.org/specifications/, 2020.

[8] OX: Computational Storage SSD Controller. https://github.com/DFC-OpenSource/ox-ctrl, 2020.

[9] Samsung. https://samsungsemiconductor-us.com/smartssd, 2020.

[10] ScaleFlux. https://scaleflux.com/, 2020.

[11] SNIA. Computational Storage. https://www.snia.org/computational, 2020.

[12] A. Acharya, M. Uysal, and J. Saltz. Active disks: Programming model, algorithms and evaluation. ACM SIGOPS Operating Systems Review, 32(5):81–91, 1998.

[13] I. F. Adams, J. Keys, and M. P. Mesnier. Respecting the block interface–computational storage using virtual objects. In 11th USENIX Workshop on Hot Topics in Storage and File Systems (HotStorage 19), 2019.

[14] D.-H. Bae, J.-H. Kim, S.-W. Kim, H. Oh, and C. Park. Intelligent ssd: a turbo for big data mining. In Proceedings of the 22nd ACM international conference on Information & Knowledge Management, pages 1573–1576, 2013.

[15] A. Barbalace, M. Decky, J. Picorel, and P. Bhatotia. BlockNDP: Block-storage Near Data Processing. ACM/IFIP Middleware ’20, New York, NY, USA, 2020. [16] A. Barbalace, A. Iliopoulos, H. Rauchfuss, and G. Brasche. It’s time to think about an operating system for near data processing architectures. In Proceedings of the 16th Workshop on Hot Topics in Operating Systems, pages 56–61, 2017.

[17] A. Barbalace, M. L. Karaoui, W. Wang, T. Xing, P. Olivier, and B. Ravindran. Edge computing: the case for heterogeneous-isa container migration. In Proceedings of the 16th ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments, pages 73–87, 2020.

[18] A. Barbalace, R. Lyerly, C. Jelesnianski, A. Carno, H.-r. Chuang, and B. Ravindran. Breaking the boundaries in heterogeneous-isa datacenters. In Proceedings of the 22th International Conference on Architectural Support for Programming Languages and Operating Systems, ASPLOS ’17, 2017.

[19] A. Barbalace, J. Picorel, and P. Bhatotia. Extos: Data-centric extensible os. In Proceedings of the 10th ACM SIGOPS Asia-Pacific Workshop on Systems, APSys ’19, page 31–39, New York, NY, USA, 2019. Association for Computing Machinery.

[20] A. Barbalace, B. Ravindran, and D. Katz. Popcorn: a replicatedkernel os based on linux. In Proceedings of the Linux Symposium, Ottawa, Canada, 2014.

[21] S. Bates and O. Duer. Enabling the NVMe CMB and PMR ecosystem. https://nvmexpress.org/wp-content/uploads/Session2-Enabling-the-NVMe-CMB-and-PMR-Ecosystem-Eideticom-andMell....pdf, 2018.

[22] S. K. Bhat, A. Saya, H. K. Rawat, A. Barbalace, and B. Ravindran. Harnessing energy efficiency of heterogeneous-isa platforms. SIGOPS Oper. Syst. Rev., 49(2):65–69, Jan. 2016.

[23] W. Cao, Y. Liu, Z. Cheng, N. Zheng, W. Li, W. Wu, L. Ouyang, P. Wang, Y. Wang, R. Kuan, et al. Polardb meets computational storage: Efficiently support analytical workloads in cloud-native relational database. In 18th USENIX Conference on File and Storage Technologies (FAST 20), pages 29–41, 2020.

[24] S. Cho, C. Park, H. Oh, S. Kim, Y. Yi, and G. R. Ganger. Active disk meets flash: A case for intelligent ssds. In Proceedings of the 27th international ACM conference on International conference on supercomputing, pages 91–102, 2013.

[25] A. De, M. Gokhale, R. Gupta, and S. Swanson. Minerva: Accelerating data analysis in next-generation ssds. In 2013 IEEE 21st Annual International Symposium on Field-Programmable Custom Computing Machines, pages 9–16. IEEE, 2013.

[26] J. Do. Softflash: Programmable storage in future data centers. https://www.snia.org/sites/default/files/SDC/2017/presentations/ Storage Architecture/Do Jae Young SoftFlash Programmable Storage in Future Data Centers.pdf, 2017.

[27] J. Do, V. C. Ferreira, H. Bobarshad, M. Torabzadehkashi, S. Rezaei, A. Heydarigorji, D. Souza, B. F. Goldstein, L. Santiago, M. S. Kim, et al. Cost-effective, energy-efficient, and scalable storage computing for large-scale ai applications. ACM Transactions on Storage (TOS), 16(4):1–37, 2020.

[28] J. Do, Y.-S. Kee, J. M. Patel, C. Park, K. Park, and D. J. DeWitt. Query processing on smart ssds: opportunities and challenges. In Proceedings of the 2013 ACM SIGMOD International Conference on Management of Data, pages 1221–1230, 2013.

[29] J. Do, S. Sengupta, and S. Swanson. Programmable solid-state storage in future cloud datacenters. Communications of the ACM, 62(6):54–62, 2019. [30] D. Gouk, M. Kwon, J. Zhang, S. Koh, W. Choi, N. S. Kim, M. Kandemir, and M. Jung. Amber: Enabling precise fullsystem simulation with detailed modeling of all ssd resources. In 2018 51st Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), pages 469–481. IEEE, 2018.

[31] B. Gu, A. S. Yoon, D. Bae, I. Jo, J. Lee, J. Yoon, J. Kang, M. Kwon, C. Yoon, S. Cho, J. Jeong, and D. Chang. Biscuit: A framework for near-data processing of big data workloads. In 2016 ACM/IEEE 43rd Annual International Symposium on Computer Architecture (ISCA), pages 153–165, 2016.

[32] I. Jo, D.-H. Bae, A. S. Yoon, J.-U. Kang, S. Cho, D. D. Lee, and J. Jeong. YourSQL: a high-performance database system leveraging in-storage computing. Proceedings of the VLDB Endowment, 9(12):924–935, 2016.

[33] D. Katz, A. Barbalace, S. Ansary, A. Ravichandran, and B. Ravindran. Thread migration in a replicated-kernel os. In 2015 IEEE 35th International Conference on Distributed Computing Systems, pages 278–287. IEEE, 2015.

[34] K. Keeton, D. A. Patterson, and J. M. Hellerstein. A case for intelligent disks (idisks). Acm Sigmod Record, 27(3):42–52, 1998.

[35] G. Koo, K. K. Matam, I. Te, H. K. G. Narra, J. Li, H.-W. Tseng, S. Swanson, and M. Annavaram. Summarizer: trading communication with computing near storage. In 2017 50th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), pages 219–231. IEEE, 2017.

[36] Y.-S. Lee, L. C. Quero, Y. Lee, J.-S. Kim, and S. Maeng. Accelerating external sorting via on-the-fly data merge in active ssds. In 6th USENIX Workshop on Hot Topics in Storage and File Systems (HotStorage 14), 2014.

[37] H. Li, M. Hao, S. Novakovic, V. Gogte, S. Govindan, D. R. Ports, I. Zhang, R. Bianchini, H. S. Gunawi, and A. Badam. Leapio: Efficient and portable virtual nvme storage on arm socs. In Proceedings of the Twenty-Fifth International Conference on Architectural Support for Programming Languages and Operating Systems, pages 591–605, 2020.

[38] S. Pei, J. Yang, and Q. Yang. Registor: A platform for unstructured data processing inside ssd storage. ACM Transactions on Storage (TOS), 15(1):1–24, 2019.

[39] L. C. Quero, Y.-S. Lee, and J.-S. Kim. Self-sorting ssd: Producing sorted data inside active ssds. In 2015 31st Symposium on Mass Storage Systems and Technologies (MSST), pages 1–7. IEEE, 2015.

[40] R. Schmid, M. Plauth, L. Wenzel, F. Eberhardt, and A. Polze. Accessible near-storage computing with fpgas. In Proceedings of the Fifteenth European Conference on Computer Systems, EuroSys ’20, New York, NY, USA, 2020. Association for Computing Machinery.

[41] Z. Schoenborn. Board Design Guidelines for PCI Express Architecture. https://web.archive.org/web/20160327185412/http://e2e. ti.com/cfs-file/ key/communityserver-discussions-components-, 2004.

[42] S. Seshadri, M. Gahagan, S. Bhaskaran, T. Bunker, A. De, Y. Jin, Y. Liu, and S. Swanson. Willow: A user-programmable ssd. In 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14), pages 67–80, 2014.

[43] S. Shadley and N. Adams. What happens when compute meets storage, 2019.

[44] J. Wang, E. Lo, M. L. Yiu, J. Tong, G. Wang, and X. Liu. Cache design of ssd-based search engine architectures: An experimental study. ACM Transactions on Information Systems (TOIS), 32(4):1–26, 2014.

[45] J. Wang, D. Park, Y.-S. Kee, Y. Papakonstantinou, and S. Swanson. Ssd in-storage computing for list intersection. In Proceedings of the 12th International Workshop on Data Management on New Hardware, pages 1–7, 2016.

[46] L. Woods, Z. Istv´an, and G. Alonso. Ibex: An intelligent storage engine with support for advanced sql offloading. Proceedings of the VLDB Endowment, 7(11):963–974, 2014