Exploring Design Challenges in Getting Solid State Drives Closer to CPU

Exploring Design Challenges in Getting Solid State Drives Closer to CPU

1. 摘要

Abstract—The PCI Express Solid State Drives (PCIe SSDs) blur the difference between block and memory access semantic devices. Since these SSDs leverage PCIe bus as their storage interface, their interfaces are different from conventional memory system interconnects, as well as from standard storage interfaces. This leads to a new SSD architecture and storage software stack design. Unfortunately, there are not ample studies focusing on the system-level characteristics of these emerging PCIe SSD platforms. In this paper, we quantitatively analyze the challenges faced by PCIe SSDs in getting SSDs closer to CPU, and study two representative PCIe SSD architectures (from-scratch SSD and bridge-based SSD) using state-of-the-art real SSDs with our in-house resource analyzer and dynamic evaluation platform. Our experimental analysis reveals that 1) while the from-scratch SSD approach offers remarkable performance improvements, it requires enormous host-side memory and computational resources; 2) the performance of the from-scratch SSD significantly degrades in a multi-core system; 3) bridge-based SSD architecture has a potential to improve performance by co-optimizing their flash software and controllers; 4) PCIe SSDs’ latencies significantly degrade with their storage-level queueing mechanism; 5) tested PCIe SSDs consume 200% ∼ 500% more dynamic power than a conventional SSD; and 6) the power consumption increases by 33%, on average, when PCIe SSDs suffer from the performance drops caused by garbage collections. While our analytical study based on real PCIe SSD products includes technical conjecture and inference, the findings and the empirical evidences present many design challenges that the future architecture and software stack probably need to address.
PCIe SSD设备使得块设备和内存访问语义设备之间的差异更加模糊不清。由于SSD设备使用PCIe总线作为存储接口，这个接口不同于传统的内存系统互连，也不同于标准存储接口。这导致了新的SSD架构和存储软件栈的设计。不幸的是，目前还没有足够的研究集中于这些新兴的PCIe SSD平台的系统级的特性研究。在本文中，我们定量分析了PCIe SSD所面临的挑战（使SSD越来越接近CPU），并研究两种具有代表性的PCIe SSD架构（from-scratch SSD和bridge-based SSD），在我们内部资源分析器和动态评估平台采用先进设备、最先进的SSD。我们的实验分析表明：1），当from-scratch SSD方案提供显著的性能改进时，它需要巨大的主机端内存和计算资源； 2）from-scratch SSD的性能在多核系统中显著降低； 3）通过联合优化Flash软件和控制器的性能，bridge based SSD架构有提高性能的潜力；4）PCIe SSD的延迟显著降低了其存储级排队机制；5）测试的PCIe SSD的消耗是传统的SSD的200％〜500％动态功耗；6）当PCIe SSD设备因垃圾回收而性能下降，功率消耗平均增加了33％。虽然我们的分析研究基于真实的PCIe SSD产品，包括技术猜想和推理，结论和实证证据提出了许多设计挑战，和未来的架构和软件栈可能需要解决的问题。

2. 现有背景下的问题

在过去的几年中，基于NAND Flash的SSD设备广泛应用于计算机系统，一般都作为块设备的替代或者存储缓存使用，但Flash的性能比标准存储接口好很多，如图近二十年，SATA接口和PATA接口的带宽增长很少，但是SSD设备带宽增长了很多。故学术界和工业界已开始考虑将SSD设备从I/O控制中心（南桥）移出，将其使用在更接近CPU的地方。PCIe SSD设备是迄今为止集成Flash到处理器内存中最简单的方法之一。通过开发PCIe接口的优势，延迟预计保持在接近DRAM的水平。
 
