Empowering Architects and Designers: A Classification of WhatFunctions to Accelerate in Storage

Chen Zouchenzou@uchicago.eduUniversity of Chicago

Andrew A. Chienachien@cs.uchicago.eduUniversity of Chicago

ABSTRACTStorage acceleration is a topic of widespread study and innovation.We seek fundamental understanding of 1) what computations tooffload to benefit application performance and scalability and 2)how the properties of such computations shape offloading benefits.Using raw-data analysis as an exemplar, we study accelerationbenefits using SparkSQL operating in a cloud data center, analyzingwhere and how speedup and scalability are improved.

From this base, we analyze 14 function offload candidates drawnfrom 17 research studies to create a classification to help the appli-cation or hardware system designer. We analyze from the perspec-tive of feasible acceleration, network data reduction, and softwarechange - for application and system software. These studies identifyfunctions that are clear wins and should be the target of early “com-putational storage”, those that give clear benefit, but face softwarechallenges to support, and finally those that are less compelling.

1 INTRODUCTIONThe past two decades have seen explosive growth in large-scale data,ranging from scientific research (particle accelerators, moleculardynamics, weather modeling and so on), internet services (websearch, e-commerce, social networking, music and video streaming)to nearly every aspect of the economy and society through theexplosion of data science and analytics. More recently, the successof machine learning in delivering function from data has acceleratedthis trend. These data sets range from a few hundred gigabytes to100’s of petabytes [4, 9], and their efficient storage and processingis the raison d’etre of massive and rapidly growing global networksof both HPC and commercial data centers [1, 3, 8].

While rotating storage (HDDs) remains the cheapest capacitystorage, the continued scaling of NAND flash[14] has reduced thecost of SSD capacity sufficiently such that its superior bandwidthand IOPS performance make it a mainstay of the modern datacenter.Leading enterprise SSDs can reach 3.5 GB/s and 720K IOPS [13],and consumer SSDs exceed 3 GB/s and 300K IOPS [10] at a muchlower cost.

How to best divide computation across compute and storage haslong been important to system performance and cost-effectiveness,and the subject of research going back to the 1990s [18, 42]. But re-cent rapid increases in storage device capability have shifted scalingand cost bottlenecks in the modern HPC or cloud datacenter archi-tecture onto the CPU and interconnect (see Figure 1). This changingbalance has reopened a set of critical research questions about whatkind of acceleration is beneficial, how to redistribute work andrebalance systems, should acceleration be added to compute orstorage, etc. The community has seen an explosion of research[22, 24, 32, 39, 45, 46] and innovation [37, 47] exploring specific ap-proaches to storage acceleration. Terms such as “cognitive storage”

Figure 1: Modern Datacenter Architecture: Separate com-pute and storage layers.

and proposals for full compute functions in storage nodes considera reversion to 1st generation datacenter architectures as seen inFigure 1.

In this exciting, but chaotic environment, our approach is toaddress a focused question. Presuming datacenter operators want topreserve the modern datacenter architecture and associated usagemodel (allocate compute, share storage), we explore the questionsof what computations give benefits when accelerated and offloaded tostorage?. And, can we provide more general guidance to applicationsand datacenter hardware architects on what acceleration to includeon storage nodes/devices?

We first perform a case study, using a raw data analytics sys-tem, exploring the performance impact of storage-side acceleration.We consider both in-storage node and in-storage device accelera-tion, assessing opportunities for improved performance and systemscalability. The study gives insights into the best location for accel-eration and its quantitative benefits. Second, we perform a broadliterature study of the computations being considered for storageacceleration, analyzing the properties of these computations andhow said properties affect performance benefit. This analysis buildson insights from our raw data analytics case study and produces aclassification that guides both datacenter hardware architects andapplication designers in understanding what functions can benefitfrom storage offload, as well as which require significant softwarechanges – application and storage system – and thus have benefitsthat are more difficult to realize. Specific contributions of the paperinclude:

• Using a case-study of raw data analytics with a multi-stageheterogenous pipeline structure, we characterize quantita-tively the benefits of storage-side in-node and in-device ac-celeration. Latency improves 4.5x and scalability 14.9x (geo-metric mean, TPC-H benchmarks)• Analysis of key properties (acceleratable, network data reduc-tion) of 14 proposed computations for storage accelerationand used in 17 research studies of proposed accelerationsystems. These computations are drawn from filesystem,database, and application computations.

Chen Zou and Andrew A. Chien

• Creation of simple criteria that identify the acceleration func-tions datacenter hardware architects should target (perfor-mance benefit, little software support required), and “stretchcapabilities” functions – that require application (program-ming), system (addressability and access), and operational(resource management) software change to deliver benefit.• We present empirical studies of selected functions (filter,parse, neural network inference, compress, cryptography,serialize/archive, and select) to illustrate potential perfor-mance benefits, and to show the power of the classificationcriteria to identify the most beneficial functions for offload.

The rest of the paper is organized as follows. First, we coverthe background of raw-data analytics and accelerators in Section 2,and the opportunity of offloading in Section 3. Next, we describethe methodology for our raw-data analytics experiments (Section4), and follow with the experimental results in Section 5. We thenundertake a literature study of proposed offload candidates, produc-ing a function classification Section 6. Empirical studies illustrateoffload in Section 7, and demonstrate the power of the classificationcriteria. Related work is discussed in Section 8, and we summarizeand point out interesting directions for future work in Section 9.

2 BACKGROUND2.1 Analytics and Raw-data analyticsWe study on-demand raw-data online analytical processing (OLAP),a common workload for analysis in data lakes. OLAP’s goal isto answer multi-dimensional analytical queries swiftly [21]. On-demand raw-data OLAP eliminates the extract-transform-load(ETL)and storage overhead in the normal workflow where raw-data isfirst transformed and loaded to the database. Instead, on-demandraw data processing performs analytical queries on the raw datadirectly. Such raw data analytics workloads are heavily compute-intensive and amenable for storage-side acceleration. Promisingcandidates for acceleration in data lake storage include parsing andfiltering.

2.2 Acceleration HardwareThe study explores acceleration benefits and impacts in storage-side offloading. For system-level performance studies, we needan accelerator framework. Many accelerators have been proposed[23, 24, 26, 32, 35, 43]. For this paper, we choose the unstructureddata processor (UDP) and the ACCORDA raw data analytics system[25, 26]. UDP is flexible, cost-effective(∼ half the silicon area of aSkylake core) and power-efficient(∼ 1/10 power of a Skylake core),which stem from a carefully customized architecture, and a tradi-tional hardwired implementation (ASIC vs. FPGA). UDP delivers∼20x speedup compared to a CPU for a broad range of data transfor-mation tasks such as CSV parsing, Huffman encode/decode, regexpattern matching, dictionary encode/decode, run-length encoding,histogram, and snappy compression/decompression – relevant forstorage acceleration.

