Storage-Centric System Designs for Enabling Fast, Efficient, and Low-Cost Genomic and Metagenomic Analyses

DOCTOR OF SCIENCES

• The dissertation was accepted on the recommendation of Prof. Dr. Onur Mutlu as examiner and five co-examiners.The co-examiners are Prof. Dr. Can Alkan, Reetuparna Das, Wen-mei Hwu, Jangwoo Kim, and Yatish Turakhia.Source: DOCTOR OF SCIENCES · p. 1
• Nika Mansourighiasi’s work is titled “Storage-Centric System Designs for Enabling Fast, Efficient, and Low-Cost Genomic and Metagenomic Analyses,” and the cited passage gives its copyright year as 2026.Source: DOCTOR OF SCIENCES · p. 2
• The dissertation is dedicated to resilient students and researchers who advance science while navigating challenges such as illness, poverty, bureaucracy, and conflict.The dedication describes these as challenges beyond their scientific endeavors.Source: DOCTOR OF SCIENCES · p. 3

• The dissertation targets two persistent bottlenecks: moving low-reuse sequence data from storage and decompressing and formatting compressed data before analysis.Its approaches aim to reduce data-transfer overhead and computational load while maintaining high performance, energy efficiency, and compression ratios, and to integrate easily into diverse analysis systems.Source: Zusammenfassung · p. 9
• GenStore uses low-cost in-storage accelerators to filter genomic data; MegIS cooperatively processes metagenomic data inside and outside storage to reduce transfers across the analysis pipeline.GenStore targets data that does not require computationally intensive further analysis.Source: Zusammenfassung · p. 10
• GRAINS analyzes very large genomic and metagenomic sequence graphs in storage, using storage-aware co-design to optimize pipelines and improve performance, energy efficiency, and cost-efficiency.It combines in-storage and in-flash processing.Source: Zusammenfassung · p. 10
• SAGe co-designs algorithms and hardware to provide highly compressed sequence storage with low decompression latency, lightweight hardware, and efficient streaming access.It exploits characteristic patterns in genomic data to achieve compression ratios comparable to state-of-the-art genomic compression methods.Source: Zusammenfassung · p. 10
• The proposed systems reduce data-transfer overhead, computational load, and data-preparation bottlenecks while substantially improving performance, energy efficiency, and cost-efficiency.They combine analysis directly in storage with highly compressed storage and high-performance access to sequence data.Source: Zusammenfassung · p. 10

8.1 Motivation for Combining the Proposed Designs into a Unified System

• The section motivates combining the proposed designs into a unified system.Source: §8 · p. 15

8.1.1 Storage-Centric Computing on Compressed Data

• The section addresses storage-centric computing on compressed data.Source: §8 · p. 15

8.1.2 Facilitating Wider Adoption

• The section addresses facilitating wider adoption.Source: §8 · p. 15

8.2 Design of the Unified System

• The section describes the design of the unified system.Source: §8 · p. 15

8.2.1 Hardware Units

• The section covers the unified system’s hardware units.Source: §8 · p. 15

8.2.2 FTL

• The section covers the unified system’s FTL.Source: §8 · p. 15

8.2.3 Interface Commands

• The section covers the unified system’s interface commands.Source: §8 · p. 15

8.3 Cost-Benefit Analysis of the Unified System

• The section presents a cost-benefit analysis of the unified system.Source: §8 · p. 15

Introduction

• Genomic analysis supports fields including medicine, disease-outbreak tracing, food safety, agriculture, scientific discovery, biodiversity conservation, and antimicrobial-resistance surveillance.Metagenomic analysis studies the sequences of different species sharing an environment and has applications in precision medicine, urgent clinical settings, and early disease warnings.Source: Introduction · p. 22
• The introduction links increasing adoption of genomic and metagenomic analyses and advances in sequencing to exponential growth in sequence-data generation.It notes that the public Sequence Read Archive illustrates this growth, while private repositories also hold large volumes whose sizes are not publicly available.Source: Introduction · p. 23
• Sequencing and basecalling are usually one-time tasks, but read sets may be reanalyzed across studies, parameter choices, databases, and updated or personalized references.Repeated analysis supports tuning sensitivity-specificity tradeoffs and pursuing different accuracy goals.Source: Introduction · p. 24
• 38 days on a high-end server node are required to analyze data that a sequencer can sequence and basecall in 48 hours, using a state-of-the-art metagenomic tool.The example highlights the challenge for time-critical use cases that require fast decisions.Source: Introduction · p. 24
• Analysis throughput must match or exceed sequencing throughput for analysis during sequencing; otherwise, analysis bottlenecks time-critical use.Matching throughput enables dynamic stopping when a target pathogen is identified or sufficient coverage is reached.Source: Introduction · p. 24
• 675 KJ, or 63% of workflow energy, is required to process the dataset on a commodity server, making analysis the primary energy bottleneck.The passage states that improving analysis energy efficiency is increasingly necessary as sequencing technologies evolve.Source: Introduction · p. 24

1.1. PROBLEM DISCUSSION

• 44× higher throughput at only 1.5× higher power consumption makes newer sequencing more energy-efficient, while scaling commodity systems worsens analysis energy demands.The comparison is between a 2023 Illumina sequencer and an older 2020 version; compact portable sequencers also heighten the need for energy- and cost-effective analysis.Source: §1.1 · p. 25
• Prior work accelerates genomic and metagenomic analysis and compresses sequence data because storing uncompressed data is impractical at massive scale.Approaches include algorithmic optimization, hardware accelerators, and read filters for analysis, alongside sequence-specialized compression techniques.Source: §1.1 · p. 25

1.1 Problem Discussion

• The major outstanding problem is accessing stored sequence data and feeding it to analysis units.The paper notes significant prior efforts to improve analysis and storage, but identifies access and delivery as unresolved challenges.Source: §1.1 · p. 25

Overhead of Moving Large Amounts of Low-Reuse Data from the Storage System

• Low-reuse data movement significantly hinders end-to-end performance and energy efficiency in genomic, metagenomic, and graph-based (meta)genomic analysis.The metagenomic impact is tied to moving data that is unlikely to be reused, while evaluation on large-scale genome graphs likewise finds significant performance and energy costs.Source: Overhead of Moving Large Amounts of… · pp. 26–27
• Storage I/O and unnecessary computational burden bottleneck genomic-analysis performance and energy in conventional and hardware-accelerated systems, especially when other bottlenecks are reduced.The stated impact applies to both software-based and emerging hardware-accelerated systems.Source: Overhead of Moving Large Amounts of… · p. 26
• Data preparation—decompressing and formatting sequence data before analysis—can critically limit the performance benefits of hardware-accelerated genome analysis.The dissertation reports examining this bottleneck across various real-world scenarios.Source: Overhead of Moving Large Amounts of… · p. 27

1.2 Goal

• The goal is to alleviate storage data-movement overhead, reduce computational burden on the rest of the system, and mitigate data preparation while achieving high performance, energy efficiency, and compression ratios.The proposed designs are intended to be lightweight and integrate with a broad range of genomic and metagenomic analysis systems.Source: §1.2 · p. 28

1.3 Thesis Statement

• The thesis proposes storage-centric systems for in-storage genomic and metagenomic analysis and highly compressed, high-performance sequence access to alleviate bottlenecks and improve performance, energy efficiency, and cost.The thesis states that improvements can reach one to two orders of magnitude.Source: §1.3 · p. 28

1.4 Our Approach

• The approach proposes storage-centric computing for genomic, metagenomic, and graph-based analyses, plus algorithm-architecture co-design for compressed storage and high-performance sequence access.Storage-centric computing processes data inside the storage device, either on the SSD controller or on flash dies.Source: §1.4 · p. 28

1.4.1 In-Storage Filters for Genomic Analysis

• Existing genomic filters reduce expensive computation, but still require moving large amounts of data from storage, lowering end-to-end read-mapping performance.Read mapping involves approximate string matching on large amounts of data.Source: §1.4.1 · p. 29
• GenStore is an in-storage genomic analysis system that uses low-cost, accurate filters to reduce storage data movement and computational overhead.Its hardware/software co-design accounts for differences in read properties and genetic variation.Source: §1.4.1 · p. 29
• GenStore improves read-mapping performance over three state-of-the-art software (hardware) baselines [294] by 2.07–6.05× (1.52–3.32×) for high-similarity reads and 1.45–33.63× (2.70–19.2×) for low-similarity reads.It reduces energy consumption by an average (up to) 3.92× (3.97×) for high-similarity reads and 27.17× (29.25×) for low-similarity reads.Source: §1.4.1 · p. 29

1.4.2 Cooperative In-Storage Processing for Metagenomic Analysis

• MegIS uses cooperative in-storage processing, partitioning pipeline work between the host and SSD and coordinating data transfer with computation.Its design also uses storage-aware algorithms, lightweight accelerators, and an FTL and data mapping scheme to leverage SSD bandwidth while limiting internal buffer requirements.Source: §1.4.2 · p. 30
• MegIS outperforms performance- and accuracy-optimized software tools by 2.7×–37.2× and 6.9×–100.2×, respectively, while matching the accuracy-optimized tool.It also achieves 1.5×–5.1× speedup over the hardware-accelerated processing-in-memory tool, with significantly higher accuracy.Source: §1.4.2 · p. 31
• MegIS reduces average energy consumption by 5.4× and 1.9× versus performance-optimized software and hardware baselines, respectively, and by 15.2× versus the accuracy-optimized baseline.Source: §1.4.2 · p. 31

1.4.3 Storage-Aware Algorithm-Architecture Co-Design for Graph-Based Genomic and Metagenomic Analyses

• GRAINS is designed for large-scale genomic and metagenomic sequence graphs, whose low-reuse data accesses create storage data-movement overhead.Existing tools and prior storage-centric systems are unsuitable for these graph data structures and access patterns or modern SSD resource limits.Source: §1.4.3 · p. 31
• GRAINS co-designs sequence-graph analysis for storage through batching that reduces random accesses, in-flash and in-storage processing that avoids transferring low-reuse or unused pages, and lightweight scheduling across flash dies.It supports major sequence-graph operations and integration into analysis pipelines.Source: §1.4.3 · p. 32
• GRAINS achieves 1.5×–17.0× speedup over a hardware-accelerated processing-in-memory baseline and average energy efficiency gains of 16.4× and 9.8× over software and hardware baselines, respectively.Source: §1.4.3 · p. 32

1.4.4 Algorithm-Architecture Co-Design for Highly-Compressed Storage and High-Performance Access of Sequence Data

• SAGe co-designs lossless compression, lightweight decompression hardware, storage layout, and access commands to support high compression ratios, low decompression latency, and streaming access.It supports datasets from different sequencing technologies and species and can integrate with a broad range of genome-analysis accelerators.Source: §1.4.4 · p. 33
• SAGe improves average end-to-end performance and energy efficiency of two state-of-the-art genome analysis accelerators by 3.0×–32.1× and 13.0×–34.0×, respectively.These results are compared with the accelerators relying on state-of-the-art software and hardware decompression tools.Source: §1.4.4 · p. 33

1.4.5 Putting It All Together

• The proposed unified system combines GenStore, MegIS, GRAINS, and SAGe to mitigate data movement and preparation bottlenecks without requiring uncompressed sequence storage.It is intended to support a wide range of genomic and metagenomic analysis tasks at low cost; shared hardware components make its area smaller than the sum of the individual designs.Source: §1.4.5 · p. 33

1.5. CONTRIBUTIONS

• The dissertation identifies two barriers to end-to-end analysis: moving low-reuse data from storage to memory and compute units, and decompressing and formatting compressed sequence data before analysis.It argues that storage-centric designs can analyze data where it resides to alleviate movement overheads, while also mitigating data-preparation bottlenecks despite storage hardware limitations.Source: §1.5 · p. 34

1.5 Contributions

• GenStore is an in-storage processing system for genomic analysis that uses low-cost accelerators to filter reads not requiring expensive ASM computation during read mapping.Its storage-aware co-design replaces expensive random accesses with sequential accesses and places data to use internal SSD bandwidth.Source: §1.5 · pp. 34–35
• MegIS uses cooperative in-storage processing, combining storage-side and host-side processing through hardware/software co-design for metagenomic analysis.This design addresses in-storage processing challenges by exploiting the strengths of both locations.Source: §1.5 · p. 35
• MegIS achieves average energy reductions of 5.4× versus software and 1.9× versus hardware performance-optimized baselines, and 15.2× versus an accuracy-optimized baseline.It outperforms two state-of-the-art tools, including a hardware-accelerated tool, with higher accuracy while matching the accuracy-optimized tool.Source: §1.5 · p. 35
• GRAINS is introduced as a system for analysis with large-scale genomic data.Source: §1.5 · p. 36
• Storage-aware algorithm–architecture co-design makes graph-based genomic and metagenomic analysis pipelines more storage-friendly and improves performance, energy efficiency, and cost-effectiveness through in-storage and in-flash processing.The co-design addresses storage-centric computing challenges by adapting analysis pipelines and processing to the storage system.Source: §1.5 · p. 36
• SAGe combines high compression ratios comparable to state-of-the-art genomic compressors with low decompression latency, lightweight hardware, and efficient streaming access.Its design targets the data-preparation bottleneck while maintaining compression and a lightweight implementation.Source: §1.5 · p. 36
• The proposed systems provide performance and energy benefits without costly system-wide resources, including external I/O bandwidth, large DRAM capacity, or extensive computational units.The dissertation presents these benefits as supporting wider adoption of genomics and metagenomics.Source: §1.5 · p. 36

