Willow: A User-Programmable SSD

Willow: A User-Programmable SSD
1、 摘要
We explore the potential of making programmability a central feature of the SSD interface. Our prototype system, called Willow, allows programmers to augment and extend the semantics of an SSD with application-specific features without compromising file system protections. The SSD Apps running on Willow give applications low latency, high-bandwidth access to the SSD’s contents while reducing the load that IO processing places on the host processor. The programming model for SSD Apps provides great flexibility, supports the concurrent execution of multiple SSD Apps in Willow, and supports the execution of trusted code in Willow.
We demonstrate the effectiveness and flexibility of Willow by implementing six SSD Apps and measuring their performance. We find that defining SSD semantics in software is easy and beneficial, and that Willow makes it feasible for a wide range of IO-intensive applications to benefit from a customized SSD interface.
Willow原型系统，允许编程者增强和扩展有特定应用程序特性的SSD的语义，同时不影响文件系统保护。运行在Willow上的应用程序有较低的延迟、较高的访问带宽，同时减少主机处理器上IO处理的负载。SSD Apps可编程模型有更好的灵活性，支持多个SSD Apps的并发执行，支持可信代码的执行。
通过实现6个SSD Apps并测量其性能，验证Willow的有效性。我们发现定义SSD语义简单且有效，Willow使SSD语义在很大的IO密集应用程序上可行，且得益于传统的SSD接口。
2、 现有背景下的问题
Willow提出的接口：存储设备暴露系统的其余部分，并为接口的有限性提供硬件支持。
传统的硬盘计算机系统使用块设备接口，但随着计算机组件的发展，接口也变得更为复杂。高速非易失SSD的出现，因其与硬盘有很大不同，故需要存储软件和存储系统间接口的根本性改变。
新接口的范围很广，包括通用接口和适应特定应用程序的方案。现有研究已有：SSD可支持复杂的原子操作[ , , ]、本地缓存操作[ , ]、大的稀疏存储地址空间[ ]、授权存储分配决策到SSD[ ]、卸载文件系统对硬件的权限检查 [ ]，都带来了巨大的性能提升。但当前的有效方法实施时，都受限于SSD本身的制约。故我们建议做可编程的SSD接口，即Willow，则普通程序员可安全的扩展其SSD的功能。Willow允许应用程序、文件系统、操作系统编程者自定义安装SSD Apps。

3、 提出的解决方案
应用程序可以通过4种方式，开发这种可编程性。（1）数据相关逻辑；（2）语义扩展；（3）特权执行[8]；（4）数据密集型计算。Willow致力于前三点，并证明了添加通用的可编程性可显著减少开销和复杂性。我们描述了一个基于PCM的Willow原型实施方案。

3.1 解决方案综述
（一） Willow组件