Figure 2: Data center system architecture, accelerators(A)can be integrated per-node or per-storage device.

3 OPPORTUNITY OF STORAGE-SIDEACCELERATION

The opportunity to refactor the data stack involves shifting com-putation from compute to storage nodes and adding accelerationhardware to support it. This shifts work across the typical high-level datacenter organization (Figure 2). In such systems, nodesare divided into compute nodes (CPUs and memories) and storagenodes (storage devices and a little compute). Storage accelerationchanges the balance across this datacenter organization designed toenable separate provisioning and resource management of computeand storage for applications.

The ultimate goal of storage acceleration is to increase perfor-mance (latency to result) and scalability (# of SSDs each CPU candrive, eliminate network bottlenecks). However, storage customersare price-sensitive, so delivering this value at minimum cost is es-sential. Because refactoring has complex performance dynamics, anumber of key research questions are open:

(1) What computation functions benefit from acceleration?(2) What of those are worth offloading? (give benefit from loca-

tion on the storage side of the network)(3) What are the software implications of offloading?(4) Howmuch can application/system performance and benefit?To address these questions, we begin with a study of storage

acceleration in a data analytics system. The goal here is to under-stand in detail which parts of analytics applications are suitablefor offloading and the quantitative benefits. Next, we study a broadvariety of computation functions that are candidates for storageoffload. This study produces a perspective on what function char-acteristics suggest most benefit from offloading, and what class offunctions acceleration hardware should support.

4 METHODOLOGY4.1 Modeling

Workloads. We use all 22 TPC-H queries [16] on raw data forevaluation. These queries span simple select-project-join structuresto more complicated ones with expensive expressions like regexmatching and large intermediate attributes. The queries operateon raw data in tabular format with different fields separated bydelimiter ‘|’. Each field is in text format rather than binary, exercisingthe flat parsing and data type conversion dimensions of raw dataprocessing. We decompose the TPC-H queries as below.Task Elements:• Storage IO: Read raw data from storage devices.• Parse: Parse data for column and row boundaries for selec-tion and conversion (i.e. text int/date to binary)

Empowering Architects and Designers: A Classification of What Functions to Accelerate in Storage

Figure 3: Task elements for a raw data analytics application,data flows from the storage, and with offload is processed,then transferred to the CPU for final query logic.

• Select: Extract needed columns from a database table.• Filter: Filter rows based on a predicate.• Transfer: Move data from storage to compute node for anal-ysis.• Query logic: Execute TPC-H query logic on data at the com-pute node.

These elements are depicted in Figure 3. All three of the parse,select, and filter operations can be run on the CPU or offloadedto the storage-side. Network transfer is shown for one particularmapping, where parse, select and filter are run on the storage node.4.2 System Architecture

Software. We use SparkSQL[15] as the raw-data analysis system.Its query optimizer, Catalyst, generates predicates and pushes theminto the DataSource extension mechanism [11] to reduce data. Wemap the data reduction process onto storage-side acceleration.

Hardware. Compute nodes are a single Skylake-SP CPU (32threads), and HDDs (0.1GB/s, SATA3.0)and SSDs (4GB/s per de-vice) are considered on the storage nodes.

Compute and storage nodes are connected by 40GigE or NVMeover Infiniband. We consider two storage-side execution units: First,a data transformation accelerator (the UDP [25, 26] as discussed inSection 2.2) whose low power and small size make it suitable for in-tegration in-device or in-node. The UDP delivers high performanceon data transformation, scanning, and pattern recognition. Second,we consider an ARM Cortex A53 (4 cores), an embedded processordesign, often included in high-end SSDs and with comparable areaand power to the UDP. A single core of the embedded processor is16x slower (SPECint2000/2006) than a single Skylake-SP core.

Data transfer between compute and storage nodes can be limitedby PCIe connections or the datacenter network. We consider theinterconnect throughput to be sufficient as modeled by 4GB/s (4xPCIe 3.0) for each SSD.

Hybrid Simulation. Application performance is computed by ahybrid simulation technique that measures task elements on a 32-core CPU, storage, acceleration, and network separately and scalesthem appropriately for the modeled system. Three componentsof the total execution time of SparkSQL raw data analytics areall captured in the execution logs. Query logic execution time isunmodified, accelerated tasks are scaled based on the accelerator

Figure 4: Elements of query runtime for 1 thread, 1HDD(light) and 1 thread, 4 SSD(dark) systems with all taskson compute node

Figure 5: Elements of query runtime for 1 CPU,4 SSD system,all tasks on compute node. This is the Baseline.

performance model (for UDP software simulator and cycle timefrom hardware design and for ARM by relative performance), andStorageIO time is scaled considering the modeled storage systembandwidth.

4.3 MetricsWe report per task-element runtime in seconds for each query. Insum, these are the end-to-end application latency. Unless otherwisespecified, the runtime corresponds to a 32-thread implementationon one CPU. We also report CPU-scalability (the number of SSDsthat can be driven by one CPU at the same utilization as in ourBaseline system (1 CPU, 4 SSD).

5 CASE STUDY: RAW DATA ANALYTICSFirst, we present studies that explore the performance implica-tions of offloading of several types and in several locations (instorage node, in storage device, compute-side). We consider dif-ferent mappings of raw data analysis task elements to CPU andacceleration. The results illustrate the complex performance dynam-ics between application stages, mapping, and resources, illuminat-ing a variety of design issues for storage acceleration. Second, weconsider how each configuration affects CPU-scalability, a criticalcost-effectiveness issue. Finally, we consider the cost of accelerationhardware, presenting performance normalized for silicon area andpower.

Chen Zou and Andrew A. Chien

Figure 6: Query runtime for Baseline (light) and withstorage-side Parse & Filter(dark), running on A53 CPU.

Figure 7: Parse & Filter fraction of query runtime for Base-line(light) and with storage-side Parse & Filter(dark), run-ning on A53 CPU.

5.1 Scaling Disk BandwidthWe start with a single thread of a compute node CPU and a singlehard disk drive (HDD) (as in Section 4.1). To show system balance,we increase IO bandwidth by 160-fold from the HDD configurationto a 4-SSD configuration (16 GB/s bandwidth). The result, shownin Figure 4, illustrates the effects of growing storage system perfor-mance. The increase in IO bandwidth from the HDD configuration(lighter, on left) to the 4 SSD configuration (darker, on right) reducestotal runtime only slightly. Since query logic, parse, filter time (allon CPU) dominate the runtime, this and further increases in IObandwidth motivate storage acceleration.

Withmulticore chips, more threads can be applied to the computebottleneck. To model this, we scale compute node runtimes for 32threads (assuming perfect speedup). This produces the results inFigure 5 which we call the Baseline (one CPU, 4 SSD). Despiteperformance overestimation with perfect speedup, query logic,parse, and filter tasks (on CPU) still dominate the runtime while IOremains just below 10%, a small percentage of the overall runtime

5.2 Storage-side OffloadNext, we consider how storage-side offload affects performance.First, we consider a cheap storage node augmentation, adding anembedded-CPU, a Cortex A53 (4 cores) to execute offloaded tasks.1Surprisingly, this offloading reduces performance dramatically, in-creasing runtimes 100-fold! (see Figure 6). There are two reasons1This configuration may be similar to Amazon S3 Select storage nodes [2], rumored touse ARM cores for column select and row filtering tasks.

Figure 8: Query runtime for Baseline(light) andwith storage-side accelerated Parse & Filter(dark), running on UDP.

Figure 9: Query runtime for Baseline(light) and in-storagedevice accelerated Parse & Filter(dark)

for this. First, the much slower ARM cores cause the runtime forparsing and filtering to increase 120-fold. These tasks accountedfor 50-85% of runtime on the CPU, and when shifted to the A53,their share increases to more than 99% (see Figure 7). In this case,offload to the A53 shifts the bottleneck and aggravates it. So, if wedo not have suitable hardware accelerators, offloading can be harm-ful to performance. Second, the data size reduction of storage-sidefiltering alone yields little benefit as the data transfer is a negligiblefraction of overall runtime. From these results, it is clear that offload-ing from the compute nodes does not always increase applicationperformance.

5.3 Storage-side AccelerationAs we have seen, offloading can reduce the compute-node CPU load,but if the task is slowed by offloading, there may be little benefit –or even performance degradation. We next consider acceleratorsthat perform important storage tasks faster and at lower power andcost than the compute node CPU. For the next experiment, thereis a UDP accelerator ([25, 26] and see Section 2) in each storagenode. With the acceleration of the offloaded parse and filter tasks,the performance improvement compared to Baseline is significant,ranging from 1.7x to 3.9x, and with an average of nearly 2.5x (seeFigure 8). With accelerated parse and filter, the contributions ofStorage IO, Parse & Filter, and Query logic are comparable – nonedominates. This storage-side accelerated system is 200x faster thanthe naive offload to A53 results shown in Figure 6.

Empowering Architects and Designers: A Classification of What Functions to Accelerate in Storage

Figure 10: Balanced system: 1 CPU, # of SSDs in average ofall TPC-H queries and of best-scalable TPC-H query

5.4 In-Storage Device AccelerationWe next consider acceleration in each storage device (one UDP perSSD). This increases hardware expense for storage, and may bepossible for small accelerators such as UDP, but infeasible with lessefficient approaches such as FPGA’s [32, 43]. The obvious advan-tage of in-storage device acceleration is that acceleration capabilityscales with storage bandwidth.

As shown in Figure 9, the increase in acceleration bandwidthdelivers a further increase performance of nearly 50%. Specifically,performance increases by 1.9x to 6.3x with an average of 3.8x com-pared to Baseline. Clearly, more acceleration is desirable if it canbe afforded. The per-task breakdown shows that the parse andfilter bottleneck is eliminated with in-storage device acceleration,leaving the system largely limited by Storage IO and Query Logicon the CPU. We analyze these benefits from another perspective,evaluating net system scalability in Figure 10.

5.5 CPU-scalabilityThe storage accelerated system shifts computation to the storagenodes, increasing the number of SSDs that a CPU can drive. TheCPU scalability metric quantifies this change in system balance asshown in Figure 10. For the average performance over the TPC-Hbenchmarks, we can achieve CPU scalability increase for UDP-accelerated systems to nearly 64 SSDs, an increase of 14.9x overthe Baseline. The CPU-scalability increase for a best single TPC-Hquery is even higher, to 139 SSDs, an increase of 24.8x.

5.6 Normalized PerformanceAcceleration’s performance benefits have a cost – increased siliconarea and power. To consider these increased costs, we computenormalized performance from the geometric mean of runtimes forthe TPC-H benchmarks. First, we normalize for silicon area which isestimated from die shots [5, 6]. The results show that performanceefficiency does not improve for the A53 and Skylake acceleratedcases because no speedup is achieved (Figure 11). However, thestorage-side and in-device acceleration is highly efficient, and net3x and 4x improvements in normalized performance respectively.The power efficiency analysis yields similar results. So in this case,the acceleration benefits are much greater than the costs.

Figure 11: Normalized Speedup vs Silicon area and vs Power,with in-storage accelerated Parse & Filter

5.7 SummaryOur studies show that offloading for raw data analytics is tricky.Offloading does not always increase performance, but in a num-ber of cases, significant performance increases can be achieved incost-effective fashion. With these insights, we undertake a greaterchallenge, understanding in general when it is profitable to offloadcomputation to storage for system performance and scalability.

6 THE RESEARCH LANDSCAPE OF STORAGEACCELERATION

With inspiration from the many studies, including ours (Section5), and the expansive interest in storage acceleration, we considermore general questions –

(1) what computations give benefits when accelerated and of-floaded to storage? (application guidance)

(2) what general guidance is there on what acceleration to in-clude on storage nodes/devices? (cloud architect guidance)

Part of this situation is depicted in Figure 12 where an applicationdesigner considers whether to deploy elements of an applicationacross compute and storage nodes of the system. On the other hand,the question for the cloud data center architect (or storage systemdesigner) is what acceleration to add to storage and compute nodesfor maximum benefit and minimum cost.

In short, the criteria is “is storage acceleration the most efficientapproach for the system – hardware architecture and applications”,not simply “does storage acceleration increase performance”. Thereare numerous functions that increase performance if accelerated instorage, but not in a fashion most efficient for the system.

In this study, we consider these questions for a vertical slice,CPU - memory - network - storage node - SSDs, as shown in Figure12. We defer consideration of more complicated NxN and NxMscenarios and storage sharing for future studies.

6.1 The Spectrum of Functions for OffloadTo identify candidates for offload, we surveyed the research litera-ture for file systems, databases, and some miscellaneous applicationdomains [12, 19, 20, 28–32, 34, 38, 39, 41, 43, 45, 47–49]. In Table 1,functions (candidates for offload) are shown as columns and thenumerous systems that explore storage acceleration are shownas rows. The table illustrates the breadth and diversity of poten-tial storage acceleration, and collectively, they are the forefront ofsystems research for storage acceleration.

Chen Zou and Andrew A. Chien

File system Database Applications

Dedup

licate

Cryp

tography

Compress

Seria

lize

Archive

Replicate

Erasure

Coding

Filte

r

Select

Parse

Summarize

(Statistic

s)

Write-ahead

LogRe

play

Transpose

Statistic

alMod

eling

Neural

Networks

ActiveFlash [45] x x x x xAlmanac [48] xAurora [47] x xAzure [30] xBiscuit [28] xCaribou [32] x x xCIDR [19] x xDeepStore [41] xDiamond [31] xHWDedup [20] xIbex [49] x x xLepton [29] xInsider [43] x x x x xInSSDDedup [38] xSummarizer [39] x x xTintri [27] xYourSQL[34] x x xThis Raw Data Study x x xThis Classification Study x x x x x x x x x x x x x x

Table 1: Functions proposed from many application domains for storage-side acceleration.

Figure 12: Designer considering function offload to storage.

For filesystems, the focus has been on block-oriented opera-tions to transform data – for security, reliability, and density. Theblock-oriented focus arises naturally from the block-devices foundin storage systems and the studied operations can be 1-to-1 (i.e.cryptography or compress), many-to-1 (deduplication), 1-to-many(replicate, erasure code) with the corresponding data IO and net-work transmission requirements.

Databases operate on tables of tuples or columns of attributes. Assuch, the operations explored are all abstract database operationssuch as filter, select, summarize, and “parse” operations for unstruc-tured data items (often stored in strings). While these databasesoperate logically on individual tuples or values, they can be col-lected into large groups or block operations. The work per itemvaries from small to large for filter and summarize with variationarising from parsing, pattern matching, and operator complexity.Select on structured data is typically fixed low cost. A commonexploitation of database operators that provide data reduction is

predicate pushdown on the CPU. This query plan optimization canproduce benefits independent of acceleration and offload.

Application examples come directly from expensive computingor data reshuffling operations in “big data” applications. Easy towrite in conventional programs, operating in main memory, storageacceleration shifts these common computations such as transpose,neural networks, or statistical modeling to accelerator hardware inthe storage such that they could even operate autonomously.

Despite numerous studies, overall coverage of acceleration op-portunities is sparse – we are just at the beginning. Our goal is togeneralize from the many point studies – each reporting perfor-mance benefits for a specific acceleration approach. Such studiesoften fail to normalize for acceleration costs (high for FPGA’s andfull CPU’s), or consider compute-side acceleration as an alternative.We focus on separating the benefits of adding acceleration and thebenefits of its location. In short, our criteria is “does accelerationhelp?” and “is the most efficient place for the acceleration in thestorage system?” Numerous functions that increase performance ifaccelerated at storage give greater benefit if placed elsewhere.

6.2 Analyzing Acceleration and Data ReductionWe consider three groups of acceleration candidates drawn fromTable 1, based on their source – file systems, data analytics / data-base, and applications. For each group, we classify the functionsbased on two dimensions –

(1) Is the function acceleratable?(2) Does offloading reduce network data transmission cost?

Empowering Architects and Designers: A Classification of What Functions to Accelerate in Storage

These dimension capture first the traditional notion of beneficialcomputation hardware acceleration, where the accelerated imple-mentation provides latency, throughput, or energy benefits. Thesecond captures the notion that acceleration specifically on the stor-age improves system performance and scalability by increasing theexploitation of plentiful storage bandwidth. We consider not onlythe total data transmitted, but in some cases also the nodes amongstwhich it must be communicated – as that can affect network cost.

In Figure 13 we classify the functions from our survey based onour two criteria - acceleratable and network data reduction. Forfilesystem functions, cryptography, compress and deduplicate areall acceleratable. However, offloading them to storage does not re-duce data transfers between compute and storage. Cryptographygenerally does not reduce size at all. And compress and dedup ifdone at the CPU, produce reduced-size data to be transmitted tostorage. If compress and dedup are offloaded, full-sized data mustbe transmitted – offloading increases the data required to be trans-ferred. Erasure coding, serialize/archive, WAL replay, and replicateall involve multiple storage nodes, creating a more complicated situ-ation. In these cases, offloading can segregate required data transferwithin the storage nodes (cluster), effectively reducing data trafficbetween compute and storage; it can also be contained to a specialstorage network.

Further in Figure 13 we see that for database functions, offload-ing studies have focused on the operators that reduce data size– and hence network traffic. For filter the computation per tuplecan vary widely (from arithmetic comparisons to complex regularexpression matching). Summaries can range from max to complexcomputation operators, creating acceleration opportunities. Further,if the operators have low selectivity, these functions can reducedata transfer cost as well as follow-on computation.

Finally, we consider application kernels in Figure 13, includingcompute and shuffle intensive kernels such as statistical modeling(KNN classification or feature selection), neural network inference,and transpose. These applications all depend heavily on structureddata movement and computation, and are thus amenable to ac-celeration through parallel hardware such as vector and matrixmultiplications operations. If the kernels can be offloaded entirelyto storage and confined to a single node, data transfer costs can bereduced, by avoiding the transfer to the CPU completely.

6.3 Analyzing the Need for Software ChangeWhile most storage-side acceleration research focuses on speed-ing computation, such acceleration can create new software chal-lenges. First, application software generally requires access to thefull virtual memory of the application process (address space). Shift-ing an application computation to a storage-side accelerator cre-ates potential addressing and locality challenges. Second, offloadedapplication-defined functions can have variable resource require-ments (runtimes), creating a new resource management/schedulingproblem for system software on the storage system – a criticalshared resource. Error handling and failures further complicate thesituation. We highlight (red) functions that create such softwarechange challenges in Figure 14.

Examples of these challenges are varied. We discuss severalexamples from Figure 14, where they are marked in red. For ex-ample, offloading an application program for neural-net inferenceto storage requires mapping between application, accelerator, andperhaps storage address space. If the input array is a subset ofa multi-dimensional or sparse array, the mapping may be com-plicated, and other problems ensue with microcontrollers withsmaller addressing ranges. Traditional solutions (shared addressspace, virtual memory, or coherent memory) all increase hardwarecomplexity and create variability in performance. A second exam-ple is WAL replay offload as in Amazon’s Aurora database; whichshifts the log replay into to the storage layer. Storage-offloadingWAL replay requires running a collection of processes distributedacross storage nodes. The nodes must be quite capable - able toinitiate messages and IO operations in order to persist changesfrom the log in storage. These capable nodes must support vari-able computational requirements and high resource requirements[47]. A third offload type, functions such as compress or cryptog-raphy are fixed cost, local-data only operations with well-definedsemantics. Acceleration hardware for them can be designed andprovisioned specifically matched to performance needs, and withminimal software changes. Beyond examples such as WAL replay,all of the application-defined offload candidates will require spe-cial scheduling support from the system software. Because theapplication changes the data size, work, or even the function, theirrequirements are not known in advance, and can also be variable.This is a problem in shared storage resource applications. Othercomputations that present difficult scheduling issues include parse,statistical modelling, serialize/archive (red in Figure 14).

6.4 Example Offload CandidatesWe analyze exemplary offload candidates with respect to our threecriteria - acceleratable, network data reduction, and software change.

We start with parse, drawn from databases. Costs per tuple forparsing can be expensive, signaling significant acceleration oppor-tunities. And its branch-intensive properties fit well with acceler-ators like UDP [26]. Parsing also brings moderate data reductionbenefits during type conversion (e.g. 10 byte text int -> 4 byteint). However, parse costs can be highly-variable subject to thecomplexity/structure of the item being parsed creating schedulingchallenges for system software in the storage system. As a result,parsing is (acceleratable, data reducing, need software change). Itsperformance benefits encourage storage-offloading, the softwarechallenge must be addressed.

Next consider compress, an important file system function. Com-press generally operates on blocks, is amenable to acceleration,and easy software integration on blocks. Compress reduces thedata size, but in a system does not provide network data reductionbenefits when not offloaded (reduced-size data sent from computeto storage). Offloaded compress gives zero network data reductionbenefits. Thus, compress is an (acceleratable, no data reduction, nosoftware change) function.

Another distinctive example is write-ahead log replay. WAL re-play was originally designed to achieve crash consistency, replayingdatabase changes during recovery. Amazon Aurora [47] offloadsWAL replay to the storage layer as a replacement for dirty page

Chen Zou and Andrew A. Chien

Figure 13: Functions plotted - Acceleratable (y-axis) versus Network Data Reduction (x-axis)

Figure 14: Application rewrite and system resource manage-ment - software challenges for offload

flushing during normal operation of the DBMS. This refactoredsoftware architecture reduces the network data transmission fromthe database frontend cluster to the storage cluster, sending justmodified tuples instead of whole dirty pages. Further WAL replayupdate traffic is confined to the storage system. Because the logreplay operations have complex consistency and reliability require-ments, acceleration is difficult. So consider WAL replay as a (notacceleratable, data reducing, heavy software change) function.

6.5 A Proposed Classification FrameworkDistilling the discussions above, we produce a classification frame-work for application designers and system architects. Directly, theframework seeks to answer the question: what functions should beoffloaded to storage?.

The framework uses three attributes: acceleratable, data reduc-tion, need software change. Acceleratable reflects whether thefunction can be accelerated with specialized hardware. Data re-duction captures whether the function reduces network data traffic- by selective transmission, recoding, or perhaps changing receivers.Finally, need software change indicates whether software rewriteor new functionality is needed. Framework insights:

Hardware Architects. should design storage acceleration hard-ware to support all functions classified as (acceleratable, data re-duction, no software changes). These functions will provide bothcritical path reductions as well as scalability, enabling exploitationof the growing NAND Flash/SSD bandwidth. Furthermore, thesefunctions do not require software change, to they will find rapidadoption. Beyond these attributes, some (acceleratable, data reduc-ing, need software changes) functions are also worth considering,if software pioneers can be found.

The (acceleratable, no data reduction, *) functions are marginal.Offloading acceleration in storage may not give the best benefit.

For example, as in Section 7 offloading compress decreases systemperformance; compute-side acceleration is a better choice.

Application Designers. should consider (acceleratable, data re-duction, *) functions for storage-side offloading. Offloading thesefunctions will provide critical path reduction and improved scala-bility. Those that require no software change are easiest, but as anapplication designer addressing those that need software changemay also be accessible.

The (acceleratable, no data reduction, *) functions can be ex-ploited opportunistically if acceleration hardware is available. Herecompute-side accelerationmaywell be more beneficial than storage-side, and therefore preferable.

Beyond these initial insights for hardware designers and appli-cation designers, the framework also creates a clear roadmap, andordered progression of key challenges to solve to enables the nextbest candidates for storage offload. The next step is the solve thesoftware challenges for the functions in (acceleratable, networkreduction, need software change) and then (not acceleratable, net-work reduction, need software change).

7 EXPLORING THE CLASSIFICATIONWe present performance measurements for a variety of offloadingfunction examples. These results substantiate hardware architectand application designer recommendations and thereby demon-strate the power of our classification framework.

7.1 MetricsWe consider three metrics for performance: 1) Runtime (seconds,end-to-end application latency), 2) Network Traffic (gigabytes trans-ferred), and 3) CPU-scalability (the number of SSDs to reduce Stor-age IO time to 20% of total runtime).