1.6. DISSERTATION OUTLINE

• The dissertation presents GenStore, MegIS, GRAINS, and SAGe, then describes a combined storage-centric design and its evaluation in Chapter 8.Chapter 9 discusses future research directions and concluding remarks.Source: §1.6 · p. 37

Background

• The chapter surveys SSD storage, genomic and metagenomic workflows, and the genomic, metagenomic, graph-based, and genomics-specific topics covered in later sections.Its stated scope includes an overview of sequencing, basecalling, and analysis, followed by more detailed treatments of genomic and metagenomic analysis.Source: Background · p. 38

2.1 Solid State Drive Organization

• NAND flash SSDs connect packages of independently operating dies to the controller through shared channels, which allow only one die at a time to communicate with it.Each die contains multiple planes that share access circuitry and can operate concurrently only for accesses at the same offset.Source: §2.1 · pp. 38–39
• The SSD controller combines firmware-running cores and per-channel flash controllers; its flash translation layer handles host communication, I/O scheduling, and SSD management.SSD-internal DRAM primarily stores logical-to-physical mappings used for address translation.Source: §2.1 · p. 39

2.2. GENOMIC AND METAGENOMIC WORKFLOWS

• Modern SSD internal bandwidth generally exceeds external host-to-SSD bandwidth, while multiple channels help reduce request contention and support internal management tasks.The text gives enterprise-controller examples with 19.2 GB/s internal versus 6,550MB/s external bandwidth, and 2025 controller bandwidth up to 57.6 GB/s internal versus 14 GB/s external.Source: §2.2 · p. 40

2.2 Genomic and Metagenomic Workflows

• Genomics analyzes sequences from an individual or small group of one known species, whereas metagenomics analyzes organisms from multiple species in a shared environment.Both workflows include sequencing, basecalling, and analysis.Source: §2.2 · p. 40

2.2.1 Sequencing

• Sequencing produces overlapping reads rather than complete error-free genomes; greater sequencing depth provides more information at each genomic position.In sequencing-by-synthesis, fluorescently labeled nucleotides are incorporated one at a time and imaged each cycle to produce raw sequencing data.Source: §2.2.1 · pp. 41–42
• SBS provides high accuracy but produces short reads; SMRT avoids cycle-by-cycle sequencing for longer reads, while nanopore sequencing can yield ultra-long reads but has noisy signals.SMRT noise requires additional error correction, including alignment, consensus construction, and polishing.Source: §2.2.1 · pp. 42–43

2.2.2 Basecalling

• Basecalling converts sequencing signals into nucleotide strings; noisy nanopore signals make this harder than SBS and SMRT, so modern basecallers use neural networks and flexible decoders for variable-length signals.Models may combine CNNs and RNNs, while CTC or CRF decoders handle signal segments of varying length.Source: §2.2.2 · p. 43

2.3. GENOMIC ANALYSIS

• Each read is represented by a nucleotide string, a per-base quality score, and a header; reads are commonly stored as FASTQ and compressed for future analysis.Source: §2.3 · p. 44

2.2.3 Analysis

• Compressed reads must be decompressed and formatted before analysis; genomic workflows quantify mismatches between reads and a reference genome, whereas metagenomics compares target sequences against large databases of many reference genomes.Source: §2.2.3 · p. 44

2.3 Genomic Analysis

• The genomic-analysis section frames its focus as core analysis components and the need for high-performance, energy-efficient processing.Source: §2.3 · p. 44

2.3.1 Read Mapping Process

• Read mapping is computationally expensive; mappers use reference-genome k-mer indexes to narrow candidate locations, and some index only minimizers to reduce storage and query overhead.Source: §2.3.1 · pp. 44–45
• Read mapping seeds candidate genome locations, filters or chains seeds, then uses computationally expensive dynamic-programming alignment to return the best-scoring locations.Reads without sufficiently strong chains skip alignment.Source: §2.3.1 · pp. 45–46

2.3.2 Pre-Alignment Read Filtering

• Pre-alignment filters remove locations likely to require too many edits, while another filter detects exact or near-exact matches to avoid costly alignment.The exact/near-exact filter is particularly effective when many reads match exactly, as in human short-read sets with 80% such reads [419,714,715]; both filter types still require many random memory accesses.Source: §2.3.2 · p. 46

2.3.3 Further Steps in Analysis

• Downstream analyses use read-mapping results and typically need all read bases but quality scores only around mismatches.Those local quality scores help distinguish biological variation from sequencing errors.Source: §2.3.3 · p. 47

2.3.4 Importance of High-Performance and Energy-Efficient Genomic Analysis

• Analysis performance matters because read sets may be reanalyzed, slow analysis challenges clinical and disease-surveillance use, and conventional scaling is inefficient in cost and energy.Sequencing technologies that enable analysis during sequencing increase the need for analysis to keep pace with sequencing throughput.Source: §2.3.4 · p. 47

2.4 Metagenomic Analysis

• Metagenomics analyzes organisms of different species in a shared environment, identifying which species are present and their relative abundances.This contrasts with traditional genomics focused on one individual or a small group from the same known species.Source: §2.4 · p. 48

2.4.1 Presence/Absence Identification

• Metagenomic tools extract read-set k-mers and search taxonomically indexed k-mer databases to identify species present in a sample.These databases may contain gigabytes or terabytes of data.Source: §2.4.1 · p. 48
• Gigabyte- or terabyte-scale metagenomic databases support random or streaming access, and the section examines these patterns to understand data-movement overheads.The passage introduces tools with random-access queries but provides no further details here.Source: §2.4.1 · p. 48
• Kraken2 uses random database accesses, while Metalign streams queries and matches long k-mers plus prefixes, increasing true-positive rate.Metalign uses large k-mers, such as k=60, to maintain a low false positive rate.Source: §2.4.1 · p. 49

2.4.2 Abundance Estimation

• Abundance estimation ranges from lightweight statistical models using taxonomic-tree relationships to computationally intensive reference-genome mapping that accurately counts species reads.Statistical models use taxIDs assigned to reads to determine the number belonging to each species.Source: §2.4.2 · pp. 49–50

2.4.3 Importance of High-Performance and Energy-Efficient Metagenomic Analysis

• Metagenomics supports clinical, environmental, agricultural, and other uses, while analysis may be repeated to tune accuracy goals or use updated and targeted databases.The text describes analysis as a bottleneck in the workflow and notes that metagenomics overcomes the need to culture individual known species in isolation.Source: §2.4.3 · p. 50
• 38 days to analyze data sequenced and basecalled in 48 hours on a high-end server node illustrates the metagenomic analysis bottleneck.Analysis throughput is also described as significantly lower than that of modern sequencers.Source: §2.4.3 · p. 50

2.5. GRAPH-BASED GENOMIC AND METAGENOMIC ANALYSIS

• 675 KJ, or 63% of total workflow energy, is required to process the dataset on a commodity server, making analysis the primary energy bottleneck.The text says simply scaling up commodity systems to improve analysis throughput worsens this energy bottleneck.Source: §2.5 · p. 51

2.5 Graph-Based Genomic and Metagenomic Analysis

• Sequence graphs have emerged as an approach for representing and querying massive, complex genomic databases containing reference genomes from many species or previously sequenced samples.Source: §2.5 · p. 51
• Genome graphs store shared genomic regions once and encode cohort diversity, reducing bias and improving accuracy while capturing population-specific variants missed by linear sequences [239, 244, 312, 814].Compacting shared subsequences can reduce sequence-set size by up to thousand-fold.Source: §2.5 · p. 52

2.5.1 Importance of High-Performance and Energy-Efficient Graph-Based Genomic Analysis

• High performance and energy efficiency are critical for graph-based analysis because conventional systems face challenges processing large sequencing-read volumes.A large body of work proposes techniques to improve both measures for graph-based genomic analysis.Source: §2.5.1 · p. 54

2.5.2 Unique Characteristics of Genome Graphs

• Genome graphs have distinctive semantics that make general-purpose graph structures and methods inefficient; DBGs store nodes or edges while deriving the other implicitly.This representation is enabled by sequence overlap and needed to handle genome graphs at massive scale.Source: §2.5.2 · p. 54

2.6. STORING AND COMPRESSING SEQUENCE DATA

• DBGs have indegree and outdegree at most four, limiting skew-based optimizations, while biological sequence queries create access-locality opportunities despite storage-imposed node ordering.Shared substrings in query reads can map to nearby regions of the graph’s index.Source: §2.6 · p. 55

2.6 Storing and Compressing Sequence Data

• As of October 2025, 75.9% (18 peta DNA bases) of public whole-genome read sets were unmapped FASTQ, and their size grew 42.5% per year on average over the prior decade.Sequence data volumes in public and private repositories are also growing by an order of magnitude every few years, approaching and expected to exceed volumes generated by major internet media platforms.Source: §2.6 · pp. 55–56
• Genomic compressors typically achieve ratios of ∼2 to ∼40, versus ∼2 to ∼6 for general-purpose compressors, which fail to leverage longer-range similarities common in DNA data.For DNA bases, each read set is represented by a consensus sequence and each read’s mismatches relative to it, including mismatch positions and bases.Source: §2.6 · pp. 56–57
• On evaluated datasets, Intel QAT and IBM zEDC achieved 2.6× and 2.7× lower average compression ratios than genomic compressors, while xz and zstd had 2.13× average and up to 6.7× worse ratios.These comparisons illustrate the compression-ratio gap between general-purpose and genomic-specific approaches.Source: §2.6 · p. 56
• Compression does not replace read mapping: future reference genomes and parameters may be unknown, reads may need remapping, and compression stores only one match although some analyses require many.Matching reads to a consensus during compression is independent of mapping operations in subsequent analysis.Source: §2.6 · p. 57

2.7 Summary and Outlook

• The dissertation identifies two bottlenecks: moving large amounts of low-reuse sequence data from storage, and decompressing and formatting compressed data before analysis.Its goal is to mitigate both through lightweight designs that improve performance, energy efficiency, and compression ratios while integrating with a broad range of analysis systems.Source: §2.7 · p. 58
• The dissertation proposes storage-centric computing for genomic, metagenomic, and graph-based (meta)genomic analysis, processing data on SSD controllers or flash dies to reduce data movement.These designs process data where it resides, using in-storage processing (ISP) or in-flash processing (IFP).Source: §2.7 · p. 58
• To mitigate data preparation bottlenecks, the dissertation co-designs algorithms and architecture for highly compressed storage and high-performance access to sequence data.This contribution is presented in Chapter 7.Source: §2.7 · p. 58

2.7. SUMMARY AND OUTLOOK

• The dissertation describes combining its storage-centric designs at low cost and identifies future opportunities enabled by its contributions.The integrated design and future directions are covered in Chapters 8 and 9, respectively.Source: §2.7 · p. 59

Related Work

• The related-work chapter covers storage I/O reduction, storage- and memory-centric computing, genomic and metagenomic acceleration, graph-based (meta)genomics, and genomic-specific compression.Its sections also describe where prior work falls short.Source: Related Work · p. 60

3.1.1 Reducing the I/O System Stack Overheads

• Storage I/O bottlenecks motivate approaches that streamline I/O-stack operations with specialized hardware or data paths, or bypass the kernel using user-space I/O.The stack’s software layers can add context-switch, data-copy, lock-contention, and interrupt-handling overheads.Source: §3.1 · p. 60, §3.1.1 · p. 60

Accelerating the I/O Stack Operations

• Prior I/O-stack acceleration includes zero-copy techniques, DPUs that offload infrastructure tasks, and direct storage access for accelerators such as GPUs.Examples include mmap and io_uring, plus GPUDirect and BaM for direct storage-to-GPU access.Source: Accelerating the I/O Stack Operations · p. 61

User-Space I/O Frameworks

• Kernel-bypass frameworks provide user-space storage access, while exposed device organization lets hosts control data placement and tailor SSD management.SPDK and NVMeDirect are cited examples; ZNS and Open-Channel SSDs expose different forms of device organization.Source: User-Space I/O Frameworks · pp. 61–62, §3.1.2 · p. 62

3.1.3 Request Batching, Scheduling, and Prefetching

• Other I/O-reduction approaches batch, schedule, prefetch, cache, or compress data, with effectiveness depending on access-pattern predictability, locality, and compression cost.Compression trades off ratio, performance, energy efficiency, and computational cost; caching depends on working-set size relative to cache capacity.Source: §3.1.3 · p. 62, §3.1.4 · pp. 62–63