如图1(a)，描述了传统的SSD存储系统，它使用NVMe协议和PCIe接口；操作系统发送命令和接受通道的命令，且命令都是特定的（读写一个块），主机操作系统和存储设备是点到点连接。现在的高端SSD都有多个嵌入式可编程处理器，但是这些可编程性对主机系统或应用程序都不可见。
如图1(b)显示了Willow SSD。有多个存储处理器单元（SPUs），每个SPU包含一个微处理器、连接到内部SPU的接口、到NVM阵列的访问。每个SPU运行一个很小的操作系统SPU-OS，管理和执行安全。
Willow提供的接口与传统SSD有很大的不同。主机端，Willow驱动创建和管理一个对象集，对象集被称为主机RPC端点（HREs）。HRE允许OS和应用程序访问SPUs，HRE是一个数据结构，由内核创建并分配给一个进程；HRE ID是唯一标识，负责发送和接受RPC请求，并使进程通过DMA传输发送和接受这些请求。SPUs和HREs的交互通过一个使用简单灵活RPC机制的弹性网络。RPC机制是通用的。
Willow的最后一个部件是以SSD Apps形式存在的可编程功能。每个SSD Apps包含三个元素：RPC handler集（Willow内核驱动在每个SPU上安装，代表应用程序）、一个库（应用程序使用库访问SSD App）、内核模块（若SSD App需要内核支持）。多个SSD Apps可以在同一时间活动。
下面分别介绍：高级系统模型（Willow使用模型）、可编程模型（建立SSD App）、SPUs和HRE的安全模型（SPU架构、RPC接口）。
（二） Willow使用模型
Willow支持很多不同的使用模型，本文将Willow视为传统的存储设备，但具有可编程的特点；因为它允许Willow的特点采用增量模型，并确保应用程序可直接使用Willow而不用做修改 。在此模型中，Willow运行一个叫Base-IO的SSD App，提供基本块设备功能（从存储设备读写数据）。Base-IO将数据分布在SPUs和非易失bank中，分段大小为8KB；Base-IO（且在本文中提到的所有SSD App）在每个SPU中运行相同的代码。Base-IO对于组织数据和计算是很有用的，但是Willow不需要。
Willow中使用一个传统的文件系统管理空间，并为它持有的数据设置权限。文件系统使用Base-IO块设备接口来维护元数据，并提供对应用程序的数据访问。没有使用Willow的可编程性。
为了开发Willow的可编程性，一个应用程序需要安装和使用一个传统的SSD App。图2说明了此过程，即Direct-IO，它提供了一个OS-bypass接口 ，这个接口避免了常规读写的系统访问和文件系统开销。图显示了Direct-IO的软件组件（黑体部分）。应用程序使用Direct-IO的用户空间库libDirectIO。库要求操作系统在Willow中安装Direct-IO，并向Willow驱动请求一个HRE，以达到与Willow SSD进行信息交互的目的。

Direct-IO也包含一个内核模块（在主机端内核），当需要打开一个文件时则libDirectIO调用这个内核模块。Direct-IO内核模块请求Willow驱动，授予应用程序权限以访问该文件。驱动向文件系统请求必须的许可信息，并流出可信的RPCs到SPU-OS，以为文件扩展安装许可，应用程序需求访问SPU-OS许可表中的文件扩展。现代的文件系统已具备从内核里面查询权限的能力，故文件系统不需要改变。
Base-IO和Direct-IO为很多其它SSD Apps提供有用功能，故在Willow上是标准装备。特别的，其它的SSD Apps可以使用Direct-IO的功能实现文件数据上的库和不可信操作。
（三） 建立SSD App
SSD Apps包含运行在各个地方（客户端应用程序、主机端内核、Willow SSD）的交互组件。为了减小复杂度，在这三个地方的代码使用一个共用的接口集来实现SSD App功能。主机端的应用和内核中，HRE库实现这些接口，同时在Willow中，SPU-OS实现这些接口。接口提供以下功能：
（1） 发送RPC请求。SPUs和HREs可以相互发送RPC请求。RPC交付是不可靠的（因为接收端有限的缓存），或者全部接收或者不接收。Willow支持同步和异步的RPCs。
（2） 接受RPC请求。RPC的RPC ID指定了目标SSD App和应调用的处理程序。当RPC到达，the runtime（HRE库或者SPU-OS）调用相应的处理程序。
（3） 发送一个RPC响应。RPC响应很短暂，是固定长度的消息。响应包含结果代码和请求信息。响应的传递是可靠的。
（4） 启动数据传输。一个RPC handler可以同步的传输数据，在网络接口、本地存储器、本地非易失存储器（只对SPUs）之间。
（5） 分配本地内存。SSD App在SPU的本地数据存储器中，声明静态变量来分配空间；但不可以动态分配SPU存储。主机的代码可静态分配数据或者在堆中分配。
（6） 通用计算。SSD Apps用C语言实现，但在SPUs中这些标准库不可用。
除了这些接口，主机端HRE库也提供了便利，来从Willow驱动请求HREs和安装SSD Apps。这些接口灵活易用。当我们建立SSD App有了更多的经验，则SSD App的优化、功能扩展、预防出错将变得更容易。
（四）SPU架构
SPU有4个硬件组件，用来实现SSD App工具包：SPU处理器、本地非易失存储、网络接口、可编程DMA控制器。DMA控制器在非易失存储、网络接口、处理器的本地数据存储之间路由数据。DMA是SPU和RPC机制设计的核心，因为它允许高速处理器来处理高带宽的数据流。