Experiments assume two storage side execution unit configu-rations: either a 4-core x86 Skylake CPU as the storage-side general-purpose execution unit (denoted as ‘storage offload’), or an application-specific accelerator (denoted as ‘storage accel’). The Skylake CPU ismore powerful than realistic storage-side CPUs, as power and costlimits are significant. We will see acceleration is needed to makeoffloading effective.

7.2 Does ‘Acceleratable’ and ‘Data Reduction’justify Storage Offload

We evaluated exemplars of (acceleratable, data reduction, *) func-tions – filter, parse, and neural network to see if storage offload isthe best system configuration (highest efficiency).

Empowering Architects and Designers: A Classification of What Functions to Accelerate in Storage

Figure 15: Filter - acceleratable, data reduction, no softwarechange

Figure 16: Parse - acceleratable, data reduction, softwarechange

Figure 17: Neural network inference - acceleratable, datareduction, software change

(acceleratable, data reduction, no software change) - Filter.Figure 15 presents runtime (latency by elements), network trafficand SSD scalability for filtering on parsed TPC-H Q6 ‘lineitem’table of 10GB. The results show that offloading the filter to storage-side acceleration delivers improved performance. Storage offloadingeases the network bottleneck by sending only the needed data to theCPU, as shown by the network traffic. Performance is better thancompute only or compute accel situations. Adding acceleration onthe storage-side further reduces latency. SSD scalability is improvedby storage offload or acceleration.