3.1.5 Data Reduction

• Deduplication stores unique data blocks and replaces duplicates with references, reducing storage capacity and I/O overhead when redundancy is high.It can operate at file or sub-file block granularity and inline or as post-processing, but adds metadata management and may increase read amplification through fragmented mappings.Source: §3.1.5 · p. 63

3.1.6 Hybrid Storage and Memory Systems

• Hybrid storage and memory systems combine technologies with different cost, capacity, and performance characteristics to provide trade-offs across tiers.Placement and migration policies use access patterns or workload-specific heuristics; tiering may be managed by the OS or storage controller, or controlled by the user.Source: §3.1.6 · p. 63

3.1.7 Memory and Storage Disaggregation and Expansion

• CXL memory expansion can reduce working-set spills to storage, but does not eliminate the need to access large, low-reuse datasets.CXL attaches memory devices through a cache-coherent PCIe interconnect and can expand memory beyond a node’s DIMM slots, including through memory pools shared across hosts.Source: §3.1.7 · p. 64
• Disaggregated storage decouples storage capacity from compute and enables independent scaling, but network and fabric traversal adds latency and exposes requests to congestion and interference.NVMe over Fabrics extends the NVMe command set across network fabrics, enabling remote SSD access with latency approaching a locally attached device; reducing data crossing the interface is therefore especially valuable.Source: §3.1.7 · p. 64

3.1.8 I/O Amplification Reduction

• I/O amplification occurs when device data read or written exceeds the application’s logical request; mismatched access granularity can cause read amplification, while garbage collection drives write amplification in NAND SSDs.Approaches include log-structured storage, key-value separation, data-structure alignment, and host-managed placement that co-locates data with similar lifetimes to reduce write amplification.Source: §3.1.8 · pp. 64–65

Improving NAND Flash Chip Latency

• NAND-level techniques reduce read or write latency through wear-aware read-reference voltage tuning, read-retry optimization, finer-grained partial programming, and erase-operation optimization.The subsection frames within-device improvements as ways to reduce I/O latency and increase throughput; transitions from SLC to MLC, TLC, and QLC raise density but also read and write latencies.Source: §3.1.9 · p. 65, Improving NAND Flash Chip Latency · p. 65

Reducing Contention

• Storage-device contention arises when requests compete for shared resources such as channels, dies, planes, or internal buses.Proposed mitigations include data placement, lightweight internal network structures, and reducing SSD management-task overhead such as garbage collection.Source: Reducing Contention · p. 65

Improving NAND Flash Chip Latency

• 3D NAND with improved cell architectures offers denser storage and improved scalability compared with planar NAND.Source: Improving NAND Flash Chip Latency · p. 65

Other Storage Device Optimizations

• Controller and firmware optimizations use command scheduling and queue management to improve I/O performance, fairness across applications and users, and quality of service.Source: Other Storage Device Optimizations · pp. 65–66

3.1.10 Storage-Centric Computing

• Storage-centric computing approaches are tightly attached processing, controller-level in-storage processing (ISP), and in-flash processing (IFP), with computation placed progressively closer to stored data.ISP computes within the storage device, while IFP computes within NAND flash dies.Source: §3.1.10 · p. 66
• GenStore is presented as the first in-storage system for genome sequence analysis and supports short and long reads and varying genetic differences between genomes.The text also notes that a later filter for genomics in storage can be combined with GenStore’s design.Source: §3.1.10 · p. 67
• MegIS is presented as the first storage-centric system to reduce data movement across the end-to-end metagenomic analysis pipeline through a cooperative host–SSD pipeline.Its design addresses challenges in applying in-storage processing to metagenomics.Source: §3.1.10 · p. 67
• GRAINS enables storage-centric graph-based (meta)genomic analysis through storage-aware algorithm–architecture co-design, storage-friendly pipelines, and ISP and IFP.The proposed storage-centric techniques alleviate low-reuse data movement and reduce the computational burden on the rest of the system, and can complement other approaches.Source: §3.1.10 · p. 67, §3.2 · p. 68

3.2. MEMORY-CENTRIC COMPUTING

• The proposed storage-centric techniques can be combined with other approaches in the section to improve end-to-end performance.Making genomic and metagenomic pipelines more storage-friendly helps them use bandwidth provided by direct storage access, user-space I/O frameworks, and storage-device optimizations.Source: §3.2 · p. 68

3.2 Memory-Centric Computing

• Memory-centric computing (MCC), or processing-in-memory (PIM), aims to reduce data movement between main memory and computational units by making memory systems compute-capable.Its broad categories are processing near memory (PNM), which places computational units near or within memory, and processing using memory (PUM), which uses memory technology’s analog properties to compute.Source: §3.2 · p. 68
• Memory-centric designs can avoid host-to-main-memory transfers, but movement between memory chips and computational chips still consumes more energy than movement within a memory chip.The section frames storage-centric and memory-centric designs as complementary approaches.Source: §3.2 · p. 68, §3.3 · p. 69

3.3. ACCELERATING GENOMIC ANALYSIS

• Memory-chip computation offers greater internal bandwidth and energy efficiency than approaches that move data between memory and computational chips.The text distinguishes computation on a 3D-stacked memory logic layer or near memory banks from processing-in-memory that uses existing memory interconnects and cell-array bandwidth without dedicated computational units.Source: §3.3 · p. 69

3.3 Accelerating Genomic Analysis

• Read-mapping accelerators include non-filtering and filtering approaches, and an in-storage filter can combine with a PIM-based read-mapping accelerator to remove I/O movement overheads.Filtering approaches eliminate dissimilar sequences before computationally expensive alignment; the combined design is demonstrated in Chapter 4.Source: §3.3 · p. 69

3.4. ACCELERATING METAGENOMIC ANALYSIS

• GenStore’s in-storage filters and SAGe’s mitigation of genomic data preparation can be orthogonally combined with genome-analysis accelerators to improve end-to-end performance.The dissertation gives examples integrating GenStore and SAGe with state-of-the-art accelerators in Chapters 4 and 7, respectively.Source: §3.4 · p. 70

3.4 Accelerating Metagenomic Analysis

• MegIS is presented as the first storage-centric system designed to reduce data movement across end-to-end metagenomic pipelines, using a cooperative host–SSD pipeline.Existing GPU, FPGA, and PIM approaches alleviate computation or main-memory overheads but do not reduce I/O; MegIS is compared with a state-of-the-art PIM baseline.Source: §3.4 · p. 70

nomics Analysis

• Hardware for querying sequence graphs can reduce computation or memory overheads, but the cited approaches do not alleviate I/O overheads.The text notes that I/O matters more to end-to-end performance as other overheads are reduced.Source: nomics Analysis · p. 70, §3.5 · p. 71

3.5. ACCELERATING GRAPH-BASED GENOMICS AND METAGENOMICS ANALYSIS

• GRAINS is presented as the first storage-centric system designed to reduce data movement in end-to-end genome-graph analysis pipelines.It integrates with other graph-analysis works to alleviate I/O and uses storage-aware algorithm–architecture co-design to make pipelines storage-friendly and improve performance, energy efficiency, and cost-effectiveness via ISP and IFP.Source: §3.5 · p. 71

3.6 Compressing Sequence Data

• Compact genomic-data compression is important amid the continuing exponential growth of genomics repositories.The section points to genomics-specific compression work.Source: §3.6 · p. 72
• Computational kernels including BWT, FM-Index search, and LZMA [474, 1192] are widely used in genomic compressors but can be unsuitable for resource-constrained environments or leave preparation bottlenecks unresolved.The passage identifies these as limitations of existing approaches.Source: §3.6 · p. 72
• Some compression algorithms that avoid expensive resources compress poorly, and general-purpose compressors achieve poor compression ratios for genomic data.Source: §3.6 · p. 72
• SAGe provides significant performance benefits when integrated into a resource-constrained environment.The passage does not specify the comparison baseline or quantify the benefits.Source: §3.6 · p. 72
• SAGe is presented as the first system to mitigate the sequence-analysis data-preparation bottleneck while retaining compression ratios comparable to state-of-the-art genomic compressors.Its lightweight design supports integration with a wide range of genomic and metagenomic systems.Source: §3.6 · p. 72

4.1.1 Methodology

• The study compares five mapping systems across SSD-L, SSD-M, SSD-H, and idealized DRAM; 80% of the short-read dataset exactly matches the human reference genome.Base uses Minimap2 [294], SW-filter adds SIMD exact-match filtering, and the ideal in-storage-filter variants model filtering concurrent with host or accelerator mapping.Source: §4.1.1 · p. 73, §4.1 · p. 74

4.1.2 Results & Analysis

• On SSD-H, Ideal-ISF outperforms Base and SW-filter by 3.12× and 2.21×, while Ideal-ISF+ACC speeds up ACC by 2.78×.The gains come from reducing storage-to-system data movement and removing the burden of filtering 80% of reads from processors and memory.Source: Figure 4.1 · p. 75, §4.1.2 · p. 75
• With SSD-H, Ideal-OSF takes 1.15 seconds—60% longer than Ideal-ISF+ACC—because reading all reads costs more than reading and mapping only unfiltered reads.Ideal-OSF filters outside storage, so it does not avoid moving all reads from the SSD into memory.Source: §4.1.2 · p. 75
• Replacing SSD-L with SSD-H reduces Base and SW-filter execution time by 24% and 38%, respectively, bringing performance close to DRAM.The study reports SSD-L, SSD-M, and SSD-H internal sequential-read bandwidths of 19.2×, 5.48×, and 2.74× their respective external bandwidths; high-end SSD capacity scaling is constrained by price and PCIe-slot availability.Source: §4.1 · p. 74, §4.1.2 · pp. 75–76
• Even with DRAM, SW-filter speeds up Base by only 41%, as random reference-index accesses and resource contention constrain filtering outside the SSD.In contrast, filtering reads where they reside inside the SSD removes that filtering burden from the rest of the system.Source: §4.1.2 · p. 76
• With ACC, SSD-H still takes 23% longer than DRAM, because accelerating computation makes I/O a bottleneck again.The comparison of ACC and Ideal-ISF+ACC highlights storage-to-accelerator data movement as a limiting factor.Source: §4.1.2 · p. 76

4.2. GENSTORE

• Prior read-mapping accelerators [363] can significantly bottleneck the potential benefits of read mapping.Source: §4.2 · p. 77
• At least 1.55 seconds for SSD-H to read the entire dataset was 2.15× slower than Ideal-ISF+ACC’s 0.72-second execution time.This motivational study illustrates that storage-to-accelerator data movement can remain a bottleneck even when computation and main-memory overheads are addressed.Source: §4.2 · p. 77

4.1.3 Our Goal

• An in-storage filter can enable both software-based and hardware-accelerated read mappers to use their computation capacity while addressing the data-movement bottleneck.The design goal includes overlapping filtering with mapping, supporting reads with varied lengths, error rates, and genetic variation, and avoiding substantial hardware overhead.Source: §4.1.3 · p. 77

4.2 GenStore

• GenStore is an in-storage processing system for genome sequence analysis that uses low-cost, accurate filters to reduce data movement and computational overhead.It is designed as an extension of the SSD controller and flash translation layer.Source: §4.2 · pp. 77–78
• GenStore supports reads with different lengths and error rates and different degrees of genetic variation in the compared genomes.Its design extends the existing SSD controller and flash translation layer, and uses low-cost, accurate in-storage filters.Source: §4.2 · p. 78

4.2.1 Overview

• GenStore concurrently reads data from NAND flash and filters reads that need no further analysis, sending unfiltered reads to the host for computation.SSD-level and channel-level accelerators use the SSD’s internal bandwidth, and the filtering process is designed to be almost completely removed from the application’s critical path.Source: §4.2.1 · pp. 78–79
• GenStore reuses internal DRAM for filtering metadata by flushing regular FTL mapping data to NAND, and its metadata can be built offline once and reused across applications.The filtering algorithms sequentially access NAND, requiring only a small amount of metadata to access stored data.Source: §4.2.1 · p. 79

Approach Overview

• GenStore-EM filters reads with at least one exact reference match, but is not applicable to long reads because exact matches become very unlikely.Short reads’ low error rates and low genetic variation make exact matches common; for a 10K-base-pair human read with zero sequencing errors, the probability is below 3.6 × 10^-6.Source: Approach Overview · pp. 79–80
• GenStore-EM’s exact-match filtering requires random accesses to large k-mer indexes and reference genomes, which are challenging for NAND flash and exceed available SSD DRAM.The cited examples are 4 GB of internal DRAM versus 7 GB for the human reference genome and its index.Source: Approach Overview · p. 80
• GenStore-EM sequentializes most data access with a sorted, read-sized k-mer index, enabling sequential read-set scanning with only one index lookup per read during filtering.The sorted read table and index support exact-match detection by streaming reads and k-mers through a comparator.Source: Approach Overview · p. 80
• Sequentially accessed structures and simple comparator logic make GenStore-EM’s exact-match filter suitable for streaming and fully pipelined in-storage processing.This design leverages NAND flash’s high sequential read bandwidth.Source: Approach Overview · p. 81
• The human-reference SKIndex grows from 21 GB at k=15 to 126 GB at k=150, but its sequential access makes the larger read-sized index feasible for in-storage processing.The larger index is motivated by using read-length k-mers rather than the shorter k values common in conventional read mappers.Source: Approach Overview · p. 81