SPU运行一个简单的操作系统SPU-OS，它提供简单的多线程、联合Willow主机端的驱动来管理SPU存储器资源，实现保护机制即允许多个SSD App同时运行，且增强了文件系统对非易失存储器的保护策略。
（五）RPC接口
考虑到SPU处理的性能和有限的本地存储器资源，缓存整个RPC信息在SPU处理器中是不实际的。RPC库的解析和整合在不同阶段完成。如图3显示了从Base-IO中READ()RPC的过程。

当一个RPC到达，SPU-OS使用DMA复制RPC header到本地缓存，并传递缓存到适当的handler（Read_Handler）。这个handler使用DMA控制器传递RPC的参数到SPU处理器的本地存储器（RPCReceiveBytes）。Header包含通用信息（RPC请求的来源和大小），同时参数包括特定命令值（读写地址）。Handler使用一个或多个DMA请求来处理请求的剩余部分。这包含将部分请求移动到处理器的本地存储器，以便审查或执行网络接口和非易失存储器bank间的批量转移（比如：实现一个写操作）。在这个例子中,不需要额外的DMA传输。Handler发送一个固定大小的响应（RPCCreateResponse和RPCSendResponse）。当RPC被发送，Willow通过确保空间来接受响应消息，保证固定大小响应的可靠传输（acks或者nacks）。如果SSD App需要发送一个32bit以上的响应，则它必须向发送方发送RPC。若接收端缓存不足，内部SPU通讯网络丢掉包，但很罕见。
发出一个RPC以返回读取的数据的过程类似一个序列。SPU将目标和长度信息给网络接口（RPCStartRequset）。然后它在本地存储器中准备好一些header，并使用DAM控制器传输他们到网络接口（RPCAppendRequest）。进一步的，DMA请求可以从非易失存储器或者处理器存储器传递数据到网络接口，以完成请求。这种情况下，SSD App从非易失存储器传递数据。最后，调用函数发送结束信息（RPCFinishRequest）。
（六）Willow中的保护和共享
Willow有几个功能，方便用户构建和部署有用的SSD的应用：Willow支持不可信的SSD Apps，防止恶意的SSD Apps（假设主机端内核不被盗用），允许多个SSD Apps同时活动，允许一个SSD App使用其它应用提供的功能。这四个特性允许用户构建和使用SSD应用程序，而不需要系统管理员的许可。
提供这些功能需要4个保护机制的结合使用。首先，需要清楚的是哪一个主机端进程负责SPU中代码的执行，故SPU-OS可以执行正确的保护政策。第二，只要发起当前RPC的进程有访问数据的权限，SPU必须允许SSD App访问存储在Willow中的数据。第三，SPU必须限制SSD应用程序只能访问自己的内存和执行自己的代码。第四，必须允许SSD应用之间的一些控制传输，这样用户可以组合SSD应用。分别如下：
Tracking responsibility：主机系统有责任为Willow设置保护政策，这点通过将权限和操作系统进程结合来实现。为了正确地执行操作系统的策略，SPU-OS必须能够确定：当前运行的进程中，哪些负责RPC handler。
为了实施这点，Willow追踪每个RPC的原始HRE。An HRE is the originating HRE for any RPCs it makes and for any RPCs that an SPU makes as a result of that RPC and any subsequent RPCs。 Willow SSD中的PCIe接口硬件为最初的RPC设置最原始的HRE，且SPU硬件和SPU-OS在SSD中传播此消息。结果，最原始的HRE ID是不可伪造的，并作为一项功能[ ]。
为了减少缓存一致性流量，给一个进程中的每一个线程设置一个HRE是有用的。Willow驱动分配HREs，故一个单进程中所有HRE的HRE ID的高位是相同的。
Non-volatile storage protection：为了限制非易失存储器banks中的访问，SPU-OS为SPU中的每一个进程维护一张权限表。每次SSD App使用DMA控制器从非易失存储器中移动过数据，SPU-OS检查最原始的HRE权限表。最坏的权限检查延迟为2us。
主机端内核驱动通过发行特权RPCs到SPU-OS，安装基于扩展的权限表项。SPU存储每个进程的权限以一个splay树的形式，以减少检查时间。因为SPU-OS权限表是固定的大小，如果空间短缺它可能驱逐一些表项。若请求需要一个已被驱逐的权限表项，则发生权限不命中，则DMA传输失败。响应时，SPU-OS发送一个RPC到内核。内核将请求转发给SSD App的内核模块（如果有），且内核模块有责任解决这个缺失。大多数SSD Apps使用Direct-IO模块来管理缺失，且重新调入所需的权限表项。
Code and Data Protection：为了限制SPU处理器本地存储器的代码和数据访问，SPU处理器提供段寄存器且不允许外访。每个SSD App有自己的数据和指令段，定义了指令的基址和长度及可访问的数据区域。访问SSD App段以外区域引发一个异常，且导致SPU-OS通过一个RPC通知内核，反过来，内核通知一个应用程序SSD App已不可用。SPU-OS对传入的消息，提供了一个可信的RPC的调度机制。这种机制根据RPC指定的SSD App，设置段寄存器。
主机端内核负责管理和静态分配SPU指令和数据存储器到活动的SSD App。覆盖可以扩展有效指令和数据内存的大小(在商业SSD控制器固件中是常见的)，但原型中未实现。
Limiting access to RPCs：软硬件的组合限制了一些RPCs的访问。这允许SSD Apps的安全组合，且允许SSD Apps只能创建从主机端内核流出的RPCs。
为了支持组合，SPU-OS为改变段作为部分函数调用（从一个SSD App到另一个），提供一种机制。每个SPU中的一个SSD App内部调用表控制：哪一个SSD Apps可调用另一个，哪个函数调用是被允许的。
为了实现内核only RPCs，使用一个约定：HRE ID高位为0则表示HRE数据内核。RPC实施可以检查ID，并在非内核HRE调用一个受保护的RPC时返回失败。
SSD Apps可使用这个机制来引导更多需要复杂保护机制的。比如，通过一个内核only RPC，可以使用SSD App内核模块授权给用户空间HREs。
3.2 Willow原型系统及原理详述
原型系统有8个SPUs，共64GB。使用基于BEE3 FPGA 的原型系统。BEE3使用PCIe 1.1x8连接主机，提供2GB/s的全双工带宽。每4个FPGAs组成一个BEE3，有2个SPUs，每个附加一个8GB的DDR2 DRAM。我们使用DRAM加上一个定制的内存控制器模拟PCM，其读延迟48 ns和写延迟150 ns。内存控制器实现start-gap磨损均衡。
SPU处理器：125MHz RISC处理器，每周期执行一条指令。我们使用MIPS版本的GCC生成可执行代码。对于调试，它提供了一个虚拟串口和一组丰富的主机性能计数器和状态寄存器。处理器有32 KB的本地数据存储器和32 KB的本地指令存储器。
内核驱动静态分配SPU存储器空间给SSD Apps，这约束了可同时运行的SSD Apps的数目和大小。SPU-OS维护一个权限表在本地数据存储器中，可以存储768条表项，占据了20KB的数据存储。
Willow的环，使用循环制，基于令牌的仲裁，故在任何时间只有一个SPU发送消息。发送一个消息，SPU的网络接口等待一个令牌的到来，占有令牌，并进行数据传输。接受一个消息，接口查看环中的消息头部，识别应该从环中删除的消息。环宽128位，以250MHz运行，总对分带宽为3.7GB/s。
为了与主机的HREs通信，使用一个桥连接环和PCIe link。这个桥作为HRE的一个硬件代理。对每一个HREs，桥维护一个上游（主机）和下游（Willow）队列。这种基于队列的接口与NVMExpress使用的机制相似，用于流出和完成IO请求。原型系统中的桥支持1024个队列对，故主机支持1024个HREs。
桥也有利于Willow的安全执行，从HREs到SPUs的消息在桥上传输，桥根据到来的HRE，设置这些消息的原始HRE字段。因为进程只能通过他们控制的HREs的队列来发送消息，进程不能发送伪造RPC请求。