With only minimal software change needed to deliver these ben-efits with storage offloading, system architects should design hard-ware to support (acceleratable, reduce data, no software change)functions. If possible, this entire group should be supported in fu-ture storage-side accelerators. Application designers should alsoconsider offloading these applicable functions.

Figure 18: select - not acceleratable, data reduction, soft-ware change

(acceleratable, data reduction, software change) - Parse.Figure 16 present runtime, network traffic, and SSD scalability forthe parsing the required columns from the text version of TPC-H‘lineitem’ table. In the base case, parsing performance is limitedby the network transfer. Storage offload garners network data re-duction benefits, addressing the network bottleneck, leaving thegeneral-purpose storage CPU as the performance limit. Accelera-tion is provided by the UDP (see Section 2.2), that is fast enoughto eliminate the storage-side computing bottleneck. The SSD scala-bility metric shows a similar story, with storage acceleration, bothnetwork and computing bottlenecks are addressed, delivering largeincrease in system capacity and scalability.

(acceleratable, data reduction, software change) - NeuralNetwork. We consider the cases where MobileNetV2 is used tofilter relevant images from an image collection as in [41]. Storageacceleration performance is modeled on the edge TPU [7]. Figure 17presents the runtime elements, network traffic and SSD scalabilityfor the inference process over 1,000 images totaling 10GB.