Design of GenStore-EM

• GenStore-EM fetches read-table and index batches from NAND to internal DRAM, filters them in the SSD accelerator, and pipelines filtering with host mapping of unfiltered reads.The concurrent host mapping and SSD filtering divide the work between the two systems.Source: Design of GenStore-EM · p. 82
• At a read size of 150 bps, the optimized human-reference SKIndex is 32 GB, 3.9× smaller than the unoptimized index, and fingerprints reduce exact-match comparison overhead.Strong hashes replace raw read-sized k-mers in the index and enable comparison using fingerprints; their extremely low collision rate is described as not affecting mapping accuracy.Source: Design of GenStore-EM · p. 83
• 174 MB/s of preprocessing throughput on a personal laptop exceeds the sequencer’s 18.9 MB/s read-data throughput, allowing preprocessing to overlap sequencing and basecalling.Preprocessing generates hashes and sorts reads; its overhead can be amortized by reusing preprocessed data across mapping experiments.Source: Design of GenStore-EM · p. 83
• GenStore-EM compares read and k-mer fingerprints in batches: a lower read fingerprint rules out an exact match, while an equal fingerprint marks an exact match.Reads ruled out by this filter are sent to the host for read mapping.Source: Design of GenStore-EM · p. 84
• GenStore-EM’s execution time is bottlenecked by fetching batches from NAND, so its performance can scale with greater SSD internal parallelism.Data fetching streams batches to internal DRAM using the SSD’s full internal bandwidth.Source: Design of GenStore-EM · p. 84

Approach Overview

• 31.7%–99.6% of reads in the analyzed use cases do not align to the reference, making in-SSD filtering a way to reduce data movement and unnecessary ASM computation.The use cases include high sequencing error and high genetic variation; Table 4.1 summarizes their read sets and aligning fractions.Source: Approach Overview · p. 85, Table 4.1 · p. 85
• GenStore-NM performs fast chaining only on reads with few seeds and sends other reads to the host, since reads with many seeds are likely to align.Selective chaining can filter non-aligning long reads without costly SSD hardware resources.Source: Approach Overview · p. 86

Alignment

• At 64, 128, and 256 seeds, average read-alignment probabilities are 88.87%, 91.32%, and 93.84%, respectively.GenStore-NM therefore chains reads with fewer than a configurable seed threshold and sends reads at or above it to the host, reducing chaining time and hardware area while filtering most non-aligning reads.Source: Alignment · p. 86

Design of GenStore-NM

• GenStore-NM finds minimizer seeds, filters reads with fewer than M seeds, sends reads above N seeds to the host, and chains the remaining reads in the SSD.Reads with too few seeds would fail the baseline mapper’s minimum chaining-score requirement [294]; reads with more than N seeds are likely to align and can undergo full mapping concurrently with filtering.Source: Design of GenStore-NM · p. 87
• KmerIndex optimizations reduce the human-reference index from 5.8 GB to 2.9 GB, enabling storage in the SSD’s limited DRAM.The changes omit the reference genome, omit seeds with many matching locations, and increase hash-table buckets so each holds one minimizer.Source: Design of GenStore-NM · pp. 87–88
• GenStore-NM selectively chains reads with fewer than N seeds, using shift-based multiplication approximations that overestimate scores to avoid filtering potential mappings.The design performs the same chaining computations as the baseline filter for reads with fewer than N seeds and does not affect read-mapping accuracy.Source: Design of GenStore-NM · pp. 88–89

4.2.4 GenStore Flash Translation Layer (FTL)

• GenStore’s FTL uses metadata to access its data structures without the regular FTL’s L2P table and sequentially distributes data across NAND chips for accelerator-mode bandwidth.Data structures are stored using multiple sets of NAND blocks with the same block offset across the sets.Source: §4.2.4 · p. 90
• Because accelerator-mode GenStore only reads data structures, it omits write-related SSD tasks such as garbage collection and wear-leveling.Reliability maintenance can occur before or after filtering: GenStore refreshes data nearing its retention limit and refreshes pages with high read counts to prevent read-disturb errors.Source: §4.2.4 · p. 90, §4.3 · p. 91

4.3 Evaluation Methodology

• The evaluation compares Minimap2-based Base, externally filtered GS-Ext, and in-storage GS; GS-Ext reduces mapper work but does not alleviate I/O bottlenecks.GS combines Base with GenStore-EM and GenStore-NM accelerators, which filter reads inside the SSD while Base maps unfiltered reads.Source: §4.3 · p. 91

4.4. EVALUATION

• Evaluation uses low-, mid-, and high-end SSD configurations and read sets varied in size and exact-match fraction, with simulated short reads up to 440 GB.The short-read sets use 75% or 85% exactly-matching reads; long-read experiments use the reference genome and read set from Table 4.1, with larger sets generated by concatenation.Source: §4.3 · p. 92, §4.4 · p. 93

4.4.1 Area and Power Analysis

• GenStore’s total hardware area is 0.20 mm^2 at 65 nm and 0.02 mm^2 at 14 nm, only 0.006% of a 14nm Intel Processor.Source: §4.4.1 · p. 94
• 0.06 mm2 at 32 nm is less than 9.5% of the area of three 28nm ARM Cortex R4 processors; most logic units scale linearly with channel count.The comparator supports up to 12 channels, the hash64 accelerator up to 4, and the control unit remains unchanged across channel counts.Source: §4.4.1 · p. 94

4.4.2 GenStore-EM Analysis

• Across SSDs, GS outperforms Base and SIMD by 2.07–2.45× and 1.66–2.09×, respectively; its average benefit over Base is 2.23×, versus 1.19× for SIMD.GS-Ext provides limited benefits over SIMD in SSD-L.Source: §4.4.2 · pp. 94–95
• With a hardware read mapper, GS significantly outperforms Base by 3.32×, 2.55×, and 1.52× on systems with SSD-L, SSD-M, and SSD-H, respectively.Source: Figure 4.8 · p. 94, §4.4.2 · p. 95
• With a software mapper, GS gains rise from 2.62× to 4.75× as read-set size grows and from 3.46× to 6.05× with higher exact-match rates for the largest read set.The increases reflect greater data-movement savings and less time mapping unfiltered reads.Source: §4.4.2 · p. 96
• With a hardware mapper, GS gains rise from 1.52× to 3.13× as input size grows, but do not increase with higher exact-match rates.The in-SSD filter time depends on input size, not exact-match rate.Source: §4.4.2 · pp. 96–97

4.4.3 GenStore-NM Analysis

• With a software read mapper, GS outperforms Base by 22.4×, 29.0×, and 27.9× on SSD-L, SSD-M, and SSD-H, respectively.Source: §4.4.3 · p. 97, Figure 4.10 · p. 97
• 19.2×, 6.86×, and 6.85×: GS outperforms Base with a hardware read mapper on SSD-L, SSD-M, and SSD-H, respectively.GS-Ext provides no significant benefit over Base on SSD-L and SSD-M, and is 2.50× faster than Base on SSD-H; its gains remain limited compared to GS.Source: §4.4.3 · pp. 97–98, Figure 4.10 · p. 97
• Across software and hardware read mappers, GenStore-NM benefits vary little with input size but grow as alignment rates fall, because filtering saves data movement and mapping work.The analysis attributes the limited input-size effect to the reference genome’s small 14.6 MB size.Source: §4.4.3 · p. 98

4.4.4 Energy Analysis

• 3.92× average (up to 3.97×) and 27.17× average (up to 29.25×) energy-consumption reductions are reported for GenStore-EM and GenStore-NM, respectively, across storage configurations.The comparison is against Base (Minimap2 [294]).Source: §4.4.4 · p. 99

4.5. DISCUSSION

• GenStore-NM can keep filtering non-aligning reads as long-read accuracy increases, while GenStore-EM can filter exactly matching short reads needed for processes such as polishing and validation.The discussion also anticipates demand for data-movement-minimizing systems on portable sequencing devices with limited compute and DRAM capacity.Source: §4.5 · p. 100

4.5 Discussion

• GenStore-NM filters >99.7%, ∼36.1%, and ∼47.3% of reads in cited analyses, improving end-to-end throughput and energy efficiency.The cited analyses concern gene detection, SARS-CoV-2 read alignment, and studies of undiscovered microbes, respectively.Source: §4.5 · p. 100, §4.6 · p. 101

4.6 Summary

• GenStore is an in-storage processing system that integrates with hardware and software read mappers to improve end-to-end short- and long-read mapping performance using co-designed filtering techniques and accelerators.The summary reports large performance and energy improvements when integrated into state-of-the-art mappers.Source: §4.6 · p. 101

4.6.1 Impact and Influence

• GenStore has influenced work on genomic in-storage filters, other bioinformatics subdomains, and AI/ML, and its storage-centric ideas may improve performance, energy efficiency, and cost-effectiveness in health and life-science applications.The discussion names prior work on additional genomic filters, in bioinformatics, and in AI/ML.Source: §4.6.1 · p. 101

5.1.1 Data Movement Overheads

• Evaluation contrasts Kraken2's random-access Random-Qry with Metalign's streaming Stream-Qry on CAMI-L's 100 million reads and tool-specific databases.The databases include 293 GB for Kraken2 and a 701 GB k-mer database plus a 6.9 GB sketch tree for Metalign, with larger databases also tested.Source: §5.1.1 · p. 102

5.1. MOTIVATIONAL ANALYSIS

• I/O hurts Stream-Qry more because of its lower data reuse, costly SSD-P still leaves a performance gap to DRAM, and overhead grows with database size.For Random-Qry, the SSD-C-to-DRAM gap widens from 7.1× to 12.5× as the database grows from 0.3 TB to 0.6 TB.Source: §5.1 · p. 103
• DRAM is 9.4× (1.7×) faster than SSD-C (SSD-P) for Random-Qry, and 32.9× (3.6×) faster for Stream-Qry, averaged across both databases.Throughput is measured in queries/sec and normalized to DRAM.Source: Figure 5.1 · p. 103, §5.1 · p. 103
• For 0.3-TB and 0.6-TB Kraken2 databases using a PIM accelerator, DRAM is 26.1× (3.0×) faster than SSD-C (SSD-P) on average.Accelerating other bottlenecks does not eliminate the overhead of moving large, low-reuse data from storage.Source: §5.1 · p. 104

5.1.2 Our Goal

• ISP could reduce data movement, but random accesses constrain SSD bandwidth while streaming approaches require more computation and main-memory capacity.These constraints make directly implementing existing metagenomic approaches effectively on an SSD challenging.Source: §5.1.2 · p. 104

5.2. MEGIS

• MegIS targets lower storage data movement to improve metagenomic analysis performance and efficiency.The system can use specialized lightweight accelerators or existing embedded SSD cores or general-purpose ISP systems; specialized accelerators offer the highest performance and power efficiency.Source: §5.2 · p. 105

5.2 MegIS

• MegIS is proposed as the first ISP system designed for the end-to-end metagenomic analysis pipeline, using hardware/software co-design for cooperative ISP.It coordinates processing inside and outside storage in an efficient pipeline and extends the SSD controller and FTL without affecting baseline SSD functionality.Source: §5.2 · p. 105

5.2.1 Overview

• Figure 5.2 presents an overview of MegIS's steps as an efficient pipeline.Source: §5.2.1 · p. 105
• MegIS pipelines host query processing and transfer to SSD species search, then prepares and transfers data for further analysis, including abundance estimation.Its specialized data and control flow is described as avoiding channel conflicts and frequent management tasks during in-storage processing.Source: §5.2.1 · p. 106

5.2.2 Step 1: Preparing the Input Queries

• MegIS prepares queries on the host by extracting, sorting, and optionally pruning k-mers, avoiding offline storage of per-sample sorted sets that may exceed the sample size.Host DRAM and computation resources support this step, and host-side execution enables overlap with Step 2.Source: §5.2.2 · p. 106

K-mer Extraction

• MegIS improves on KMC by partitioning k-mers into lexicographical buckets, overlapping each bucket’s sorting and transfer with SSD processing of previously transferred buckets.If extracted k-mers do not fit in host DRAM, some buckets remain there while the SSD stores others, avoiding back-and-forth movement for DRAM-resident buckets.Source: K-mer Extraction · pp. 107–108

Sorting