然而，由于这些SSD技术视PCIe总线作为存储接口，这些接口不同于北桥的常规内存互连，也不同于南桥的存储接口。在新的SSD接口下，数据移动管理和底层Flash存储管理使得PCIe SSD成为SSD架构和附带软件堆栈设计发展的一个关键里程碑。不幸的是，这些新出现的PCIe SSD平台的系统特性到目前为止很少受到关注，且固态硬盘背后的挑战和软件技术基本上未被开发。
在这篇文章中，我们定量分析闪存作为PCIe SSD在更靠近CPU端，所面临的挑战，研究两个典型的PCIe SSD架构和flash软件栈：from-scratch PCIe SSD 架构和bridge-based PCIe SSD架构。From-scratch PCIe SSD使用自底向上的方法，使用基于FPGA或ASIC的本地PCIe控制器；且进一步优化了本地PCIe控制器上的flash软件栈，以试图最大化存储和数据处理效率。与此相反，Bridge-based PCIe SSD利用传统的高性能SSD控制器，采用板上的PCIe-to-SAS（或-SATA）桥接控制器。
本文主要贡献：
1) Characterizing the performance of the emerging PCIe SSD architectures；
2) Analyzing host-side resource usages on different flash memory storage stacks.
3) Addressing the challenges introduced by PCIe SSDs as shared resources.
4) Characterizing dynamic power consumption of PCIe SSD.
5) Real storage workload evaluations.

3. 提出的解决方案

3.1 解决方案综述

如图2显示了从计算机体系结构方面的一个典型的南北桥结构。CPU通过北桥（内存控制中心）直接与内存和PCIe设备连接。而南桥（I/O控制中心）处理外围低性能设备，主要是与I/O相关的功能。现在的架构将南北桥一体化，集合在一个处理器芯片上，存储设备通过传统接口（SATA/SAS）连接I/O控制中心，此接口成为开发flash性能的主要瓶颈。因此，可将SSD设备从I/O控制中心中提出来，尽可能将flash放在靠近处理器端。 
 
让Flash更接近计算单元，需要Flash有更短的延迟值和更高的吞吐率，相比于传统的存储设备。由于PCIe SSD平台的适配器因数（在使用多个Flash package和SSD控制器的时候，允许他们分配更多的空间），PCIe SSD在更好的位置，可以收获更高的并行性，比传统SAS/SATA SSD设备。 除了PCIe总线的大容量，这种并行性使PCIe SSD设备减少延迟的同时，增加了吞吐量，相比单一的SAS/SATA SSDs。 此外,他们也提高 flash软件栈的性能。在这节中,我们将讨论两个代表作为PCIe SSD的体系结构和相应的flash软件栈。

3.2 PCIe架构

1 Bridge-based PCIe SSD
如图（a）显示了Bridge-based PCIe SSD架构，使用了多个传统SSD控制器，每个处理器管理下层Flash包，像单一的SAS/SATA SSD。因为PCIe总线和存储接口之间存在一个接口差距，这样的内部SSD控制器也连接到一个PCIe-to-SAS （SATA）桥控制器，连接上层的外部PCIe连接和下层内部SAS连接。桥控制器内部将PCIe协议转换为SAS协议，所以它可以利用现有的 SSD技术和提供高兼容性。另外，桥控制器将到达的I/O请求条带分布于多个SSD控制器，这类似于RAID控制器提高存储级并行性的方法。因此，bridge-based SSD架构可以暴露一个聚合SAS/SATA SSD性能到PCIe root complex (RC)设备，RC连接内部PCIe fabric（由一个或多个桥控制器组成）到处理器内存复合体。
 
 
2 From-scratch PCIe SSD
Bridge-based SSD架构的一个挑战是在内部转换不同的协议和处理I/O请求的性能开销很高，需要使用多个控制装置，从CPU到Flash。出于这一点，from-scratch PCIe SSDs被开发出来，使用从低向上的方法，通过互连NAND Flash接口和外部PCIe链接，如图3(b)所示。因为PCIe接口是一组点对点链接，PCIe RC和Flash接口之间的连接通过一个或多个转换设备实现。每个内部转换设备处理多个PCIe端点(EPs)。PCIe EP有独立的上游和下游的缓冲区，在Flash内存上面控制出入境的I/O请求。这种可扩展的架构很容易扩展存储容量，通过将更多的闪存芯片放置到它的PCIe网络拓扑中，并直截了当的暴露真正的NAND Flash的性能给上层processor-memory子系统。这些from-scratch PCIe SSDs的PCIe Eps和转换也以本地PCIe控制器的形式实现，flash软件可以优化，以减少延迟和提供更好的吞吐量。
 