For offload to the storage CPU, the inference cost dominates,so little benefit is achieved. The TPU acceleration improves infer-ence performance, allowing the intelligent filtering benefit of datareduction to benefit system scalability.

Thus, the functions of (acceleratable, data reduction, softwarechange) should be the second candidates for hardware architect toconsider for the hardware support. Significant performance benefitsare achievable if software challenges can be solved.

7.3 Can ‘Data Reduction’ justify StorageOffload

We evaluate serialize/archive and select which are (not acceleratable,data reduction, *) to understand whether data reduction alone issufficient to justify storage offloading.

(not acceleratable, data reduction, no software change) -Select. In Figure18, we present the runtime elements, network traf-fic and SSD scalability for the column select on TPCH Q1 ‘lineitem’table of 10 GB. Because select does little computation, its perfor-mance is limited by network transfer. Storage offload provides datareduction benefits, addressing the network bottleneck and bothperformance and scalability improves.

(not acceleratable, data reduction, software change) - Seri-alize & Archive. We consider shifting serialize & archive entirelyto the storage nodes, confining the network traffic inside the stor-age cluster. Figure 19 presents runtime elments, network traffic, and

Chen Zou and Andrew A. Chien

Figure 19: Serialize & Archive - not acceleratable, data re-duction, software change