4、 方案的结果（案例分析）
通过实现6个不同的SSD Apps和比较它们的性能（使用传统的存储接口），已证实了Willow的有效性。
6个应用：basic IO，IO with OS bypass，atomic-writes，caching，a key-value store，appending data to a file in the Ext4 file system。

4.1 Base IO
一个有Base-IO的Willow SSD很接近传统的SSD，因为SSD固件实现Base-IO提供的功能。如图4：Base-IO的读写分别使用78%和73%的PCIe带宽；对于小访问，可维持到388K的读IOPs。这PCIe使用率相当于商业中高端PCIe SSD设备。

4.2 Direct-IO
Direct-IO，绕过了操作系统，应用程序可以直接执行read()、write()操作。Direct-IO依赖用户空间库，实现POSIX兼容接口。
图4比较了XFS下的base-IO和Direct-IO性能。通过避免文件系统开销和系统调用，Direct-IO小读性能比Base-IO高66%，写性能高8倍。写性能的提升比读性能大，因为写需要一个RPC往返而读需要两个：一个从主机到SSD的RPC发送请求，一个从SSD到主机的RPC发送数据。Direct-IO减小了第一个RPC的开销，而不是第二个。
图5分解了4KB访问的读延迟。几种情况共享相同的硬件（DMA和NVM访问）和主机端延迟。但Direct-IO通过绕过操作系统，节约了35%的访问延迟。预计图5的第三种情况，在整个延迟上，几乎消除了SPU软件开销，尽管可能增加功耗。在定制的Willow硅板上，这样的处理器很容易实现。