3.3 Flash软件栈

1 Storage-side flash firmware
一般来说，大多传统的SSD和bridge-based PCIe SSD中，存储端控制模块在存储设备端以“Flash固件”形式实现。在存储端Flash软件栈中，硬件抽象层（HAL）处理底层NAND Flash的命令并管理I/O总线，在SSD控制器和个人Flash内存的内部寄存器间移动数据（如图3a）。在HAL的最上面，构建的是主要的flash软件模块，如FTL、缓存、磨损均衡器和垃圾回收器。在flash软件模块间，FTL是管理Flash和地址转换的核心逻辑。最后，在flash软件的上层，还有一个主机接口层，主要负责协议转换、解析传入的I/O请求并调度。这个传统的flash软件堆栈让SSD公开底层的Flash给processor-memory复合体， host-side存储堆栈没有任何修改。
2 Host-side flash software module
Flash软件可以更有效地管理底层的闪存，它可以访问主机端资源如文件系统、高速缓存和I/O调度器信息。故建议尝试迁移flash软件到主机端（如图3b）。此外，通过在主机端实现flash软件模块，我们可以：1)统一间接flash软件逻辑[6，4，3]；2)通过利用主机端丰富的计算和内存资源[ ， ]，重叠存储和数据处理时间。特别的，文献[ ]中提出虚拟存储层和直接文件系统，通过将flash软件模块从存储端移动到主机端（特别是FTL），故可以优化数据访问并提供广泛的OS支持。文献[ ]统一了FTL和主机端文件系统，移除了直接地址映射。文献[1]当遇到写密集负载时，将内部缓存移动到主机端以提高性能。文献[2]将垃圾回收器和页分配器[ ]从SSD迁移到主机端软件堆栈。由于这个flash软件模块的迁移，from-scratch SSD 可以最大化吞吐率的同时减小延迟。

3.4 实验配置

PCIe test-beds：从两个不同的供应商，我们选择了两个最近发布的、前沿PCIe SSD。我们的目标并不是对这些商业产品执行反向工程，而是理解这两款PCIe SSD的关键设计参数（关于SSD更接近CPU的参数，比如内存使用、CPU利用率和功耗。FSSD：代表from-scratch SSD；BSSD：代表bridge-based SSD。表1是SSD设备的参数。应该注意到的是，虽然这两种SSD架构基于不同的设计理念，但是PCIe SSD设备针对的是提供低延迟和高吞吐率，且主要用于工作站。
 