Figure 20: Compress - acceleratable, no data reduction, nosoftware change

SSD scalability for archiving a directory with 1024 files totalling10GB.

Because the storage CPU (offload engine) is not as powerfulas the compute node and the runtime latency for the offloadedwork increases. However, overall system latency decreases as net-work transfer time drops sharply, due to data reduction. The SSDscalability metric suggests the same: alleviating the network bottle-neck by confining the traffic to the storage cluster increases systemscalability.

This exemplar shows that functions that are not acceleratable butdeliver data reduction are good candidates for storage offloadingto general purpose units. Often they are not acceleratable becauseof their software complexity of lack of compute-intensivity. Forthese offloading to a weak general purpose engine can still be a netbenefit. Thus, application designers should consider these functionsfor storage offload, provided the accompanying software changecan be achieved.

7.4 Can ‘Acceleratable’ justify Storage OffloadWe evaluate the compress and cryptography which are (accelerat-able, no data reduction, *) in this section to see whether accelerationalone justifies storage offloading.

(acceleratable, no data reduction, no software change) -Compress. Figure 20 presents runtime elements, network trafficas well as SSD scalability for compressing 10GB data with snappycompression using 64KB blocks. The acceleration is delivered bythe Xilinx FPGA U200 with the Vitis compression library [17].

Without storage offloading, system performance is limited com-pute node speed. Offloading compress, increases network traffic(as in Section 6.2) since the uncompressed data is transferred to

Figure 21: Cryptography - acceleratable, no data reduction,no software change

Figure 22: Scalability and performance improvements withClassification

storage for compression. The resulting network bottleneck limitsperformance compared to the non-offloading CPU-only situation.

(acceleratable, no data reduction, software change) - Cryp-tography. In Figure 21, we present runtime elements, networktraffic as well as SSD scalability for encrypt 10GB data with AESencryption.

Although acceleration delivers slight performance increase, storage-offloading cannot provide network data reduction, so network datatransfer remains a bottleneck. So, even with storage acceleration,there is neither a significant reduction of runtime or nor increasein the SSD scalability.

Thus, the performance data affirms the recommendations bythe classification framework that acceleration alone can not makethe case for storage-offloading (acceleratable, no data reduction, *)functions.

7.5 SummaryWe summarize the system scalability and performance improve-ment with storage acceleration or offload (if the function is notacceleratable) comparing to the baseline of ‘compute only’. In Fig-ure 22, scalability is shown at the left, and speedup on the right. Thesummary shows the power of our classification framework. In bothgraphs, the functions that are both acceleratable and provide datareduction enjoy the greatest benefits. In contrast, the functions that

Empowering Architects and Designers: A Classification of What Functions to Accelerate in Storage

do not reduce data achieve barely any scalability or performanceimprovements. Thus, we confirm the recommendations from theclassification framework with the performance data:• (acceleratable, data reduction, *) applications are good forstorage-offload. Data reduction benefits address networkbandwidth limits and acceleration lifts processing perfor-mance. System architects and application designer shouldsupport functions that need minimal software changes, andsee the ones that need significant as second candidates• (not acceleratable, data reduction, *) functions are secondarycandidates for storage-offload. The data reduction benefitsalone can justify storage-offloading, and weaker general-purpose storage offloading will not degrade the overall per-formance as these functions are usually of low computationrequirements.• Acceleratable alone can not justify storage offloading. (ac-celeratable, no data reduction, *) are not good candidates,because storage offloading may not be the most efficientoffloading, and it may even hurt the performance.

In summary, our classification framework establishes a clearroadmap and order from the chaotic research space of storageoffloading. This roadmap organizes the diverse function space, pro-viding clear priorities and guidance for the hardware architect andapplications to make offloading decisions.

Further, a roadmap could be derived from the framework toattack the general storage offloading problem. Storage system ar-chitects should first focus on the applications that are both ac-celeratable and produce data reductions, as accelerators targetingfunctions offloaded to storage could be designed to improve boththe functionality and performance of the storage systems. For ap-plication and software architects, it’s also clear that there are issuesincluding resource management, service-level agreement as wellas addressability because of storage resource sharing, variable stor-age offload performance, and disaggregate execution environmentsrespectively that need be solved before widespread adoption isfeasible.

8 DISCUSSION AND RELATEDWORKPioneering work includes “Active Storage” in the 1990s that focusedon rotating hard disks in a single system, not the modern contextof cloud shared storage services with high-performance flash SSDs[18, 42]. More recent efforts study acceleration systems and assesstheir performance benefit [28, 31, 32, 34, 39, 40, 43, 45, 46, 49]. Suchstudies showcase the benefit of a specific acceleration implementa-tion for a set of applications, but give little insight as what makescomputation suitable for acceleration, and the benefits likely toaccrue – the focus of our classification.

Storage-side Offloading for SpecificWorkloadsMany stud-ies focus on storage-side acceleration for specific workloads. Theseinclude exploiting early filtering in OLAP databases [23, 34, 39, 49],offloading compression or deduplication for file/storage systems[19, 20, 32, 38, 48] and offloading new applications such as graphanalysis [36] and deep neural networks [41]. Specific benefits in-clude reduced CPU and network loads. Our case study reaffirmsthese results for OLAP databases, but our classification goes further,assessing a much broader range of computations for offload.

Storage-side Offloading Frameworks Several have proposedframeworks for storage-side offload [28, 35, 43, 44], supporting pro-grammability to enable the development of new offload functionimplementations. If such use emerges, it could guide hardware cus-tomization. This promising work is orthogonal to our work. Asshort of implementation, it provides no input on how to systemati-cally decide what functions are worthwhile to offload.

Higher-level Storage Interfaces A number of research andcommercial efforts have constructed higher-level storage interfaces.Notable amongst these is the idea of a native key-value, storage-side accelerated system. Key-value covers an important subset ofstorage use [22, 32, 33, 37]. Significant benefits can accrue, particu-larly when synergies with media management (e.g. flash translationlayer) can be exploited [37], and by implementing key-value func-tions in specialized hardware [32]. Our work addresses a broaderscope – the classification can be applied to functions that existabove or below a key-value interface, and to completely differentstorage stacks.