4.3 Atomic Writes
很多存储应用（比如文件系统和数据库）使用预写日志（WAL）来执行严格的一致性保证。WAL方案的范围从相对简单的文件系统的日志记录机制到数据库中可伸缩事务的复杂的ARIES机制。近年，公司和研究机构已开发了几个SSD设备，有多个部分原子写操作的内置支持[2,3]，包括MARS[1]机制旨在取代数据库中的ARIES。
MARS依赖EAW(editable atomic writes)。EAW将日志信息驻留在SSD中的位置的详细的控制提供给应用程序，并允许编辑先前的日志记录以提交原子操作。
我们实施了EAWs作为SSD App，即Atomic Writes。Atomic Writes实现了4个RPCs：LOGWRITE(), COMMIT(), LOGWRITECOMMIT(),ABORT()，如表2。Atomic Writes使用了Direct-IO。

LOGWRITE(), COMMIT()的实现证明了Willow的RPC接口的灵活可编程。每个SPU为每个活动的事务，维护redo-log作为一个复杂的持久数据结构。日志的元数据项以数组形式组织，它驻留在非易失存储器的保留区，每一项指向一个日志记录、要写的数据、要写的地址。LOGWRITE()添加一条记录项到数组，并初始化以在日志中添加新的记录项。
COMMIT()为了实现原子性，在SPUs间使用一个两阶段提交协议。主机库跟踪参与事务的SPUs，并选择其中一个作为协调器。第一阶段，协调器广播一个“准备”请求给所有参与该事务（包含自己）的SPUs。每个参与者决定是否提交或终止，并报告给协调器。第二阶段，若任何一个参与者决定停止，则协调器指示所有参与者中止。否则协调器广播一个“提交”请求，故每个参与者完成本地日志的一部分，在完成时通知协调器。
我们已修改了Shore-MT[ ]存储管理器，以使用MARS和EAW实现事务进程。我们也调整了EAWs以匹配Shore-MT管理事务的方式、可能在“black box”中的sth、EAWs通用的实施方案（可能包含不可编程的SSD）。图6显示了TPC-B的MARS和ARIES的不同性能。当增加线程数目时，MARS比ARIES更好，增大1.5倍。这个增长是根本的，因为Atomic Writes丰富的语义。