为了更好地理解主机资源利用率和功耗，我们还测试了一个受欢迎的SATA-based SSD(SATA SSD)作为参考设备；SATA SSD由256GB的MLC闪存、三个Coretex ARM核、256 MB的内部DRAM，以及使用内置Flash固件模块组成。
System configuration：我们的实验系统还配备了一个Intel四核i7 SandyBridge 2600 3.4 GHz处理器和“16GB”的内存(4个4GB DDR3-1333 MHz内存模块)。在此系统中，所有的北桥芯片功能驻留在CPU，所有的SSD通过PCIe 2.0接口连接到SandyBridge。我们执行测试使用自己的测量工具和功率分析仪(稍后将对此进行解释)。然后我们存储日志和输出结果到单独的块设备，以完全异步的方式；系统分区和文件系统上都没有创建我们的SSD test-bed。注意，该配置允许每个SSD test-bed完全与评价方案和工具分开。
Measurement tool：我们修改了一个英特尔开源存储工具,叫做Iometer[],捕获时间序列的性能特征和主机端内存使用量。测量给定时间的内存使用率，我们添加了一个模块调用GlobalMemoryStatusEx到Iometer，这是一个Windows系统功能，允许用户检索当前状态的物理内存和虚拟内存。此外，为了减少连续评估的干扰，我们修改Iometer物理擦除底层设备的整个区域，通过SMART上面的一个secure erase command，在每一个初始化步骤，为了评估不同的I / O访问块大小和访问模式下的写性能。还应该注意的是，Iometer可以访问SSD，绕过文件系统的特定缓冲区，这使我们能够通过Flash软件模块测量主机端资源使用。
Dynamic power analyzer：我们还建立了一个内部的功率评价平台，它可以捕获动态功率值，在不同的工作负载以实时的方式。动态功率分析仪的总体架构，可以连接到主机系统作为扩展卡如图4所示。我们的分析仪采用一个ARM核心、I/O功率接口、电流监测器和一个微控制器。微控制器检测目标SSD使用的当前值，通过一个小分流电阻(0.01∼0.01欧姆)。ARM核将其转换成功率，并每隔10毫秒传输到主机，使我们获得真正的动态功率值，这些值由我们试验台中不同的内部资源表现出。应该指出，我们的功率分析仪不包括主机端PCIe PHY层的功率，这意味着PCIe SSD的实际功耗可以更高(如果我们考虑整个PCIe协议栈的功率)。
 
Workloads：我们评估试验台，在不同的访问模式、不同的访问粒度（从512 B到1MB）下。此外微基准测试工作负载，我们还描述不同的实际存储工作负载下的设计挑战，其中包括数据库查询(OLTP),系统监控服务器(Monitor),文件服务器(File1 File2),元数据服务器(Meta),媒体流工作站(Stream),项目存储库服务器(Repo),代理服务器和防火墙(Firewall)[][]。这些真正的存储工作负载的重要特征是描述在表2。
 

4. 资源管理的挑战

4.1 内存使用

（1）Overall memory usage evaluation.
从图5可以看出，FSSD需要至少1.7GB内存用于写和1.5GB内存空间用于读取；而BSSD只需要0.6GB内存空间，无论I / O类型和大小。由于flash软件迁移,主机端内核驱动程序需要更多的内存空间用于加载flash软件模块镜像和包含它们的内存结构。此外,我们相信,有两个主要原因FSSD平均消耗内存空间是BSSD的16倍。首先，直接文件系统[3]和迁移的flash软件[ ,4,2],需要主机端内存保存巨大的映射项和相应的数据结构（用于细粒度的地址转换）。其次,主机端写缓冲区缓存消耗内存空间，在隐藏底层闪存的复杂性方面,如垃圾回收[],耐力[]和固有的延迟变化[]。例如，如图5所示，FSSD内存使用不同的访问粒度和模式，而BSSD的内存使用在相同的粒度和模式下。这是因为,在bridge-based SSD架构，SSD实现映射表，数据处理只在存储器端。此外，FSSD读访问内存使用随着访问粒度变大而增加约8%。我们猜想，这是因为FSSD的主机端Flash模块执行read-oriented（定向读）操作，如readahead和prefetch。
 
 
（2）Time series analysis.
图6示FSSD(上)和BSSD(底部)的内存使用量。在该测试中,块访问粒度为512B，因为所有的系统级的操作都是基于块且默认块大小为512B。此外，我们完成了内存使用量测试基于两个不同的I / O访问场景：1)异步(队列)模式操作,使用128个队列项；2)同步(遗留)模式操作，无论设备是否可服务一个I / O请求，提交请求。从这个数字可以看出：在I/O进程刚开始的时候，为了处理两个队列和遗留的模式操作，FSSD大约需要2GB的内存空间。有趣的是，随着I / O进程的进行,内存的使用量不断增加，以对数的方式达到约10GB。
 
 
应该注意的是,考虑到目标系统是一个工作站，拥有4 GB∼12 GB，我们相信只花费10 GB内存来管理底层的SSD，在许多应用程序中可能是不可接受的。相比之下，BSSD保持内存使用量约0.6GB在整个时期。我们相信，为什么FSSD的内存使用量随着时间的推移不断增加，那是因为主机端的地址映射和缓存算法。特别是，DFS/VFS[3]使用B树结构来映射物理地址和虚拟空间地址，这往往会增加内存需求来保存映射信息，因为要通过添加更多的节点项为传入的I / O请求服务。我们也相信,巨大的内存使用主要是由于主机端的缓冲区缓存导致，它主要用于隐藏下层Flash的延迟变化、减少垃圾回收开销。
（3）Real storage workload analysis.
图8比较FSSD和BSSD在不同存储工作负载下的内存使用量。尽管FSSD在实际存储工作负载下需要更少的内存空间（相比于缺省块大小工作负载），它仍然会消耗更多的内存空间比BSSD 105%∼330%。BSSD所需的系统内存空间是持久不变的(0.7GB∼0.8GB)，无论使用哪个工作负载；而FSSD内存所需随着工作负载的类型而变化。如图7所示，我们也分析FSSD和BSSD在前3500秒执行I / O的内存使用，以便更好的理解实际存储工作负载的内存使用行为。BSSD使用的软件堆栈平均消耗0.8GB内存(因此它需要内存空间类似于SATA SSD)，而FSSD随着I / O进程的执行，不断增加内存消耗。
 
 