• As soon as a bucket is sorted, MegIS transfers it to SSD DRAM in batches for Step 2 while sorting the next bucket.A sorting accelerator can also be used.Source: Sorting · p. 108

Excluding K-mers

• On average, extracted query k-mers are 60 GB in our experiments, while the k-mer set selected for Step 2 is 6.5 GB.Users can exclude overly common k-mers and very infrequent k-mers, which may represent sequencing errors or low-abundance organisms.Source: Excluding K-mers · pp. 108–109

5.2.3 Step 2: Finding Candidate Species

• MegIS intersects query k-mers with database k-mers and finds their taxIDs inside the SSD, using its internal bandwidth for this large, low-reuse scan and lightweight computation.This placement is intended to alleviate the burden of moving and analyzing large, low-reuse data elsewhere in the system.Source: §5.2.3 · p. 109

Intersection Finding

• Intersection finding identifies k-mers shared by host-arriving query buckets and the flash-resident database, with both streams arriving at full bandwidth for buffering.The passage describes buffering the query k-mers from the host and database k-mers from SSD channels.Source: Intersection Finding · p. 109
• Reading database data from SSD channels at full bandwidth can exceed LPDDR4 or 16-GB/s DDR4 bandwidth, so MegIS operates on flash-fetched data without buffering it in internal DRAM.This approach addresses DRAM bandwidth pressure but otherwise requires large per-channel input and output buffers.Source: Intersection Finding · p. 109
• MegIS computes directly on flash data streams using two k-mer registers per channel, avoiding a large buffer for data awaiting computation.One register holds the computation input while the other stores the subsequent k-mer read from flash; the approach relies on lightweight computation and data distributed across channels.Source: Intersection Finding · pp. 109–110
• MegIS compares sorted query k-mers from internal DRAM with sorted database k-mers from flash using per-channel Intersect units, then writes matches to DRAM.The process reads query k-mers into DRAM in batches, compares both sorted streams, and returns intersecting k-mers to DRAM for further analysis.Source: Intersection Finding · p. 110
• MegIS overlaps query transfer and intersection finding by managing two query batches in internal DRAM.For the described 8-channel SSD configuration, it reserves space for two 1-MiB batches.Source: Intersection Finding · p. 110
• 2.4 GB/s of DRAM bandwidth is required to access all evaluated datasets when MegIS fully uses SSD-P’s internal flash bandwidth.The query set, intersection, and FTL metadata require much less bandwidth than reading the database.Source: Intersection Finding · p. 111

6.1 Motivational Analysis

• The study assesses I/O overheads in graph-based genome analysis using k-mer lookup with Fulgor and MetaGraph.The evaluation uses the tools’ best-performing thread counts and color encodings, with graphs built from a pilot MetaSUB subsample and query sizes from 100K to 10M reads.Source: §6.1 · p. 129, §6.1.1 · p. 129

6.1.1 Data Movement Overheads

• 16.7× (SSD-M) and 9.3× (SSD-H) average-performance gains for Fulgor, and 7.5× (SSD-M) and 4.5× (SSD-H) for MetaGraph, show DRAM’s advantage.The comparison is against storage I/O configurations; Figure 6.1 reports normalized throughput across query sizes.Source: Figure 6.1 · p. 130, §6.1.1 · p. 130
• Storage I/O causes large graph-analysis overheads that are expected to worsen, because large amounts of low-reuse data move through the system to computation.Caching the data in DRAM does not significantly amortize the overhead, even when DRAM exceeds the accessed data size.Source: §6.1.1 · p. 131
• Sampling reduces accuracy, while keeping all required graphs resident in DRAM is energy-inefficient, costly, and unscalable as graphs and analysis needs grow.Different analyses require different genome sets or graph parameters, making it prohibitively inefficient to keep all possible data resident.Source: §6.1.1 · p. 131
• Graph topology creates irregular, dependent access patterns and low data reuse, so genome graphs still incur large I/O overheads despite compact population-scale representation.The resulting poor locality compounds the cost of moving large, continually growing graphs.Source: §6.1.1 · p. 131

Storage-Centric Computing (SCC)

• Storage-centric computing eliminates unnecessary movement of low-reuse data, reduces work on memory and compute units, and can let components be simplified, repurposed, or turned off.It can also exploit SSD internal bandwidth, which often exceeds external bandwidth.Source: Storage-Centric Computing (SCC) · p. 132
• 14 GB/s of external bandwidth versus up to 57.6 GB/s internally illustrates the SSD bandwidth available to storage-centric processing.Processing directly in NAND flash can exploit aggregate bandwidth across dies, exceeding both SSD-controller processing bandwidth and external SSD bandwidth.Source: Storage-Centric Computing (SCC) · p. 132

Challenges and Goal

• GRAINS uses storage-aware algorithm–architecture co-design to address graph-analysis access irregularity and data-movement overheads on resource-constrained SSDs.Its design makes analysis pipelines more storage-friendly and uses in-storage processing (IFP) and processing (ISP) to improve performance, energy efficiency, and cost-effectiveness.Source: Challenges and Goal · p. 132

6.2 GRAINS

• GRAINS supports k-mer lookup and read mapping, integrates with existing alignment accelerators, and functions as a general-purpose SSD outside analysis mode.It augments the SSD controller, flash dies, and FTL for graph analysis.Source: §6.2 · p. 133
• GRAINS reduces random graph accesses through specialized batching, reordering, and pipelining, then uses lightweight IFP to process needed page data within flash dies.This avoids transferring low-reuse or unused page contents beyond the die; lightweight ISP units and per-die scheduling tables coordinate IFP operations.Source: §6.2 · p. 133

6.3. DATA STRUCTURES

• GRAINS batches host queries, accesses graph data through IFP and ISP, and pipelines these steps while avoiding writes during analysis to use SSD internal bandwidth.The FTL orchestrates communications and data flow across SSD components.Source: §6.3 · p. 134

6.3 Data Structures

• GRAINS represents graph sequences and colors with a node-centric de Bruijn graph dictionary, using SSHash to exploit k-mer statistics for a space-time trade-off.Unitigs are stored as contiguous strings and located using a minimal perfect hash function built for the k-mer set.Source: §6.3 · pp. 134–135

Color

• GRAINS sorts unitigs by graph color and marks each color’s start with a bitmap, compactly encoding repeated colors.Source: §6.4 · p. 136

6.4 Input Query Processing

• GRAINS prepares reads for graph queries using two optimizations inspired by genome-graph and query properties, including cross-read k-mer batching.Source: §6.4 · p. 136
• GRAINS looks up k-mers in the host-resident Sizes array, whose footprint is under 4% of large-scale graphs, and sorts and batches them before SSD access.The Sizes indices enable batching to reduce graph accesses; extracting k-mers on the host also avoids frequent SSD writes that would reduce SSD lifetime.Source: §6.4 · p. 136

6.5. GRAPH QUERY

• Compacting sorted k-mers by storing each shared minimizer once and retaining only differences reduces transferred data by 2.3× on average across evaluated datasets.GRAINS also overlaps sorting one batch with transfer and Offsets lookups for the previous batch.Source: §6.5 · p. 137

6.5 Graph Query

• Inside the SSD, GRAINS uses IFP to retrieve colors for matching k-mers while avoiding unnecessary page transfers and leveraging multiple dies in parallel.A lightweight FSM on the SSD controller coordinates accesses to Offsets, Strings, and Colors.Source: §6.5 · p. 137

Accessing Graph Offsets

• Sorting k-mers by Sizes and uniformly placing Offsets across dies enables sequential lookups that exploit internal bandwidth; IFP extracts only targeted entries, limiting channel transfers and DRAM writes.The small portion written to internal DRAM prevents its bandwidth from becoming a bottleneck.Source: Accessing Graph Offsets · p. 138

Accessing Graph Strings

• GRAINS uses a lightweight scheduler to coalesce Strings requests to the same page and maximize die-level parallelism without sorting accelerators.It reads GST rows sequentially and issues requests round-robin across dies and planes, avoiding redundant page accesses with minimal metadata and no complex logic.Source: Accessing Graph Strings · pp. 138–139
• For large read sets and graphs, GSTs require 2.9 GB of internal DRAM for about 10 million query reads, within a typical 4-GB SSD allocation.If usage exceeds internal DRAM capacity, GRAINS keeps some Sizes batches in host DRAM until the SSD finishes processing the current batch.Source: Accessing Graph Strings · p. 139

6.6. FTL INTEGRATION AND RELIABILITY SUPPORT

• GRAINS scans the Color Bitmap directly from NAND while streaming unitig IDs, then selects only relevant color-page portions after light ECC, avoiding internal-DRAM buffering.The bitmap is consumed immediately, and the ISP units operate on NAND streams.Source: §6.6 · p. 140
• Uniform round-robin placement across channels, dies, and planes balances batched accesses and lets GRAINS merge repeated-page accesses without workload-specific profiling.For persistently skewed query distributions, profile-guided initial placement could offer additional load balancing without changing GRAINS’s core logic.Source: §6.6 · p. 141
• For a 1-TB graph with 12-MB blocks, GRAINS requires 0.35 MB of block-granularity L2P metadata; overall FTL metadata is 0.7 MB.GRAINS needs no fine-grained remapping during SCC because it performs no writes, and uniform placement makes physical locations computable from base addresses and stride.Source: §6.6 · p. 141
• Because SCC performs no writes and reads each block at most once, GRAINS avoids write-related management and read-disturbance errors during execution, refreshing blocks above a threshold afterward.Each process is shorter than the manufacturer-specified reliable-retention age threshold.Source: §6.6 · p. 141, §6.7 · p. 142

6.7 Interface Commands

• GRAINS adds three NVMe commands: GRNS_Start initializes acceleration, GRNS_Steps signals pipeline steps and transfers query batches for processing, and GRNS_Write writes genome graphs.Batches remain in internal DRAM rather than being programmed to flash, and the host can prepare the next batch while the SSD processes the current one.Source: §6.7 · p. 142

6.8 Deployment and Integration

• GRAINS’s ISP/IFP steps can run on specialized lightweight logic for power efficiency or general-purpose units to facilitate near-term adoption.Choosing between these configurations is a design decision.Source: §6.8 · p. 142

6.9. METHODOLOGY

• GRAINS requires small, non-disruptive FTL changes, and outside SCC acceleration the SSD operates identically to a standard general-purpose SSD.Its three-command host-device protocol extension is lightweight.Source: §6.9 · p. 143
• Software integration uses standard vendor-specific NVMe extensions, with file-system and driver changes limited to identifying genome graph files and mapping three commands.The passage characterizes this integration as straightforward, low-cost, and non-disruptive to the existing storage stack.Source: §6.9 · p. 143

6.9 Methodology

• GRAINS’s simulator models system components and stage interactions, including chunk transfers, dependencies, and communication costs between host and SSD.Hardware logic is implemented in Verilog and synthesized with a 22nm library; software component performance is measured on a real system.Source: §6.9 · pp. 143–144

6.10.1 Performance

• GRN provides 2× average speedup over GRN-Ext, with its in-SSD SCC design alleviating large I/O overheads.GRN-Ext uses GRAINS’s optimizations and lightweight accelerator outside the SSD; GRN includes ISP and IFP.Source: §6.10.1 · pp. 145–146
• With SSD-M (SSD-H), GRN achieves 8.4× (5.5×) average speedup over FG and 11.9× (8.5×) over MG.Figure 6.10 reports speedups across input query sets and SSDs.Source: Figure 6.10 · p. 145, §6.10.1 · p. 145
• GRN($) yields 4.7× and 5.2× average speedup over FG($$$) and MG($$$), and 13.2× and 26.9× over FG and MG on the same cost-optimized system.The first comparison is against performance-optimized systems; the second compares systems on the same cost-optimized configuration.Source: Figure 6.11 · p. 146, §6.10.1 · p. 146
• GRAINS moves 31.4× and 39.1× less data outside flash dies than FG and MG, respectively.The reduction is attributed to storage-friendly execution, analysis where graph structures reside, and scheduling that leverages die-level parallelism.Source: §6.10.1 · p. 147, Figure 6.12 · p. 147
• GRN-B-S is 2.3× faster on average than GRN-B, and GRN-B-S-SCC is 2.0× faster on average than GRN-B-S.Batching, scheduling, and SCC are added successively; the full configuration includes SCC.Source: §6.10.1 · pp. 147–148, Figure 6.13 · p. 147
• With two SSDs in QS, GRAINS retains speedups of 14.2× with SSD-M and 9.4× with SSD-H.The passage notes a slight speedup decrease in this configuration as software query processing becomes relatively more significant.Source: §6.10.1 · p. 148, Figure 6.14 · p. 148
• On SSD-M (SSD-H), GRAINS provides 7.4× (4.3×) average speedup over IdealAccMem.The comparison uses GRAINS’s storage-aware design and efficient ISP/IFP operations.Source: §6.10.1 · p. 149, Figure 6.15 · p. 149
• SeGraM+GRN provides 6.2× and 9.0× average speedup over SeGraM+FG and SeGraM+MG, respectively, for alignment-based mapping.The tools are integrated with SeGraM to align candidate graph regions identified by each tool.Source: §6.10.1 · p. 149, Figure 6.17 · p. 149