4.4 caching
SSD设备比硬盘更贵、密度更小。将高性能SSD集成到存储系统中作为大型传统后备存储器的缓存。传统的SSD缓存系统比如FlashCache和bcache实现缓存查找，并作为操作系统中的一个软件部件管理操作。几个研究组已提出添加缓存接口到SSD设备，以提高存储系统性能。
Caching将Willow转换为一个缓存SSD。Caching追踪cache中的脏数据，提供恢复，追踪热数据的统计信息以为替换策略提供依据。使用Direct-IO的OS-bypass接口，直接从用户空间服务缓存访问。若缓存缺失，caching调用基于内核的缓存管理器（基于Bankshot）。
Caching将Willow转换为一个专业的缓存SSD，而不是在正常的缓存访问上提供特定应用程序特征。不是使用文件系统的基于分区的保护策略，caching使用一个专门的许可机制，基于大的、固定大小的缓存块，这样更能有效使用SPU的有限的本地存储器。Caching的内核模块使用一个特权内核only RPC来安装专门的权限项和管理缓存的内容。
为了测量缓存的性能，我们使用Flexible IO Tester（Fio）[ ]。配置Fio生成Zipf-distributed[ ]访问，即90%的访问集中于10%的数据。我们改变文件大小从1GB到128GB。我们使用一个1GB的缓存并在缓存warm后报告平均延迟。备用存储器是硬盘。
图7显示了4KB访问到FlashCache和Caching的平均读写延迟。因为是内核模块，FlashCache使用Base-IO。Caching的全相联分配策略允许缓存空间的更有效使用；且直接用户空间的访问减少了软件的开销。Caching减少了缺失率达6%到23%，提升了缓存命中延迟（写61.8%，读36.3%）。总之，这些提高了读延迟从1.7到2.8倍，写1.8倍。
4.5 Key-Value Store
键值存储是很有用的工具。持续的键值存储，比如BerkeleyDB []，Cassandra []，MongoDB[]依赖复杂的存储内部数据结构（BTrees或hash表）来存储数据。使用传统的IO操作遍历这些数据结构，导致多个相关访问，消耗主机CPU周期且需要系统互联的多个交叉。卸载这些相关访问可以消除更多的延迟。
在Key-Value中提供key-value操作。提供三个RPC函数：PUT()：插入或者更新一个键值对；GET()：检索一个值对应的关键字；DELETE()：删除一个键值对。键值对存储在哈希表使用开放链接来避免碰撞。
Key-Value在主机上计算hash值，并使用hash值在Willow中的SPUs间分布散列桶。GET() 和DELETE()调用：pass hash值和关键字；PUT()：包含值和关键字。三种RPC调用以bucket的数据来操作，每个都包含一个链表的键值对　　及其匹配的散列值。SPU以最短的DMA请求序列遍历链表。
使用MemcacheDB评估Key-Value。
我们比较MemcacheDB的三种配置。

4.6 File system offload
Append允许Direct-IO从用户空间增加数据到一个文件且更新相应的元数据。
Direct-IO

5、 方案的优缺点

很多项目基于bulk计算，Willow就是个合理的实例。Willow超越了bulk，包括修改设备语义、允许编程者在SSD上实现复杂控制密集的操作。一些NICs已使用了这种方法。项目[1，2，4，5，6，7，8]证明：将这些功能移到SSD中是有价值的，这种可编程SSD为提升应用程序和操作系统代码性能提供了可能。
Willow的目标是开发一个可编程的、一流特性的SSD接口，使它更容易　　在存储设备上添加新的、特定于应用程序的功能。我们的六个SSD示例应用程序证明Willow是足够灵活、能够实现大范围SSD的应用，且我们编程经验已证明构建、调试、改善SSD Apps是很容易的。
Atomic-Writes是一个成功的例子，Willow版本的ShoreMT流出事务，事务包含紧接的几个小更新。发送LOGWRITE() RPCs的开销损坏了性能。为了减小这些开销，实现了一个新的VECTORLOGWRITE()，它在一个但RPC中发送多个IO请求到Willow。
为HREs和SPUs提供一个统一的、通用的、简单的编程接口使得Willow使用简单。SSD Apps的可组合性很实用。
目录