4.2 CPU使用

（1）Overall CPU usage evaluation.
图9(a)和9(b)给出了主机端读和写的CPU使用。类似于内存使用分析，FSSD需要的计算功率大约是BSSD的三倍，除了访问粒度大于16KB的情况。我们猜想， FSSD对细粒的I / O访问需要更高的CPU使用率(52%∼87%)的一个主要原因是：较小的I / O请求导致需要更大的地址映射表用于查找和更新 (或host-side缓冲区的高速缓存线路)。与此形成鲜明对比的是，对于相同的I / O服务，BSSD只消耗20%∼30%。这是因为映射表的查找和更新在主机端执行。因此，主机端的计算资源更容易获得(可以分配给其他有用的应用程序),但是在不同的I / O访问模式下，很难实现持续的性能。
 
（2）Time series analysis
图6(b)对比了CPU FSSD(上)和BSSD(底部)的使用率，在有大量的默认的块大小访问的工作负载下。和之前一样，我们评估PCIe SSD试验台的传统模式和队列模式操作。FSSD传统模式操作下，持续消耗主机端CPU60%的周期，且队列模式操作下的I / O服务比传统模式需要的CPU周期多50%。我们相信仅仅I / O处理需要的CPU使用率就超过60%，则总体系统性能会降低。相比之下,BSSD只使用了20%的CPU周期，不管在什么I / O操作模式下。
（3）Real storage workload analysis
图10显示了真正存储工作负载下，FSSD、BSSD和SATA SSD的平均CPU使用率。从这个图可以观察到，尽管FSSD整体上，实际存储工作负载比微型基准测试工作负载时使用较少的CPU，但它的CPU平均使用量，仍大于BSSD的400%。图11显示了FSSD、BSSD和SATA SSD的CPU使用率的时间序列分析。该系统采用FSSD消耗130%,70%,85%的 CPU功率比BSSD，在OLTP、监控和防火墙的工作负载下。为什么BSSD需要的CPU功率略高于SATA SSD(4%∼6%),我们猜想，这是因为作为PCIe总线的队列管理机制比SATA接口更为复杂(如相比于SATA，PCIe有更多的队列项和不同的通信协议)。
 
 

5. 系统性能挑战

5.1 Overall performance comparison