Cloud Application Refactoring Cloud applications and ser-vices such as S3 Select, Glacier Select, and Amazon Aurora [12, 47]refactor the data stack, shifting function to the storage layer. Aurorapushes reliability and synchronization work for high-availabilityOLTP databases into the storage layer, performing log replay onstorage nodes. These refactorings deliver significant performanceimprovements, showing the promise of storage acceleration. How-ever, software and hardware design of these systems are not avail-able so a direct comparison is not possible.

9 SUMMARY AND FUTUREWORKWe performed a storage acceleration case study using a complexraw data analytics system, showing that large performance andscalability benefits accrue. The greatest benefits come from offload-ing regex and filtering operations that reduce the quantity of data –both for network transfer and for subsequent query logic processingby the CPU.

Building on these learnings, we studied a broad range of researchproposals for function for storage acceleration, producing a simpleclassification that enables rapid, easy assessment of a computa-tion function. This classification organizes the function space andprovide offloading recommendations to storage architects and ap-plication designers. It also derives a roadmap to attack the generalstorage offloading problem for large adoptions.

Interesting extensions include case studies of existing applica-tion systems, using the classification system to analyze their per-formance – and find new opportunities for benefit. Another wouldbe to define general requirements for hardware offload enginesbased on the classification with the goal of achieving the generalityof FPGA’s without the associated complexity and implementationinefficiency.

10 ACKNOWLEDGEMENTSThis work is supported by National Science Foundation GrantsCNS-1405959, CMMI-1832230, and CNS-1901466. We gratefullyacknowledge support from Intel, Google, and Samsung.

Chen Zou and Andrew A. Chien

REFERENCES[1] [n.d.]. Alibaba Cloud’s Global Infrastructure. https://www.alibabacloud.com/

global-locations.[2] [n.d.]. AWS Nitro system. https://aws.amazon.com/ec2/nitro/.[3] [n.d.]. CERN global grid. https://gstat-wlcg.cern.ch/apps/topology/.[4] [n.d.]. Common Crawl Dataset. https://commoncrawl.org/.[5] [n.d.]. Die shot of Skylake SP microarchitecture. https://en.wikichip.org/w/

images/8/84/skylake_sp_core.png.[6] [n.d.]. Die shot of XGene-1 Storm microarchitecture. https://bit.ly/2TP6dSX.[7] [n.d.]. Edge TPU performance benchmarks. https://coral.ai/docs/edgetpu/

benchmarks.[8] [n.d.]. Google Data Center Locations. https://www.google.com/about/

datacenters/inside/locations/index.html.[9] [n.d.]. Imagenet Dataset. http://www.image-net.org/.[10] [n.d.]. Intel 760P Series. Intel SSD product website.[11] [n.d.]. Introducing Apache Spark Data Sources API V2. https://databricks.com/

session/apache-spark-data-source-v2.[12] [n.d.]. S3 Select. https://aws.amazon.com/blogs/aws/s3-glacier-select/.[13] [n.d.]. Samsung PM1725b PCIe Gen3 x4. https://www.samsung.com/

semiconductor/ssd/enterprise-ssd/MZWLL1T6HAJQ/.[14] [n.d.]. Samsung Sixth-Generation V-NAND SSDs for Client Computing. Samsung

News Room.[15] [n.d.]. Spark SQL. https://spark.apache.org/sql/.[16] [n.d.]. TPC-H dataset. http://www.tpc.org/tpch/.[17] [n.d.]. Vitis Data Compression Library. https://www.xilinx.com/products/design-

tools/vitis/vitis-libraries/vitis-data-compression.html.[18] Anurag Acharya, Mustafa Uysal, and Joel Saltz. 1998. Active Disks: Programming

Model, Algorithms and Evaluation. In Proceedings of the Eighth InternationalConference on Architectural Support for Programming Languages and OperatingSystems (ASPLOS VIII). ACM, 81–91.

[19] Mohammadamin Ajdari, Pyeongsu Park, Joonsung Kim, Dongup Kwon, andJangwoo Kim. 2019. CIDR: A Cost-Effective In-Line Data Reduction System forTerabit-Per-Second Scale SSD Arrays. In 2019 IEEE International Symposium onHigh Performance Computer Architecture (HPCA). IEEE, 28–41.

[20] Mohammadamin Ajdari, Pyeongsu Park, Dongup Kwon, Joonsung Kim, andJangwoo Kim. 2017. A scalable hw-based inline deduplication for ssd arrays.IEEE Computer Architecture Letters 17, 1 (2017), 47–50.

[21] Surajit Chaudhuri and Umeshwar Dayal. 1997. AnOverview of DataWarehousingand OLAP Technology. SIGMOD Rec. 26, 1 (March 1997), 65–74. http://doi.acm.org/10.1145/248603.248616

[22] Chanwoo Chung, Jinhyung Koo, Junsu Im, Sungjin Lee, et al. 2019. Light-Store: Software-defined Network-attached Key-value Drives. In Proceedings of theTwenty-Fourth International Conference on Architectural Support for ProgrammingLanguages and Operating Systems. ACM, 939–953.

[23] Jaeyoung Do, Yang-Suk Kee, Jignesh M Patel, Chanik Park, Kwanghyun Park,and David J DeWitt. 2013. Query processing on smart SSDs: opportunities andchallenges. In Proceedings of the 2013 ACM SIGMOD International Conference onManagement of Data. ACM, 1221–1230.

[24] Jaeyoung Do, Sudipta Sengupta, and Steven Swanson. 2019. Programmablesolid-state storage in future cloud datacenters. Commun. ACM 62, 6 (2019),54–62.

[25] Yuanwei Fang, Chen Zou, and Andrew A Chien. 2019. Accelerating raw dataanalysis with the ACCORDA software and hardware architecture. Proceedings ofthe VLDB Endowment 12 (2019).

[26] Yuanwei Fang, Chen Zou, Aaron J Elmore, and Andrew A Chien. 2017. UDP:a programmable accelerator for extract-transform-load workloads and more.In 2017 50th Annual IEEE/ACM International Symposium on Microarchitecture(MICRO). IEEE.

[27] Gideon Glass, Arjun Gopalan, Dattatraya Koujalagi, Abhinand Palicherla, andSumedh Sakdeo. 2018. Logical synchronous replication in the Tintri VMstorefile system. In 16th USENIX Conference on File and Storage Technologies (FAST 18).295–308.

[28] Boncheol Gu, Andre S Yoon, Duck-Ho Bae, Insoon Jo, Jinyoung Lee, JonghyunYoon, Jeong-Uk Kang, Moonsang Kwon, Chanho Yoon, Sangyeun Cho, et al. 2016.Biscuit: A framework for near-data processing of big data workloads. In ACMSIGARCH Computer Architecture News, Vol. 44. IEEE Press, 153–165.