6.10.2 Area and Power Overheads

• GRAINS’s on-controller units occupy 0.0025 mm^2 (0.7% of four ARM cores), and ECCLITE accounts for 99% of on-die logic area.ECCLITE occupies 0.2% of flash-chip area and fits within its power budget, as reported in.Source: §6.10.2 · p. 150
• GRAINS’s SSD-controller ISP units use two orders of magnitude lower area and 60.1× lower power than the compared state-of-the-art hardware units.The design tradeoff is that general-purpose units facilitate earlier adoption, while specialized units offer better area and power efficiency.Source: §6.10.2 · p. 150

6.10.3 Energy

• Across evaluated queries and SSDs, GRAINS reduces energy by 4.4–21.0× versus FG, 12.2–31.6× versus MG, and 3.1–20.7× versus IdealAccMem for k-mer set lookups.The analysis attributes the benefit over FG and MG to processing low-reuse data inside storage with lightweight logic and reducing execution time.Source: §6.10.3 · p. 150
• GRAINS reduces energy use through improved access patterns that require fewer DRAM accesses and IFP that avoids transferring unused or low-reuse page portions beyond flash dies.Source: §6.10.3 · p. 151

6.11 Summary

• GRAINS is the first storage-centric system designed to alleviate large genome-graph analysis I/O overhead by making pipelines storage-friendly and enabling in-storage and in-flash processing.Source: §6.11 · p. 151
• GRAINS improves performance, energy efficiency, and system cost-effectiveness for graph-based genome analysis at low area and power costs.Source: §6.11 · p. 151

6.11.1 Impact and Influence

• The authors link GRAINS’ performance and cost-efficiency gains to wider adoption and low-cost portable-device genome analysis [246, 253, 272, 291].They hope GRAINS inspires storage-centric research in other data-intensive domains critical to population-scale settings.Source: §6.11.1 · pp. 151–152

7.1.1 Data Preparation Bottleneck in Genome Sequence Analysis Accelerators

• The end-to-end evaluation includes both data preparation and genome analysis, using a state-of-the-art hardware accelerator for read mapping.The section introduces comparisons across decompression configurations, but the supplied passages do not provide their results.Source: §7.1.1 · p. 153

7.1.2 Challenges and Goal

• Keeping read sets uncompressed is inefficient because they are typically 2–40× larger, and even hot data is too large to store efficiently that way.Read sets are commonly stored compressed even when they are not archival, with decompression integrated into genome analysis software [250,294].Source: §7.1.2 · pp. 154–155
• The goal is to mitigate data preparation while achieving high performance and energy efficiency, state-of-the-art-comparable compression, and lightweight integration across analysis systems.Meeting these requirements is especially challenging in resource-constrained environments; kernel-specific acceleration does not cover end-to-end decompression and can demand substantial hardware resources.Source: §7.1.2 · p. 155

7.2. SAGE: OVERVIEW

• 32 threads saturate genomic decompression performance even on a system with eight DRAM channels, 128 cores, and 256 hardware threads.State-of-the-art genomic decompressors require random accesses to as much as 26 GB of data and high bandwidth.Source: §7.2 · p. 156

7.2 SAGe: Overview

• SAGe co-designs highly compressed genomic storage and high-performance access to mitigate data preparation, with a lightweight design for diverse genome analysis systems and sequencing technologies.Its approach is intended to support data from different sequencing technologies and species.Source: §7.2 · p. 156
• SAGe’s algorithm–architecture co-design achieves compression ratios comparable to state-of-the-art genomic-specific compressors while enabling low-latency decompression with lightweight hardware and efficient streaming accesses.The supplied overview attributes its lightweight, high-performance, energy-efficient design to this synergistic co-design.Source: §7.2 · p. 156

7.3. SAGE: DETAILED DESIGN

• SAGe’s four design aspects are lossless compression into hardware-friendly structures, lightweight decompression hardware, bandwidth-efficient data layout, and specialized application interface commands.The commands let analysis applications request data and communicate with SAGe’s hardware to decompress it into the desired format.Source: §7.3 · p. 157
• During compression, the host encodes genome sequences with SAGe’s scheme, then uses customized interface commands and data layout to facilitate efficient decompression access.Source: §7.3 · p. 157

7.3.1 Compression Algorithm and Data Structures

• SAGe stores mismatch information in streaming-decodable structures and uses read-set-specific bit widths and guide arrays to reduce size while enabling lossless reconstruction.It organizes mismatch positions, mismatch bases and types, and matching positions in three arrays; streaming access supports lightweight decompression without frequent random accesses.Source: §7.3.1 · p. 158
• SAGe optionally supports lossless quality-score compression in a separate stream, with host-CPU decompression throughput sufficient to avoid bottlenecking genome-analysis pipelines.Users can disable the feature; the separate stream reflects that quality scores lack the redundancy patterns of DNA bases.Source: §7.3.1 · p. 159

Mismatch Positions and Counts

• For mismatch positions, SAGe tunes bit-count boundaries to minimize encoded size and uses shorter variable-length codes for more frequent bit counts.The tuning search uses a histogram of required bit counts and is constrained by a small upper bound on bit widths, typically below 8 in the evaluation.Source: Mismatch Positions and Counts · p. 160
• Because larger indel blocks encompass most indel bases, SAGe stores each block’s first mismatch position and length instead of every mismatch position.Most indel blocks are length one, but larger blocks account for most indel bases.Source: Mismatch Positions and Counts · p. 161
• SAGe tunes position-array and guide-array encodings to compress mismatch positions, using separate bit counts for single-base indels and other indels.It reserves one guide-array bit to flag a single-base indel and uses eight bits to encode other indel lengths; the observed configuration fits evaluated datasets.Source: Mismatch Positions and Counts · p. 161

Mismatch Bases and Types

• Considering the top N matching positions for chimeric reads reduces the example’s mismatches from eight to three, while SAGe’s MBTA encodes mismatch bases and types compactly.For mismatch types, SAGe infers substitutions by comparing the mismatching base with the consensus; when the bases match, one bit distinguishes insertion from deletion.Source: Mismatch Bases and Types · pp. 162–163

Matching Positions

• SAGe sequentially encodes delta-coded matching positions in MPA and MPGA, using hardware-friendly structures to compress them without entropy decoding’s random lookups.Reads can be reordered by matching position, allowing consecutive reads to use few bits for their delta-encoded positions.Source: Matching Positions · pp. 163–164

Corner Cases

• SAGe marks reads with unidentified bases or terminal clips as corner cases by encoding a mismatch at position 0, then identifies them with one MBTA bit.This handles corner cases without impacting standard reads.Source: Corner Cases · p. 164

Quality Scores

• SAGe losslessly compresses quality scores as an optional separate stream and preserves their order alongside DNA bases when reads are reordered.Source: Quality Scores · p. 164
• Across evaluated read sets, only 0.03% of quality-score blocks are accessed on average (maximum 10.7%), as applications generally need scores around mismatches.Source: Quality Scores · pp. 164–165
• At up to 17% quality-score access, host-CPU decompression does not bottleneck the pipeline and is faster than mapping the full read set with an accelerator.The 17% threshold provides a safe margin for the system configuration described.Source: Quality Scores · p. 165
• SAGe’s quality-score compression uses the software compression from in lossless mode, while host-side decompression permits flexible adoption of other algorithms [460–463,466–470,472–476].Source: Quality Scores · p. 165

Components

• SAGe’s three hardware components are the Scan Unit, which finds mismatches, the Read Construction Unit, which rebuilds reads from the consensus sequence, and the Control Unit, which coordinates them.Source: Components · p. 165
• Streaming decoding lets the Scan and Read Construction Units use small registers instead of large buffers, with sequential accesses to mismatch-position arrays and the consensus sequence.Source: Components · p. 165
• SAGe sends reconstructed reads directly to analysis, which can start as output arrives; reads longer than 150 base pairs are reconstructed in 150-base-pair chunks.Source: Components · p. 166

Operations

• SAGe concurrently decodes read positions and mismatch information, reconstructs reads against the consensus sequence, and formats them as requested.On an access request, the storage unit decodes positions while the reconstruction unit decodes mismatch bases and rebuilds the full reads.Source: Operations · pp. 166–167

7.3.3 Data Layout

• SAGe’s FTL designates blocks as genomic or non-genomic, while leaving vendor-specific FTL features for other data untouched.Garbage collection groups blocks in a parallel unit and sequentially rewrites them in original logical-address order to preserve multi-plane operations.Source: §7.3.3 · p. 167
• SAGe partitions compressed genomic data across SSD channels and aligns active blocks’ page offsets to enable multi-plane reads across channels.Each channel receives a consensus-sequence partition and the compressed mismatch information for reads matched to it; writes proceed round-robin.Source: §7.3.3 · p. 167

7.3.4 Interface Commands

• SAGe adds commands to request genomic data in a desired output format and to write compressed genomic data to storage.Source: §7.3.4 · p. 167

7.4 Case Studies of SAGe’s Hardware Integration

• SAGe supports PCIe or CXL attachment, same-chip integration, and SSD-controller integration; its logic uses 2.5% of lookup tables and 0.8% of flip-flops.Streaming flash data is processed with lightweight double-buffering, avoiding buffering in the SSD’s low-bandwidth, single-channel internal DRAM.Source: §7.4 · pp. 168–169

7.5 Methodology

• The evaluation measures end-to-end data preparation and genome analysis using pigz, Spring and NanoSpring, an idealized BWT accelerator, and zero-time decompression.The compared SAGe configurations include software decompression, hardware decompression, and SSD hardware integration.Source: §7.5 · p. 169
• The genome-analysis configurations use the GEM read-mapping accelerator, and SAGeSSD integrates with an on-chip in-storage analysis system.The evaluation does not explicitly test same-chip mode 2, stating it can match mode 1 given sufficient interface bandwidth.Source: §7.5 · pp. 169–170
• SAGe is the only data-preparation configuration lightweight enough for efficient SSD implementation, enabling data preparation → ISF → read mapping without uncompressed storage or external decompression.Without SAGe, ISF would require genomic data to be stored uncompressed or decompressed outside the SSD, undermining NDP benefits.Source: §7.5 · p. 170

7.6.1 Performance

• 12.3× (8.1×), 3.9× (2.7×), and 3.0× (2.1×) average speedup over pigz, (N)Spr, and (N)SprAC, respectively, on PCIe (SATA) SSDs.End-to-end execution includes both data preparation and genome analysis; speedup is normalized to (N)Spr.Source: §7.6.1 · pp. 171–172, Figure 7.10 · p. 172
• SAGe matches 0TimeDec because it fully hides decompression overhead, while SAGeSW averages 2.3× speedup over (N)Spr but reaches up to 4.0× slowdown versus SAGe.In the pipelined I/O, decompression, and read-mapping execution, throughput depends on the slowest stage; SAGeSW decompression remains a bottleneck.Source: §7.6.1 · p. 172
• SAGe hardware provides better performance and significantly better energy reduction than SAGe software, while the software version facilitates near-term adoption.The hardware implementation is described as lightweight enough for integration with genome-analysis accelerators in resource-constrained environments.Source: §7.6.1 · p. 172
• 7.8× (2.5×) average speedups over (N)SprAC on PCIe (SATA) SSDs are achieved by SAGeSSD+ISF.SAGeSSD+ISF outperforms SAGe except when ISF filters few reads or SATA external bandwidth bottlenecks performance; in those cases, SAGe decompresses outside the SSD to avoid moving more data through the limited-bandwidth interface.Source: §7.6.1 · p. 172
• 91.3×, 29.5×, and 22.3× average data-preparation speedups over pigz, (N)Spr, and (N)SprAC, respectively, are reported on a PCIe SSD.Figure 7.11 reports data-preparation throughput normalized to pigz.Source: §7.6.1 · p. 173, Figure 7.11 · p. 173
• With more SSDs, SAGe maintains a large speedup over (N)Spr, and SAGeSSD+ISF benefits increase for RS3 and RS5 as ISF performance improves on the critical path.SAGe’s streamed data can be partitioned across SSDs for concurrent access.Source: §7.6.1 · p. 173

7.6.2 Area and Power

• At 22 nm, SAGe’s accelerators use 0.002 mm2 of area and 0.49 mW, while NAND flash read throughput bottlenecks operations.The accelerators’ throughput is already sufficient at 1 GHz because operations are limited by NAND flash reads.Source: §7.6.2 · p. 173, Table 7.1 · p. 174

7.6.3 Energy