很难直接比较两种不同SSD架构的微观性能特征，因为他们的flash软件和平台有不同的优化技术。例如，我们发现BSSD默认块大小访问的随机写操作的延迟和吞吐量，比顺序写入好7倍左右；这与大多数现代SSD展现的相反。我们怀疑，这是因为BSSD把到来的缺省块大小的I / O请求放入内部2GB DRAM缓存和传统非易失SRAM中，但将面对底层闪存的大尺寸的I / O请求，这会反过来表现出意想不到的性能。此外，BSSD可能获益于多个存储接口而带来的一些好处(如SAS / SATA)，可以公开内部SSD的总带宽。因此，我们比较BSSD和FSSD的整体性能。图12a和12b对比FSSD和BSSD之间的延迟和IOPS。我们看到，大多数BSSD延迟值平均比FSSD糟糕 39%，这与SSD芯片手册上的信息相反(见表1)。我们相信，BSSD的多个控制器、间接地址映射模块和协议转换在数据通路上的开销（从CPU到Flash的数据通路），导致了这一更长的延迟。
 

5.2 Multi-core system environment

评估多核系统环境中性能的影响，我们在FSSD和BSSD上，并行(512B粒度和128个队列项的随机存取)执行不同数量的I / O处理worker(介于1和8)。结果， FSSD、BSSD作为共享资源考虑，绘制在图13和14。FSSD和BSSD延迟随着worker数量的增加而增加，worker是Iometer多线程的工作负载生成器。具体来说，FSSD BSSD上，八个worker的平均延时值比四个worker多118%和108%，分别比单个worker多289%和704%。吞吐量的变化趋势与延迟的趋势略有不同。虽然通过增加worker的数量，BSSD的IOPS没有增加，但FSSD的 IOPS有增加。FSSD中，四个worker的IOPS是单个worker的2.2倍。然而，多个worker带来的优势有所降低，因为更高的内存和CPU使用。相比之下，BSSD显示出类似的IOPS和主机端资源使用率，不管worker的数量是多少。我们认为，这是因为，BSSD中所有的flash软件实现，不知道主机端系统的信息 (如系统生成的worker的数量)。此外，它还可以推断，两种SSD设备(有许多worker)支持的请求的并行度，高于最大的内部并行性度（一旦请求并行匹配内部并行性，其他未完成的请求只额外增加了队列的长度，从而增加延时值）。
 
 

5.3 Queuing latency

设备层的排队机制是至关重要的组件之一，它可以提高存储器的吞吐量。例如，NVMe协议提供了64K个队列项[]。SAS / SATA[],[]还提供了一个设备-驱动队列机制，允许存储设备来确定执行I / O请求的顺序，而没有任何主机端软件中断。然而，我们观察到，with a 排队方法，不管何种SSD架构，延迟值大幅降低。如图15所示，FSSD的随机和顺序写延迟比传统模式延迟长，约为106倍。同样，BSSD的队列模式操作比传统模式，延迟长99倍。尽管这不是一个令人惊讶的观察，我们认为，队列操作模式的这些显著的延迟降低，对使闪存更接近内存-处理器子系统，将是一个有问题的障碍；因为事实上，常规内存模块只需要几十纳秒,我们相信延迟从几毫秒到一百毫秒，在许多应用程序中可能是不可接受的。
 

5.4 Garbage collections：

图13a和14a(在128队列条目下默认块大小的随机访问)也显示出FSSD和BSSD有关管理底层的垃圾收集(gc)的不同。虽然FSSD提供了极为持久性能，BSSD在开始执行一半的I / O时，延迟和吞吐量值下降。这主要是因为GCs是一系列SSD内部任务（读取数据从旧闪存块、写新的块、清除旧的块）。GC造成的这种性能的下降也称为write cliff [ ]。FSSD表现持续性能背后的原因之一是充足的host-side缓冲区和优化的flash软件栈。应该指出，BSSD也雇佣了一个2GB的内部内存作为缓冲区，但不能隐藏GC开销，这意味着FSSD的持续性能并不仅仅来自于可用的缓冲区。

6. 功耗挑战

为了更好地理解的功耗问题，在本节中，我们首先把PCIe SSD试验台与SATA-based SSD设备连接到南桥—这种SATA SSD在存储设备端使用所有flash软件模块并比FSSD提供更多存储容量（高25%），通过使用更多的MLC Flash。然后我们深入挖掘每个PCIe SSD的功耗行为(即FSSD和BSSD)。最后，我们比较主机端计算单元和SSD设备本身的动态功率。