[29] Daniel Reiter Horn, Ken Elkabany, Chris Lesniewski-Lass, and Keith Winstein.2017. The design, implementation, and deployment of a system to transparentlycompress hundreds of petabytes of image files for a file-storage service. In 14thUSENIX Symposium on Networked Systems Design and Implementation (NSDI 17).1–15.

[30] Cheng Huang, Huseyin Simitci, Yikang Xu, Aaron Ogus, Brad Calder, ParikshitGopalan, Jin Li, and Sergey Yekhanin. 2012. Erasure coding in windows azurestorage. In Presented as part of the 2012 USENIX Annual Technical Conference(USENIX ATC 12). 15–26.

[31] Larry Huston, Rahul Sukthankar, Rajiv Wickremesinghe, Mahadev Satya-narayanan, Gregory R Ganger, Erik Riedel, and Anastassia Ailamaki. 2004. Dia-mond: A Storage Architecture for Early Discard in Interactive Search.. In FAST,Vol. 4. 73–86.

[32] Zsolt István, David Sidler, and Gustavo Alonso. 2017. Caribou: intelligent dis-tributed storage. Proceedings of the VLDB Endowment 10, 11 (2017), 1202–1213.

[33] Yanqin Jin, Hung-Wei Tseng, Yannis Papakonstantinou, and Steven Swanson.2017. KAML: A flexible, high-performance key-value SSD. In 2017 IEEE Inter-national Symposium on High Performance Computer Architecture (HPCA). IEEE,373–384.

[34] Insoon Jo, Duck-Ho Bae, Andre S Yoon, Jeong-Uk Kang, Sangyeun Cho, Daniel DGLee, and Jaeheon Jeong. 2016. YourSQL: a high-performance database systemleveraging in-storage computing. Proceedings of the VLDB Endowment 9, 12(2016), 924–935.

[35] Sang-Woo Jun, Ming Liu, Sungjin Lee, Jamey Hicks, John Ankcorn, Myron King,Shuotao Xu, et al. 2015. Bluedbm: An appliance for big data analytics. In 2015ACM/IEEE 42nd Annual International Symposium on Computer Architecture (ISCA).IEEE, 1–13.

[36] Sang-Woo Jun, Andy Wright, Sizhuo Zhang, Shuotao Xu, et al. 2018. GraFBoost:Using accelerated flash storage for external graph analytics. In 2018 ACM/IEEE45th Annual International Symposium on Computer Architecture (ISCA). IEEE,411–424.

[37] Yangwook Kang, Rekha Pitchumani, Pratik Mishra, Yang-suk Kee, FranciscoLondono, Sangyoon Oh, Jongyeol Lee, and Daniel DG Lee. 2019. Towards buildinga high-performance, scale-in key-value storage system. In Proceedings of the 12thACM International Conference on Systems and Storage. ACM, 144–154.

[38] Jonghwa Kim, Choonghyun Lee, Sangyup Lee, Ikjoon Son, Jongmoo Choi, Sun-groh Yoon, Hu-ung Lee, Sooyong Kang, Youjip Won, and Jaehyuk Cha. 2012.Deduplication in SSDs: Model and quantitative analysis. In 012 IEEE 28th Sympo-sium on Mass Storage Systems and Technologies (MSST). IEEE, 1–12.

[39] Gunjae Koo, Kiran Kumar Matam, HV Narra, Jing Li, Hung-Wei Tseng, StevenSwanson, Murali Annavaram, et al. 2017. Summarizer: trading communica-tion with computing near storage. In Proceedings of the 50th Annual IEEE/ACMInternational Symposium on Microarchitecture. ACM, 219–231.

[40] Anthony Kougkas, Hariharan Devarajan, Jay Lofstead, and Xian-He Sun. 2019.Labios: A distributed label-based i/o system. In Proceedings of the 28th Inter-national Symposium on High-Performance Parallel and Distributed Computing.13–24.

[41] Vikram Sharma Mailthody, Zaid Qureshi, Weixin Liang, Ziyan Feng, SimonGarcia de Gonzalo, Youjie Li, Hubertus Franke, Jinjun Xiong, Jian Huang, andWen-mwei Hwu. 2019. DeepStore: In-Storage Acceleration for Intelligent Queries.In Proceedings of the 52th International Symposium on Microarchitecture. ACM.

[42] Erik Riedel, Garth Gibson, and Christos Faloutsos. 1998. Active storage for large-scale data mining and multimedia applications. In Proceedings of 24th Conferenceon Very Large Databases. ACM, 62–73.

[43] Zhenyuan Ruan, Tong He, and Jason Cong. 2019. INSIDER: Designing In-StorageComputing System for Emerging High-Performance Drive. In 2019 USENIX An-nual Technical Conference (USENIX ATC 19). 379–394.

[44] Sudharsan Seshadri, Mark Gahagan, Sundaram Bhaskaran, Trevor Bunker,Arup De, Yanqin Jin, Yang Liu, and Steven Swanson. 2014. Willow: A User-Programmable SSD. In 11th USENIX Symposium on Operating Systems Design andImplementation (OSDI 14). 67–80.

[45] Devesh Tiwari, Simona Boboila, Sudharshan Vazhkudai, Youngjae Kim, XiaosongMa, Peter Desnoyers, and Yan Solihin. 2013. Active flash: Towards energy-efficient, in-situ data analytics on extreme-scale machines. In Presented as part ofthe 11th USENIX Conference on File and Storage Technologies (FAST 13). 119–132.

[46] Devesh Tiwari, Sudharshan S. Vazhkudai, Youngjae Kim, Xiaosong Ma, Si-mona Boboila, and Peter J. Desnoyers. 2012. Reducing Data Movement CostsUsing Energy-Efficient, Active Computation on SSD. In Presented as part ofthe 2012 Workshop on Power-Aware Computing and Systems. USENIX, Holly-wood, CA. https://www.usenix.org/conference/hotpower12/workshop-program/presentation/Tiwari

[47] Alexandre Verbitski, Anurag Gupta, Debanjan Saha, Murali Brahmadesam,Kamal Gupta, Raman Mittal, Sailesh Krishnamurthy, Sandor Maurice, TengizKharatishvili, and Xiaofeng Bao. 2017. Amazon aurora: Design considerationsfor high throughput cloud-native relational databases. In Proceedings of the 2017ACM International Conference on Management of Data. ACM, 1041–1052.

[48] Xiaohao Wang, Yifan Yuan, You Zhou, Chance C Coats, and Jian Huang. 2019.Project Almanac: A Time-Traveling Solid-State Drive. In Proceedings of the Four-teenth EuroSys Conference 2019. ACM, 13.

[49] Louis Woods, Zsolt István, and Gustavo Alonso. 2014. Ibex: an intelligent storageengine with support for advanced SQL offloading. Proceedings of the VLDBEndowment 7, 11 (2014), 963–974.