• SAGe achieves average energy reductions of 34.0× over pigz, 16.9× over (N)Spr, and 13.0× over (N)SprAC.Execution includes data preparation and genome analysis; energy reduction is normalized to (N)Spr, with higher values better.Source: §7.6.3 · p. 174, Figure 7.13 · p. 174
• SAGe alleviates preparation-energy overhead so it no longer dominates; SAGeSW still spends substantial energy on preparation using the energy-hungry host.The energy breakdown separates data preparation from analysis.Source: §7.6.3 · p. 174

7.6.4 Compression Ratio

• For DNA bases, SAGe’s average compression ratio is 2.9× better than pigz and 4.6% lower than (N)Spr; for quality scores, it is 33% better than pigz and the same as (N)Spr.For short reads, optimizations reduce matching-position and mismatch-count data; for long reads, they reduce mismatch-position and type data, encode chimeric reads, and shrink corner-case labels.Source: §7.6.4 · pp. 175–176

7.6.5 Compression Time

• SAGe’s compression is slightly faster than (N)Spr, but genomics compressors take longer than general-purpose compressors because they must find mismatches.Finding mismatch information dominates compression time for both SAGe and (N)Spr.Source: §7.6.5 · pp. 176–177

7.6.6 Resource Requirements

• SAGe yields the largest average decompression throughput, with compression ratios higher than general-purpose decompressors and comparable to genomics-specific ones.Unlike many decompression techniques, it avoids frequent random accesses to matching patterns in large data structures, eliminating the need for costly, power-hungry compute resources and large memory capacity or bandwidth.Source: §7.6.6 · pp. 177–178

7.7 Summary

• SAGe’s lightweight co-design rapidly prepares highly compressed genomic data for analysis and integrates with a broad range of genome analysis systems.The dissertation reports improved end-to-end performance and energy efficiency versus state-of-the-art software and hardware decompression tools; it also identifies addressing data preparation as important for realizing genome-analysis acceleration.Source: §7.7 · p. 178

Putting It All Together

• The dissertation introduces four storage-centric designs for genomics and metagenomics: GenStore, MegIS, GRAINS, and SAGe.SAGe is described as compatible with adoption in distributed storage systems.Source: §7.6.1 · p. 173, Putting It All Together · p. 179
• The three storage-centric computing designs significantly reduce storage data movement and the computational burden on the rest of the system.Source: Putting It All Together · p. 179
• GenStore uses low-cost, accurate in-storage filters, while MegIS targets data movement overhead in the end-to-end metagenomic analysis pipeline.Source: Putting It All Together · p. 179
• GRAINS enables analysis on large-scale genomic and metagenomic sequence graphs in storage.Source: Putting It All Together · p. 179
• SAGe co-designs an algorithm and architecture for highly compressed storage and high-performance access to large-scale genomic sequence data.Source: Putting It All Together · p. 179
• The section motivates a unified system combining the proposed designs, discusses its design, and presents a cost-benefit analysis.Source: Putting It All Together · p. 179

8.1.1 Storage-Centric Computing on Compressed Data

• SAGe is the only data-preparation approach described as high-performance, highly compressive, and lightweight enough for seamless SSD integration with SCC designs.Its compression ratios are comparable to genomic-specific compression techniques.Source: §8.1.1 · p. 179, §8.2 · p. 180

8.1.2 Facilitating Wider Adoption

• Combining the genomics and metagenomics designs broadens task applicability and reduces area versus the sum of the individual designs by reusing common units.The stated applications include clinical diagnostics, understanding disease outbreaks, and agriculture.Source: §8.1.2 · p. 180

8.2.1 Hardware Units

• The unified system shares hardware across designs, placing SAGe either in the SSD for in-storage analysis or in the host when read sets are processed there.Host-side preparation lets smaller compressed data move from SSD to host; common hardware includes double-buffering registers.Source: §8.2.1 · p. 180

8.2.2 FTL

• Small FTL metadata for genomic and metagenomic databases, references, and compressed read sets can coexist with SAGe’s metadata in SSD-internal DRAM.An interface command can determine which FTL metadata to load at the start of each acceleration mode.Source: §8.2.2 · p. 180, §8.3 · p. 181

8.2.3 Interface Commands

• A unified command starts storage-centric acceleration, with a parameter selecting GenStore, MegIS, GRAINS, or SAGe.Each design can still use its own commands for other operations.Source: §8.2.3 · p. 181

8.3 Cost-Benefit Analysis of the Unified System

• The unified design’s SSD-controller logic occupies 0.08 mm2, or 6% of four ARM cores at 28nm; the dissertation reports performance, energy-efficiency, and cost-effectiveness benefits.Area estimation accounts for shared per-channel k-mer double-buffering registers and comparators.Source: §8.3 · p. 181
• On PCIe (SATA) SSDs, SAGe averages 12.3× (8.1×) speedup over pigz, 3.9× (2.7×) over (N)Spr, and 3.0× (2.1×) over (N)SprAC.Figure 8.1 reports end-to-end speedup for different read sets.Source: §8.3 · p. 182, Figure 8.1 · p. 183
• SAGe matches 0TimeDec performance because it fully hides decompression overhead in the execution pipeline.With I/O, decompression, and read mapping pipelined, equal performance indicates decompression is no longer the slowest stage.Source: §8.3 · pp. 182–183
• 7.8× (2.5×) average speedups over (N)SprAC on systems with PCIe (SATA) SSDs are reported for SAGeSSD+ISF.SAGeSSD+ISF outperforms SAGe except when ISF filters few reads or limited SSD external bandwidth bottlenecks performance; in those cases, SAGe decompresses data outside the SSD to avoid moving larger decompressed data through the storage interface.Source: §8.3 · p. 183
• 1.8× average and up to 9.9× slower than SAGeSSD+ISF, 0TimeDec illustrates that an idealized decompressor can be inefficient when resource demands hinder SSD integration.Even highly optimized decompression tools can miss benefits from analysis systems in resource-constrained environments if their resource requirements make them unsuitable there.Source: §8.3 · p. 183

Conclusions and Future Directions

• GenStore uses low-cost, accurate in-storage filters and hardware/software co-design to reduce genomic read-mapping data movement and computation, improving performance and energy efficiency at low cost.Its design supports varied read properties and genetic variation, and evaluation on three modern NAND flash-based SSDs found improvements over three state-of-the-art software and hardware baselines.Source: Conclusions and Future Directions · pp. 184–185
• MegIS cooperatively processes metagenomic data inside and outside storage, flexibly supporting different input datasets and analysis pipelines while outperforming three state-of-the-art tools and matching the accuracy-optimized tool’s accuracy.Its design uses an efficient pipeline between the SSD and host to coordinate their capabilities.Source: Conclusions and Future Directions · p. 185
• GRAINS enables analysis of large-scale genomic and metagenomic sequence graphs in storage, supporting major graph operations and integration into diverse analysis pipelines while improving speed and energy efficiency over state-of-the-art baselines.It uses storage-aware algorithm-architecture co-design with in-storage and in-flash processing to improve performance, energy efficiency, and cost-effectiveness.Source: Conclusions and Future Directions · p. 185
• SAGe mitigates data preparation while maintaining compression ratios comparable to genomic-specific algorithms through highly compressed storage and high-performance access of genomic sequence data.The dissertation reports that SAGe improves average end-to-end performance and energy efficiency for two state-of-the-art genome analysis accelerators compared with state-of-the-art software and hardware decompression tools.Source: Conclusions and Future Directions · p. 185, §9.1 · p. 186

9.1. FUTURE RESEARCH DIRECTIONS

• Across Chapters 4–7, the systems deliver performance and energy benefits without costly external I/O bandwidth, large DRAM capacity, or extensive computational units, while the unified system brings benefits to genomic and metagenomic analyses at low cost.SAGe achieves compression ratios comparable to state-of-the-art genomic compressors with low decompression latency, lightweight hardware, and efficient streaming; it can integrate with a broad range of genome-analysis accelerators to mitigate data-preparation bottlenecks.Source: §9.1 · p. 186

9.1.1 Expanding the Capabilities of In-Storage Filters for Genomic Data

• GenStore’s exact-match filter could be extended to identify exact-matching segments in long reads in storage, using locality-sensitive hashing to avoid moving those segments to the host.Long reads rarely match the reference end-to-end, so the existing exact-match filter cannot be adopted directly; the boundaries of matching regions are also unknown in advance.Source: §9.1.1 · pp. 186–187

Metagenomic Analysis

• MegIS could be extended to targeted metagenomic queries by adding in-storage indexes for frequently updated signatures and mechanisms to accommodate emerging variants.The proposed direction targets searches for specific species, lineages, or alleles rather than exhaustive database scans; MegIS’s KSS could make tree-based approaches more storage-friendly by turning dependent accesses into sequential streams.Source: Metagenomic Analysis · p. 187

9.1.3 Storage-Centric Computing for Other Biological Data

• Storage-centric computing could extend to transcriptomics and single-cell analysis, where growing datasets intensify data-movement overheads and require algorithm–hardware co-design.The section points to storage-aware algorithmic optimizations, in-storage filters, cooperative in-storage processing, and sequence data-aware encoding as ideas that could guide these systems.Source: §9.1.3 · p. 188

9.1.4 Storage-Centric Designs for Constructing and Updating Large-Scale Sequence Databases and Graphs

• Future storage-centric designs could support incremental updates to large sequence databases and genome graphs without expensive resources, including partial graph updates that exploit modern SSD bandwidth and parallelism.Current updates may require full reconstruction of in-storage structures, incurring time, energy, and resource overheads; GRAINS batching and scheduling and MegIS cooperative processing are proposed as foundations.Source: §9.1.4 · p. 188

9.1.5 Highly-Compressed Storage and High-Performance Access of Other Biological Data Types

• The section proposes developing efficient storage and access techniques for other emerging biological data types by extending algorithm–architecture co-design beyond genomic data.The dissertation’s approach co-designs highly compressed storage and high-performance access for large-scale genomic data.Source: §9.1.5 · p. 189

Efficiently Storing and Accessing Transcriptomic Data

• SAGe’s data-specific compression and lightweight-hardware approach could be adapted to RNA-seq and scRNA-seq to achieve high compression ratios with fast, hardware-friendly decompression.The section notes non-uniform RNA-seq coverage and rapidly growing single-cell datasets as properties to leverage when designing compression schemes.Source: Efficiently Storing and Accessing… · p. 189

Efficiently Storing and Accessing Raw Signal Genomic Data

• The section also proposes extending SAGe’s approach to raw-signal genomic data, whose high-frequency electrical time series are larger than basecalled sequences and have complex noise patterns.Raw signal genome analysis examines these signals directly without basecalling.Source: Efficiently Storing and Accessing Raw… · p. 189
• A co-designed compression and access scheme for raw signal genomic data would be especially impactful given its growing volume and increasing research interest.The identified signal properties include characteristic current levels for k-mers, temporal correlations between consecutive samples, and hardware-specific noise patterns.Source: Efficiently Storing and Accessing Raw… · pp. 189–190

9.1.6 Genomic Privacy in the Era of Storage-Centric Computing

• Storage-centric computing reduces exposure of sensitive genomic data by processing it where it resides, but practical deployment must address auditability, encryption, and multi-tenant protection.The text also proposes combining SAGe with encryption to improve preparation of encrypted genomic data.Source: §9.1.6 · p. 190

9.1.7 Facilitating Portable Genomic and Metagenomic Analysis

• Storage-centric systems could support portable genomic analysis by filtering many reads efficiently without large DRAM capacity, many processor cores, or large server nodes.The motivation is portable, integrated sequencing and analysis devices with limited compute resources and DRAM, including field and bedside settings.Source: §9.1.7 · p. 191

9.1.8 Combining Memory-Centric and Storage-Centric Computing for Efficient Biological Sequence Analysis

• Future biological sequence systems could combine memory-centric and storage-centric computing, coordinating components and placing application stages where they benefit most.The proposed partitioning factors include data reuse, access patterns, locality, available bandwidth, and arithmetic intensity.Source: §9.1.8 · p. 191

9.2. CONCLUDING REMARKS

• The concluding remarks frame storage-centric design as a way to reduce data movement and enable high-performance, energy-efficient, cost-effective analysis of larger and more diverse biological datasets.Source: §9.2 · p. 192

9.1.9 From New Technologies to New Capabilities in Health, Life Sciences, and Beyond

• Emerging computing technologies co-designed with applications could enable continuous, real-time biological analysis, richer personalized analyses, and sophisticated processing on resource-constrained devices.The discussed technologies include memory- and storage-centric computing, compute-capable memories, dense 3D integration, and tightly integrated sensing and computation.Source: §9.1.9 · p. 192

9.2 Concluding Remarks

• The dissertation identifies data movement and preparation bottlenecks, proposes GenStore, MegIS, GRAINS, and SAGe to address them, and reports improved performance, energy efficiency, and cost-efficiency.GenStore, MegIS, and GRAINS target movement overheads; SAGe co-designs algorithms and architecture for highly compressed storage and high-performance sequence access.Source: §9.2 · p. 192

A.1.1 Other Work on Storage-Centric Computing for Genomics and Metagenomics