5.1 Write power consumption analysis

图16a显示了整个动态功率值（在不同的I / O访问模式，随机或顺序访问；不同的访问大小，4KB∼1MB）。虽然SATA SSD消耗少量的功率--从1.5瓦特2.2瓦特；FSSD需要更大数量的动态功率从11.7瓦特14.5瓦特。具体来说，FSSD动态功率消耗高于SATA SSD的 300%∼1000%，尽管它提供存储容量低于SATA SSD。
 
从这个数字可以看出，尽管BSSD的功耗行为比FSSD更好，BSSD也消耗9瓦∼15瓦，平均高出SATA SSD的动态功率值的600%。我们相信，这些高功耗行为可以使PCIe SSD难以部署在许多计算域。PCIe SSD消耗更多的电量比SATA SSD的主要原因之一是，PCIe接口允许每个SSD设备25瓦的最大功耗（更大的模式因子）。因此，它可以使用更多的内部组件比如多个计算资源，这使得PCIe SSD不仅是高性能设备，而且是大功耗设备。
5.2 Read power consumption analysis
我们还分析了动态读功耗，如图16b所示。从这个数字可以看出，FSSD消耗12瓦∼18瓦特，平均高于SATA SSD340%。有趣的是，尽管写底层NAND闪存数据需要更多的能耗比读，我们观察到SSD端的读功耗比写更糟糕。FSSD读比写消耗更多功耗的原因之一是，所有的目标数据应该从后端闪存服务；而写请求可以缓冲在主机端缓冲区(16 GB DRAM)。换句话说，因为所有的读操作将从SSD-side处理，读比写操作可以消耗更多的能耗。相反，BSSD展现出类似的读写功耗的行为，除了它顺序大粒度的I / O访问的情况下。我们推断，这是因为顺序存取模式允许BSSD激活更多的闪存介质，比较小的随机I / O访问。
 

5.3 Time series analysis

图17和17 b显示一组时间序列动态功耗与固态硬盘原有的地位和年龄写ssd,分别。而SATA SSD消耗98%更高的能量随机写入数据50分钟后,FSSD为第一次2小时,提供可持续的电力消耗,消耗更多的权力之后,只有16%。同样,BSSD消耗动态功率大约8瓦,和消费只有13%甚至更多的权力结尾的I / O处理。即使这些作为PCIe SSD展览持续功耗行为,应该注意的是,在总功率分析,证明FSSD和BSSD需要更多的权力比SATA SSD约500%和300%,分别,这不是在之前的研究观察到[21]。
老年人SATA SSD需要峰值功率在刚开始的时候的I / O服务、随机和顺序访问。尽管老年人BSSD和FSSD容忍的最大力量增加了几分钟,它消耗200%∼300%更多的权力比SATA SSD。我们认为,这是由于分散物理数据布局(由于老化)会引入额外的内部I / O操作,如垃圾收集,从而反过来激活更多的内部资源。相比之下,对于读请求,所有SSD试验台我们评估提供一个持续的动态功耗性能如图17所示。与写道,这些功耗行为并不显著的I / O访问模式。而不同的I / O访问模式内部会引入额外的I / O操作由于垃圾收集,耗损均衡,和这种忽冷忽热的数据管理、读取并不是我。
作为PCIe SSD的总之,我们测试需要更多的动态功率比传统SATA SSD 200%∼500%。我们相信,这种高动态能耗问题的一个挑战,需要解决ssd为了得到更接近未来的计算单位。

5.4 Real storage workload analysis
5.5 Comparison of CPU and SSD power usages

7. 系统含义及讨论

Co-operative approach：总之，我们观察到，尽管FSSD的性能优于bridge-based SSD，前者需要巨大的host-side资源，在许多情况下，这是不可接受的。我们相信，这种部分迁移flash软件功能从SSD到主机端[2，4， ， ]，的方法可以是一个有前途的中路解决方案，实现更高的性能和更低的主机端资源消耗。例如，FTL分区[4，8] 只有移动地址映射模块而不是整个FTL内核。同样的中间件和固件合作方法[2]只迁移需要更少系统内存资源的某些flash模块，比如垃圾收集器，I/O调度器。
All-flash storage arrays：基于PCIe SSD的全flash阵列或SSD RAID系统可以直接体验主机端资源挑战。例如，如果系统设计师建立一个基于FSSD RAID5系统，它需要大约50GB的内存空间，且他们必须仔细设计处理器来管理底层五个FSSDs。如果设计者构建RAID BSSD，并打算通过分段所有传入的I / O请求到五个BSSDs提高性能，他们需要仔细地管理全局GC。这是因为概率，系统可能遭受GC带来的性能下降[ ]。
Limits of real device based analysis：即使我们分析不同设计的挑战使SSD接近计算单位，可能有一个由当前真实闪存驱动研究的设计空间带来的限制。例如，基于from-scratch的PCIe SSD采用ASIC控制器，功率消耗低于FSSD，我们已经测试过，这是由于其内部基于FPGA的解决方案。同样，可以在两种代表性的SSD的架构上，设想各种各样的flash软件实现，它可以解决意外的主机资源使用和我们透露的能耗特点。还应该指出的是，write cliff不是bridge-based SSD架构本身的固有问题，而是GC算法和实现的问题。bridge-based SSD的flash端固件在计算能力和嵌入式资源上的极限，GC算法及其实现相对局限(相比host-side flash软件)，可以反过来显示GC开销在我们的实证评价运行时。

8. 结论

在这项工作中，我们定量分析作为PCIe SSD所面临的挑战在闪存接近CPU方面，并研究两种代表性的PCIe SSD的架构和flash软件栈。我们广泛的实验分析表明，未来PCIe SSD架构需要重新设计当前数据路径（从CPU到闪存），通过删除冗余flash控制器和I/O协议。他们的flash软件应该解决多核系统、存储级排队机制、flash的垃圾收集造成的性能急剧下降。此外，PCIe SSD架构和软件模块需要更有效地管理动态功率，因为他们需要更多的能耗，比高端传统SSD 多200%∼500%。
 

9. 参考文献

Jung, Myoungsoo. "Exploring Design Challenges in Getting Solid State Drives Closer to CPU." IEEE Transactions on Computers 1: 1-1.

  R. Koller, L. Marmol, R. Rangaswami, S. Sundararaman, N. Talagala, and M. Zhao, “Write policies for host-side flash caches,” in Proc. of FAST, 2013.
  M. Jung and M. Kandemir, “Middleware - firmware cooperation for high-speed solid state drives,” in Proc. of Middleware D&P, 2012.
  W. K. Josephson, L. A. Bongo, K. Li, and D. Flynn, “DFS: A file system for virtualized flash storage,” in Proc. of FAST, 2010.
  Y. Zhang, L. P. Arulraj, A. C. Arpaci-dusseau, and R. H. Arpaci-dusseau, “De-indirection for flash-based ssds with namelesswrites,” in Proc. of FAST, 2012.
  “An evaluation of different page allocation strategies on high-speed SSDs,” in Proc. of HotStorage, 2012.
  A. C. Arpaci-Dusseau, R. H. Arpaci-Dusseau, and V. Prabhakaran, “Removing the costs of indirection in flash-based ssds with namelesswrites,” in Proc. of HotStorage, 2010.
  M. Jung and M. Kandemir, “Revisiting widely held ssd expectations and rethinking system-level implications,” in Proc. Of SIGMETRICS, 2013
  M. Jung, C. ik Park, and S.-J. Oh, “Cooperative memory management,” vol. US 2008189485, 2008.
  S. Swanson and A. Caulfield, “Refactor, reduce, recycle: Restructuring the i/o stack for the future of storage,” Computer, 2013.
  M. Jung, W. Choi, S. Srikantaiah, J. Yoo, and M. Kandemir, “Hios: A host interface i/o scheduler for solid state disks,” in Proc. of ISCA, 2014