• Beyond the thesis work, the author reports co-developing MARS, a storage-centric computing system for genomics and metagenomics.Source: §A.1.1 · p. 193
• Storage-centric designs use storage resources and capacity to reduce data-movement and computational overheads in raw-signal genome analysis, and an overview paper summarizes their benefits.The designs are described as area-efficient and low-cost.Source: §A.1.1 · p. 193

A.1.2 Other Algorithm-Architecture Co-Designs

• SeGraM supports sequence-to-graph and sequence-to-sequence mapping for short and long reads, while GenPairX minimizes paired-end read-mapping computational load and enhances memory-intensive-operation throughput.Source: §A.1.2 · pp. 193–194

A.1.3 Algorithms and Software in Genomics

• RawHash uses hash-based similarity search for real-time nanopore raw-signal analysis of large genomes [270], while Rawsamble uses hash-based search for all-vs-all raw-signal overlap detection.BLEND identifies exact-matching and highly similar seeds with one hash-value lookup, termed fuzzy seed matches [1368].Source: §A.1.3 · p. 194
• RawAlign combines seeding and alignment for accurate, fast, scalable nanopore signal mapping [1369]; TargetCall filters before basecalling to avoid wasted computation; MetaGraph-MLA performs label-guided alignment to variable-order de Bruijn graphs.The section also proposes a framework for decentralized open science.Source: §A.1.3 · p. 194

A.1.4 Architecture for Health (Arch4Health) Initiative

• The Arch4Health initiative, whose organization the author led, aims to identify computational challenges in current and future health- and life-science applications and explore how computing-system designers can address them.Its work includes motivations, vision and goals, related topics, workshops, and future outlooks.Source: §A.1.4 · p. 194

Motivation

• High-throughput biological and clinical data create opportunities in healthcare and discovery, but conventional systems face processing, data-movement, and privacy challenges.Data generation can outpace downstream analysis, data movement can dominate execution time and energy, and health applications must meet privacy and regulatory requirements.Source: Motivation · pp. 195–196

The Arch4Health Initiative

• The Arch4Health initiative seeks to identify computational challenges in health- and life-science applications and explore how computer architects and system designers can advance healthcare.The broader motivation calls for collaboration across domain experts, computer architecture, and computing-systems design.Source: The Arch4Health Initiative · p. 196
• Arch4Health fosters cross-disciplinary collaboration and welcomes work identifying computational challenges and proposing architectures, systems, and algorithms to improve performance, energy efficiency, cost-effectiveness, and privacy.Its workshops bring computer architecture and biomedical communities together for talks and research exchange.Source: The Arch4Health Initiative · pp. 196–197
• Arch4Health expands toward system software and design through Sys4Health, a workshop connecting systems and health and life sciences communities around scalable, secure, and efficient applications.Source: The Arch4Health Initiative · p. 198

A.2.1 Other Works on Storage-Centric Computing

• REIS is a high-performance, energy-efficient retrieval system with in-storage processing, while Conduit is a programmer-transparent SSD near-data-processing framework that accelerates workloads using SSD resources.Source: §A.2.1 · p. 199

A.2.2 Memory-Centric Computing and 3D Integration Technologies

• ALP reduces host–NDP inter-segment data-movement costs and supports application partitioning, while RevaMp3D designs processor cores and cache hierarchies for monolithically integrated logic and memory.A third first-author project models performance across dense 3D memory technologies and is ongoing.Source: §A.2.2 · p. 199
• The ongoing third first-author project models performance across dense 3D memory systems and integration technologies.An early version was presented at the ACM Student Research Competition at PACT 2024.Source: §A.2.2 · p. 199
• SIMDRAM supports efficient implementation of complex and user-defined operations, MATSA is an energy-efficient MRAM accelerator for time-series analysis, and IMPACT uses PiM characteristics for timing attacks and covert and side channels.Source: §A.2.2 · p. 199

A.3 Optimizing Memory and Storage Systems

• FIGARO improves system performance through fine-grained in-DRAM data relocation and caching, while CAL uses charge-level-aware look-ahead partial restoration to reduce activation and restoration latency.Source: §A.3 · p. 199

A.4. OTHER ALGORITHM-ARCHITECTURE CO-DESIGNS

• The proposed flash-level interference-aware scheduler, FLIN, aims to alleviate flash-level interference.Source: §A.4 · p. 200
• CROW provides a flexible substrate for custom in-DRAM functionality, while Venice adds a low-cost SSD controller–memory interconnect that uses path diversity to resolve conflicts.The passage also names CODIC as a low-cost design, but does not specify its mechanism.Source: §A.4 · p. 200

A.4 Other Algorithm-Architecture Co-Designs

• Ariadne is a hotness-aware, size-adaptive compressed swap scheme for mobile devices, and SMASH enables efficient indexing and storage through hardware–software cooperation.Ariadne is intended to mitigate relaunch latency and reduce CPU usage.Source: §A.4 · p. 200

1. GRAINS: Enabling High-Performance and Low-Cost Graph-Based Genome Analysis via Storage-Aware Algorithm-Architecture Co-Design, [ISCA, 2026]

• Listed research contributions include GRAINS on storage-aware graph-based genome analysis, RevaMp3D on processor and cache design for monolithic logic-memory systems, and SAGe on genome-sequence data preparation.The listed venues and years are ISCA 2026 for GRAINS, ACM TACO 2026 for RevaMp3D, and HPCA 2026 for SAGe.Source: §1 · p. 201, §3 · p. 201

B.2. SUMMARY AND INITIATIVE PAPERS LED BY THE AUTHOR

• The author’s led summary and initiative papers include a work on in-storage processing and an Architecture for Health initiative addressing computational challenges in health-related applications.The Arch4Health listing gives ICS Workshops, 2026 as its venue and year.Source: §B.2 · p. 202

B.5 Open Source Tools and Repositories

• The open-source tools list names RawHash and Rawsamble and points to the CMU-SAFARI/RawHash GitHub repository.The listing gives the repository as https://github.com/CMU-SAFARI/RawHash.Source: §B.5 · p. 206

Education

• The author’s education includes an ETH Zürich Ph.D. thesis on storage-centric designs for genomic and metagenomic analyses and an M.Sc. thesis on near-data-processing engines.The passages also list a University of Tehran B.Sc. thesis on finding critical paths under process variations.Source: Education · p. 207

Awards and Recognitions

• Listed recognitions include selection among 20 young researchers to present at the 2026 Heidelberg Laureate Forum, a 2024 ACM Student Research Competition grand-finalist placement, and the ETH Zurich Doc.Mobility Fellowship.The list also says the author is to be inducted into the ISCA Hall of Fame in 2026.Source: Awards and Recognitions · pp. 207–208

Research Experience

• Research experience spans computing for healthcare and life sciences, storage- and memory-centric computing, dense 3D integration, hardware–software co-design, and bioinformatics.The Ph.D. research assistant listing specifically includes genomics and metagenomics, processor and cache architecture for dense 3D integration, and real-time genome analysis.Source: Research Experience · pp. 208–209, PhD Research Assistant [2020 - 2026] · p. 209

PhD Research Assistant [2020 - 2026]

• The PhD research assistant work includes modeling the performance landscape of ultra-dense 3D memory systems.Source: PhD Research Assistant [2020 - 2026] · p. 209

Master’s Research Assistant [2017 - 2019]

• Master’s and undergraduate research projects included a RISC-V extension, hybrid-memory request coalescing, a camera lens-distortion core using HLS, and an educational FPGA extension board.Source: Master’s Research Assistant [2017 -… · p. 210

Thesis Publications

• Thesis publications include GRAINS for graph-based genome analysis and SAGe for mitigating genome-sequence analysis data preparation.Source: Thesis Publications · p. 210
• Thesis publications also include MegIS for in-storage metagenomic analysis and GenStore for in-storage genome-sequence analysis.Source: Thesis Publications · p. 211

Other First and Co-First Author Publications

• Other first- and co-first-author publications include Arch4Health, storage-centric designs for genomic and metagenomic analyses, RevaMp3D, and ALP.The listed titles address health-related computational challenges, monolithically integrated logic and memory, and CPU-memory data movement overheads.Source: Other First and Co-First Author… · p. 211

Co-Supervised Publications

• Co-supervised publications include work on graph-based genome analysis, homomorphically encrypted data, and REIS, an in-storage retrieval system.The graph-analysis work is listed as under submission and blinded.Source: Co-Supervised Publications · p. 212
• Other co-supervised publications cover MARS raw-signal genome analysis in storage, RawAlign, Scrooge, and TargetCall.Source: Co-Supervised Publications · p. 212

Other Publications

• Other publications include work on decentralized open-science databases, raw nanopore signal assembly, Conduit near-data processing in SSDs, and GenPairX.Source: Other Publications · p. 213
• Other publications include “Analysis of metagenomic data” [P21] and RawHash for real-time analysis of raw nanopore signals for large genomes [P26].Source: Other Publications · p. 214

Manuscripts Under Submission

• Manuscripts under submission cover graph-based genome analysis [US1] and scalable in-flash processing in solid-state drives [US2].Source: Manuscripts Under Submission · p. 216
• Other submitted manuscripts address storage-centric processing of homomorphically encrypted data [US3] and AI acceleration with hybrid-bonding-based DRAM [US4].Source: Manuscripts Under Submission · p. 216
• A fifth submitted manuscript concerns flexible data representations in processing-using-memory [US5].Source: Manuscripts Under Submission · p. 216

Conference and Workshop Talks

• The GRAINS talk presents high-performance, low-cost graph-based genome analysis via storage-aware algorithm-architecture co-design at ISCA 2026.Source: Conference and Workshop Talks · p. 216, ysis via Storage-Aware… · p. 216
• The dissertation’s storage-centric system designs are listed for talks at the MCCSys Workshop at ISCA 2026 and the Arch4Health Workshop at ICS 2026.Source: ysis via Storage-Aware… · p. 216, nomic and Metagenomic Analyses · p. 217

nomic and Metagenomic Analyses

• Research contribution titles cover storage-centric genomics, SAGe, ultra-dense 3D systems, MegIS, and GenStore.The listed titles address genomics and metagenomics, memory systems, and in-storage processing.Source: nomic and Metagenomic Analyses · p. 217, Preparation Bottleneck in Large-Scale… · p. 217, Memory Systems · p. 217

Invited Talks and Lectures

• Invited talks and lectures include topics in storage-centric genomics, metagenomics, biological sequence analysis, and ultra-dense 3D systems.The listed titles also include GenStore and high-performance, energy-efficient, cost-effective metagenomics.Source: Invited Talks and Lectures · p. 218, via Storage-Centric Systems · pp. 218–219

Teaching Experience

• The listed teaching experience includes a forthcoming ETH Zürich course on architectures and algorithms for health and life sciences.The course is listed for Fall 2026 as an upcoming semester.Source: Teaching Experience · p. 219

Teaching Assistant, ETH Zürich [Spring 2019 - Spring 2026]

• ETH Zürich teaching-assistant courses span computer architecture, digital design, genome sequencing on mobile devices, and data-centric architectures.The listed courses also include genome analysis acceleration and a seminar in computer architecture.Source: Teaching Assistant, ETH Zürich [Spring… · p. 219

Graduate Students

• Graduate-student projects listed include graph-based genome analysis, encryption and privacy, storage-centric retrieval, raw-signal genome analysis, and basecalling.The entries identify projects as ongoing or dated 2023–2026.Source: Graduate Students · pp. 220–221

Undergraduate Students

• An undergraduate student is listed for ongoing benchmarking and acceleration of single-cell analysis.The entry dates the project to 2026 onward.Source: Undergraduate Students · p. 221
• Undergraduate work spans storage-centric genomics, GRAINS graph-based genome analysis, SAGe’s genome-sequence data-preparation bottleneck, and genome-assembly data movement.The listed GRAINS and SAGe papers are associated with ISCA 2026 and HPCA, respectively.Source: Undergraduate Students · pp. 221–222

Academic and Professional Service

• The lead organizer is identified for the Architecture for Health (Arch4Health) Initiative; its listing includes first, second, and third Arch4Health workshops held with international symposia or a conference.Source: Academic and Professional Service · p. 222
• Planned events include a fourth Arch4Health workshop with MICRO 2026 and the first Sys4Health workshop with SOSP 2026.Source: Academic and Professional Service · p. 222
• Service includes program committee membership at architecture and computational-biology venues and sub-reviewing for conferences and journals.Listed committee venues include HPCA, MICRO, CAL, RECOMB, and PSB; sub-reviewing spans MICRO, ISCA, and HPCA.Source: Academic and Professional Service · p. 222
• The section also lists participation in ISCA’s Meet a Senior Student program to guide and support junior PhD students.Source: Academic and Professional Service · p. 222

Open Source Tools and Repositories

• RawHash and Rawsamble are listed with the CMU-SAFARI GitHub repository.Source: Open Source Tools and Repositories · p. 223