Adaptive Channel-Aware Garbage Collection Control for Multi-Channel SSDs

Abstract

Solid-State Drives (SSDs) have become the dominant storage medium in performance-sensitive systems due to their high throughput, reliability, and energy efficiency. However, inherent constraints in NAND flash memory—such as out-of-place writes, block-level erase operations, and data fragmentation—necessitate frequent garbage collection (GC), which can significantly degrade user I/O performance when not properly managed. This paper presents a channel-aware GC control mechanism for multi-channel SSD architectures that limits GC concurrency based on real-time storage utilization. Unlike conventional controllers that allow GC to proceed simultaneously across all channels—often leading to complete I/O stalls—our approach adaptively throttles the number of GC-active channels to preserve user responsiveness. The control logic uses a dynamic thresholding function that increases GC aggressiveness only as the SSD approaches full capacity, allowing the system to balance space reclamation with quality-of-service guarantees. We implement the proposed mechanism in an SSD simulator and evaluate its performance under a range of real-world workloads. Experimental results show that the proposed adaptive GC control significantly improves SSD responsiveness across various workloads. Across all workloads, the proposed adaptive GC control achieved an average latency improvement factor of 4.86×, demonstrating its effectiveness in mitigating GC-induced interference. Even when excluding extreme outlier cases, the method maintained an average improvement of 1.55×, with a standard deviation of 1.17, confirming its consistency and robustness across diverse workload patterns.

1. Introduction

Solid-State Drives (SSDs) have become the preferred storage medium in modern computing systems due to their low access latency, high bandwidth, and superior energy efficiency compared to traditional hard drives. Their mechanical simplicity and resilience against physical shocks further enhance their reliability, leading to widespread deployment across cloud servers, data centers, and consumer devices [1,2,3].

Despite these advantages, SSD performance and endurance depend heavily on how efficiently the underlying NAND flash memory is managed. NAND flash does not support in-place updates; instead, data must be written to a new location, and previously occupied blocks must be erased before reuse. This architectural constraint necessitates a process known as garbage collection (GC)—which consolidates valid pages and reclaims space from obsolete data [4,5]. However, GC introduces additional internal data movement and can substantially degrade user I/O performance, especially when invoked frequently under high-utilization conditions [6,7].

The challenge of performance degradation due to GC becomes particularly critical in multi-channel SSD architectures, which are designed to maximize throughput through internal parallelism. When GC is triggered across all channels simultaneously, the SSD may experience system-wide contention, resulting in prolonged latency and I/O stalls [8,9]. Especially deleting large, sequentially stored files often initiates a wave of concurrent GC events because the data is striped across channels, exacerbating performance degradation [10]. Hence, managing GC activity across channels is essential to maintaining both performance stability and predictable response times.

To address these challenges, this paper proposes a Channel-Aware Garbage Collection Control mechanism that adaptively regulates GC concurrency based on the SSD’s real-time utilization level. Rather than allowing GC to proceed independently on each channel, the proposed design dynamically limits the number of GC-active channels according to the remaining storage capacity. When sufficient free space is available, GC activity is minimized to reduce interference with user requests. Conversely, as the SSD approaches full capacity, the system gradually increases GC concurrency to maintain sufficient free space. This adaptive policy ensures efficient resource utilization and mitigates the latency spikes caused by uncontrolled GC operations.

The main contributions of this work are summarized as follows:

• We propose an adaptive channel-level GC control mechanism that dynamically regulates the number of SSD channels participating in GC based on real-time storage utilization. This enables the controller to continuously balance free-space reclamation with I/O responsiveness across varying system states.
• Rather than relying on fixed thresholds or step-based triggers, our method introduces a graceful scaling policy that increases GC concurrency smoothly in proportion to storage pressure. This prevents abrupt transitions commonly found in traditional GC strategies, which can cause latency spikes and system-wide stalls.
• The proposed scheme ensures latency stability by preventing excessive GC operations from blocking foreground I/O. Experimental results across diverse workloads demonstrate that our method consistently achieves lower average and maximum latency compared to conventional fixed-policy GC mechanisms.

The remainder of this paper is organized as follows: Section 2 reviews background concepts related to SSD architecture and garbage collection. Section 3 presents the proposed adaptive GC control mechanism in detail. Section 4 describes the experimental setup and results, and Section 5 discusses the conclusions.

2. Background

To motivate the design of our proposed garbage collection mechanism, it is essential to first understand the structural and operational characteristics of modern SSDs. This section provides foundational background in two parts. First, we present an overview of multi-channel SSD architecture, including its hierarchical memory organization and the role of channel striping in achieving high throughput. Then, we describe the mechanics of garbage collection in SSDs, its performance implications in multi-channel systems, and the rationale for our proposed channel-level GC control strategy.

2.1. Multi-Channel SSD Organization

To meet the ever-growing demand for high-speed, high-throughput storage, modern Solid-State Drives (SSDs) are architected with extensive internal parallelism. A central feature of this parallelism is the multi-channel architecture as shown in Figure 1, “SSD Controller Architecture” (adapted from Mishra and Somani [11]), which enables concurrent data access and transfer operations across multiple NAND flash memory chips. Each channel serves as an independent data path between the SSD controller and a group of NAND flash chips, functioning much like an individual lane on a highway. By employing multiple channels—commonly 4, 8, 16, or more in high-performance SSDs—storage devices can achieve massive internal bandwidth, essential for both consumer and enterprise workloads [12,13,14].

At a finer granularity, each NAND chip connected to a channel contains one or more dies, which are electrically independent subunits. Each die is further divided into planes, each of which contains arrays of blocks composed of multiple pages. The page is the smallest addressable unit for read and write operations, while the block is the smallest unit that can be erased. This hierarchical structure—channel → chip → die → plane → block → page—allows the SSD controller to exploit multiple layers of parallelism to serve I/O requests efficiently.

One of the most important mechanisms enabled by multi-channel architecture is channel striping. In this design, large data such as sequential files are split into fixed-size segments and distributed across multiple channels in a round-robin or striped fashion. This means that when a large file is written or read sequentially, different portions of the file can be accessed in parallel from separate channels. For instance, in an 8-channel SSD, a 128 KB file might be divided into eight 16 KB chunks, with each chunk written to a separate channel simultaneously. This parallel access pattern significantly boosts sequential throughput and lowers read/write latency by leveraging the available hardware concurrency.

However, while striping improves performance, it also creates dependencies: completing a large sequential read requires coordination across all involved channels. If even one channel is delayed or blocked—due to internal operations such as garbage collection—the entire read must stall until the slowest component completes. This sensitivity underscores the need for intelligent coordination and scheduling across channels, particularly in the presence of background maintenance tasks.

The multi-channel architecture thus serves as both a source of performance potential and a scheduling challenge. Understanding this hierarchy and the interaction of user and internal tasks across channels is essential for designing efficient SSD controllers, especially in workloads involving mixed read/write patterns and background garbage collection.

2.2. Garbage Collection in SSD

In NAND flash memory, in-place data updates are not possible; instead, data must be written to a new location, and the original page is marked as invalid. Over time, these invalid pages accumulate and reduce usable capacity. To reclaim this space, SSDs employ a background process known as GC. This process consists of three major steps: (1) reading the valid pages from a selected victim block, (2) copying those pages to a new location, and (3) erasing the original block to make it available for future writes as shown in Figure 2.

In single-channel SSDs, GC directly contends with user-initiated read and write requests. Multi-channel SSDs, though more parallel in architecture, still experience contention at multiple levels of the NAND hierarchy—planes, dies, and most critically, channels. If a user operation targets the same storage unit currently occupied by GC activity, the user request must wait until the GC operation is completed. This is particularly problematic for large sequential reads, where data is typically striped across all channels to maximize throughput. If even one channel is blocked due to GC, the entire read operation is delayed, causing significant increases in latency and degrading overall responsiveness.

Although some modern NAND chips support limited inter-die and inter-plane concurrency, most SSD controllers enforce serialized access at the channel level to avoid complexity and ensure timing correctness. As such, once a channel is engaged in any operation—whether a user request or a GC sub-task—no other operation can be serviced on that channel until the current one finishes. This serialization makes the channel the most critical control point for performance-sensitive scheduling decisions.

3. Proposed Garbage Collection Scheme

3.1. Conventional Garbage Collection Approaches

Conventional garbage collection (GC) mechanisms in SSDs generally follow simple and widely used design principles rather than a single standardized algorithm. In most commercial and academic SSD controllers, GC is governed by static, system-wide thresholds, such as a fixed invalid-page ratio within a block or a minimum number of free blocks available in the device. When a block’s invalid-page ratio exceeds a predetermined threshold (commonly 70–80%), it is selected as a GC victim and queued for reclamation by migrating valid pages and erasing the block [1,2,3,4]. In many designs, blocks that satisfy this threshold are simply appended to a victim-block list, which the GC module services when conditions permit.

In describing these mechanisms as “conventional,” we refer to this general class of threshold-driven, non-preemptive, and opportunistic GC behaviors that have been widely adopted in SSD controllers and used as baselines in prior research. Consistent with this, our study assumes the typical industry practice in which both GC and normal read/write operations are non-preemptive: once a NAND program, erase, or read operation begins, it runs to completion. Preempting an in-flight NAND command risks partial programming, stale metadata, and increased write amplification, and is therefore avoided in real devices.

Under these assumptions, GC is scheduled opportunistically: a GC task begins on a channel only when that channel becomes idle. If a channel is busy serving host I/O, GC waits; if the channel is free, the GC module selects the earliest-enqueued victim block for cleaning. While this threshold-triggered, idle-time, non-preemptive behavior is simple and commonly used, it does not adapt to workload dynamics or per-channel utilization patterns. As a result, GC may trigger in bursty, highly parallel waves when global free space decreases rapidly. When many channels perform GC simultaneously, user I/O—especially latency-sensitive reads—can experience noticeable delays due to channel-level contention.

The motivation for our work arises from the observation that conventional approaches typically treat GC concurrency as fixed or incidental. In many SSD controllers, once the global free-space threshold is crossed, GC may activate on all channels simultaneously, without accounting for workload intensity or per-channel load. This behavior often results in system-wide stalls and long-tail latency spikes, particularly under workloads with frequent overwrites (such as journaling and logging) or large sequential deletions. This issue is further underscored by the role of channels as the highest-level shared resource between GC and host I/O: when GC occupies a channel, all user requests mapped to that channel are delayed. In addition, SSD controllers naturally schedule work on a per-channel basis, making channel-level control strongly aligned with hardware abstractions. Managing GC concurrency at the channel granularity also avoids the substantial overhead associated with coordinating dozens or even hundreds of dies or planes. Finally, many commercial SSDs serialize operations at the channel interface due to shared-bus and timing constraints (e.g., tR, tPROG, tRBERS) [15,16], which further supports the practicality of modeling and controlling GC concurrency at the channel level.

To the best of our knowledge, no prior work dynamically adjusts the number of channels permitted to perform GC as a function of SSD usage, despite GC concurrency being a key contributor to GC-induced interference. This observation directly motivates the usage-adaptive GC scheduling scheme introduced in Section 3.2, where we regulate GC concurrency according to the device’s real-time utilization.

3.2. Channel-Aware GC Scheduling

Our proposed method introduces an adaptive, channel-aware garbage collection (GC) control scheme that dynamically regulates the number of GC-active channels based on real-time SSD utilization. Unlike conventional strategies that often initiate GC in large, simultaneous bursts, our design spreads GC activity more evenly over time, reducing the risk of system-wide contention and ensuring that sufficient channels remain available to serve user requests. The GC operations are primarily scheduled during idle periods, but the number of channels permitted to engage in GC is strictly limited by the adaptive function G(t).

At the core of this approach is a continuous control function G(t), defined below, which determines the allowable number of concurrent GC operations as a function of the SSD usage ratio. Rather than relying on a fixed concurrency limit, we employ a two-threshold policy defined by parameters θ₁ and θ₂, which mark the lower and upper bounds of storage utilization, respectively. This mechanism enables graceful scaling of GC intensity, increasing GC concurrency only as storage pressure rises, thereby maintaining a balanced trade-off between space reclamation and I/O responsiveness.

$$G\left(t\right)=\left\{\begin{array}{c}0 \mathbf{,}U\left(t\right)<{\theta }_1\\ G_{max}·{\displaystyle \frac{U\left(t\right)-{\theta }_1}{{\theta }_2-{\theta }_1}} {\mathbf{,}\theta }_1\le U\left(t\right)\le {\theta }_2 \\ G_{max} \mathbf{,}U\left(t\right)>{\theta }_2\end{array}\right.$$

where $G_{max}$ is the maximum number of concurrent GC channels allowed; $U\left(t\right)={\displaystyle \frac{S_{used}\left(t\right)}{S_{total}}}\in [0\mathbf{,}1]$ is the fraction of SSD space used at time t; ${\theta }_1$ denotes the SSD usage threshold where GC starts; ${\theta }_2$ denotes the SSD usage threshold where maximum number of concurrent GC channel is allowed; $N_{ch}$ is the total number of channels.

When the SSD is less than θ₁, no garbage collection is initiated. In this region, available free space is sufficient to absorb incoming writes without incurring performance penalties, and unnecessary GC would only add overhead. Between θ₁ ≤ U(t) < θ₂, the number of active GC channels increases linearly with SSD usage, enabling graceful scaling of GC pressure as the need for space reclamation grows. Once U(t) ≥ θ₂, full GC concurrency is permitted, maximizing cleaning throughput as the system approaches storage exhaustion. This two-threshold model provides several critical advantages over fixed or step-wise policies as follows.

In practical deployments—especially under workloads like web servers, databases (e.g., Cassandra, MySQL), or cloud storage—I/O request patterns are not smooth or uniform. They come in bursts, often alternating between heavy and light phases. If GC concurrency ramps up suddenly (e.g., from 0 to full activation when usage hits a threshold), it can collide with an incoming I/O burst, severely degrading performance. A continuous, linear ramp-up allows the system to adjust gradually in response to storage usage without disrupting ongoing I/O bursts.

GC operations share the same SSD resources—channels, buses, buffers, and so forth—as user I/O. When GC suddenly activates across many channels simultaneously, it creates a resource bottleneck for host requests, especially read operations, which may be delayed or blocked. By contrast, a smooth and predictable increase in GC concurrency supports a balanced scheduler and more stable queues, preventing these disruptive contention spikes and maintaining consistent performance for foreground I/O.

3.3. Comparison with Previous Work

A wide range of studies has explored how to improve the efficiency and performance of garbage collection (GC) in SSDs, focusing primarily on when to trigger GC, which blocks to select, or how to reduce GC interference with host I/O. In contrast, the key novelty of our work lies in treating GC channel concurrency itself as a first-class control variable and adjusting the allowed number of GC-active channels continuously according to SSD usage. Below, we compare our method with the two papers highlighted by the reviewer as well as additional representative GC-related research.

SSDKeeper [17] dynamically allocates SSD channels to host I/O streams to mitigate inter-stream conflicts and improve parallelism. Its control objective is to decide which host stream should use which channel based on workload characteristics such as sequentiality and access locality. Our work differs from their work in that we do not modify host-side channel allocation or reorganize I/O streams. Instead, we regulate how many channels are permitted to perform GC concurrently, using a continuous two-threshold control function G(t) derived from storage utilization. Host I/O continues to follow the baseline mapping, and only GC concurrency is adapted. Thus, SSDKeeper and our method operate on orthogonal dimensions:

CFIO [18] is designed for Open-Channel SSDs and focuses on issuing conflict-free host I/O operations to maximize internal parallelism. CFIO restructures and reorders I/O commands to avoid channel/die/plane conflicts, improving host request throughput. Our work does not reorder or restructure host I/O. Instead, we accept the host-request stream as provided and dynamically control the parallelism of GC operations, which are internal maintenance tasks. CFIO addresses host-level conflict avoidance, whereas our method addresses GC-induced interference. CFIO does not regulate GC concurrency, and our method does not modify host I/O scheduling, making the two approaches orthogonal.

Several studies adjust trigger thresholds or develop more sophisticated victim-selection heuristics for GC. Examples include dynamic-threshold GC, hot/cold-aware victim selection (e.g., Stable Greedy), and reinforcement learning–assisted GC decision making [19,20,21]. These schemes determine when GC should occur and which block should be reclaimed. Our approach is complementary to their algorithms as well. We do not modify victim-block selection or trigger logic. Instead, we regulate how much GC may occur in parallel through a usage-based concurrency limit. These techniques can be integrated with our method because they optimize different aspects of GC behavior.

Another line of work proposes GC schedulers that can be interrupted or preempted by urgent host reads, reducing long-tail latency. Semi-preemptive GC, unified GC–I/O schedulers, and interruptible GC approaches [22,23] adjust timing by deciding when GC should pause or resume. Our control policy operates at a higher level by limiting how many channels may run GC concurrently at any time. Preemptible GC can be used within each channel, while our G(t)-based controller globally bounds GC pressure. These approaches are therefore complementary, not alternatives.

Other works accelerate GC by enhancing intra-chip parallelism, adding dedicated copy engines, or optimizing low-level flash operations [24,25]. These techniques reduce the latency of individual GC tasks but do not reason about how many GC tasks should run simultaneously.

To the best of our knowledge, no prior work proposes a continuous, usage-dependent model for GC channel concurrency nor treats the number of GC-active channels as a tunable control variable. Our method therefore explores a dimension of GC behavior not addressed in existing studies and can coexist with many of them.

4. Experiments

4.1. Experimental Setup

To evaluate our proposed SSD management scheme, we collected workload traces from real applications running on a commercial SSD. All experiments were conducted on a Samsung T5 Portable SSD (1 TB) connected to a workstation with an Intel^® Core™ i7-9700K CPU, 32 GB RAM, and Red Hat Enterprise Linux 7.9 (kernel 3.10.0-1160).

For each workload, tracing was activated on the target SSD before launching the application under test. We then started the corresponding application—such as MySQL [26], Cassandra [27], MongoDB [28], RocksDB [29], SQLite [30], Dbench [31], or the Varmail workload model—and generated load using its appropriate benchmarking tool. Specifically, sysbench [32] was used to drive MySQL, YCSB [33] to exercise Cassandra, MongoDB and RocksDB, Filebench to run the Varmail workload, and the Phoronix Test Suite to run SQLite and Dbench. As these applications executed under load, blktrace [34]. recorded all resulting block-layer I/O events, and blkparse later translated these logs into text-based traces. When file-level semantics were required, ftrace [35] output was analyzed in parallel. This process ensured that each trace reflected authentic, application-generated storage behavior.

We developed an event-driven SSD simulator in C to evaluate our proposed GC-concurrency control mechanism under realistic, trace-driven workloads. The purpose of this simulator is not to model every firmware detail, but to accurately reproduce the timing, queuing, and channel-level scheduling interactions that determine how garbage collection competes with foreground I/O in a multi-channel SSD. Because commercial SSDs do not expose internal states such as page validity, channel occupancy, or GC progress, a simulation framework is required to isolate and measure the specific impact of concurrency control. Our model incorporates widely used SSD configuration parameters—including page size, block count, and NAND timing characteristics—drawn from prior studies on flash memory organization and garbage-collection behavior [4,36,37,38,39]. The key parameters used in our evaluation are summarized in

Table 1. Parameters of SSD configuration.

Features	Value
Number of Channels	8
Planes per Channel	4
Blocks per Plane	512
Pages per Block	128
Page Size (KB)	4

.

The parameters used in the equation for determining the maximum number of concurrent GC channels were configured as follows: ${\theta }_1$ = 0.5, ${\theta }_2$ = 0.85, $N_{ch}$ = 8, $G_{max}$ = 4 (i.e., $N_{ch}$/2). These threshold values were chosen based on empirical observations and design considerations. The lower threshold ${\theta }_1$ = 0.5 ensures that garbage collection remains completely disabled while more than half of the SSD’s capacity is still available, allowing foreground I/O performance to proceed unimpeded during light to moderate usage. The upper threshold ${\theta }_2$ = 0.85 reflects the point at which GC becomes increasingly urgent, and full concurrency is needed to prevent space exhaustion. Between these thresholds, GC intensity ramps up smoothly to balance cleaning efficiency with user responsiveness. $G_{max}$ = 4 was selected to ensure that at least half of the system’s channels remain available to service user read/write requests at any time, thereby minimizing the risk of system-wide stalls caused by GC contention.

Table 2. Delay of SSD components for one page read or write.

Delay	Value
SRAM read (μs)	12
SRAM write (μs)	12
NAND read (μs)	25
NAND write (μs)	200
NAND erase (μs)	700

outlines the latency parameters used in our SSD simulation model for page-level operations across different components, including SRAM and NAND flash memory. To determine SRAM access delay, we utilized timing data from a single-port, 16-bit SRAM implemented on a Xilinx Spartan-7 FPGA (model: xc7s100fgga676-1). The measurements were obtained using Xilinx Vivado 2021.2 design tools. For NAND flash memory timing, we referenced the Micron MT29F4G08ABADAH4 device model [40], which provides representative read and write delay specifications for modern flash memory.

4.2. Trace File Analysis

Table 3. Distribution of File Types and Metadata Access Categories in Workload Traces.

Category (%)	Cassandra	Dbench	MySQL	SQLite	MongoDB	RocksDB	Varmail
Journal	64.77	82.88	56.60	55.55	54.18	72.84	81.53
Inode	0.92	n/a	0.01	0.01	n/a	n/a	0.53
Directory	0.64	0.07	0.01	0.01	n/a	n/a	3.93
Misc. meta	0.31	n/a	n/a	n/a	n/a	n/a	0.03
Sync.-create	19.29	8.23	n/a	11.21	6.55	10.71	5.08
Sync.-append	2.66	8.62	43.38	33.22	39.25	12.28	8.64
Asynchronous	9.93	0.20	n/a	n/a	n/a	0.12	0.08

summarizes the characteristics of the workload traces collected using the methodology described in Section 4.1. These traces represent a diverse set of real-world storage environments, including database systems (MySQL, Cassandra, MongoDB, RocksDB) and file-system benchmarks (SQLite, Dbench, Varmail). Each trace captures the actual block-I/O patterns generated by its corresponding application under load, including request type distributions, access locality, and temporal burstiness.

To further characterize the nature of the workloads used in our experiments, we analyzed the types of files accessed during trace execution. Table 3 summarizes the distribution of file system entities involved in each workload. For several workloads, the proportion of certain categories is extremely small, and these categories are therefore marked as “n/a”.

To better characterize the workloads used in our experiments, we analyzed user-request patterns, as summarized in

Table 4. User-requested operation and access type distribution across workloads.

Workloads	Cassandra	Dbench	MySQL	SQLite	MongoDB	RocksDB	Varmail
Read Ratio (%)	77.48	n/a	n/a	n/a	35.32	49.34	n/a
Write Ratio (%)	19.15	93.16	100.00	91.46	60.46	48.42	95.45
Delete Ratio (%)	3.37	6.84	n/a	8.54	4.22	2.24	4.55
(a) Distribution of read, write, and delete operations.
Sequential Request (%)	56.83	13.21	9.80	18.66	18.66	9.90	9.90
Random Request (%)	43.17	86.79	90.20	81.34	81.34	90.10	90.10
(b) Overall distribution of sequential vs. random accesses.
Sequential Read (%)	63.83	n/a	n/a	n/a	26.77	10.30	n/a
Random Read(%)	36.17	n/a	n/a	n/a	73.23	89.70	n/a
(c) Access type breakdown for read operations.
Sequential Write (%)	22.96	7.63	9.80	11.08	8.27	6.48	6.79
Random Write (%)	77.04	92.37	90.20	88.92	91.73	93.52	93.21
(d) Access type breakdown for write operations.
Sequential Delete (%)	88.60	89.14	n/a	99.84	99.68	75.09	75.21
Random Delete(%)	11.40	10.86	n/a	0.16	0.32	24.91	24.79
(e) Access type breakdown for delete operations.

. This includes the proportions of read, write, and delete operations, along with their breakdown into sequential and random access types. The results reveal distinct I/O behaviors across applications—for example, some traces are dominated by sequential writes, while others involve frequent small random reads.

Table 5. Request size distribution by operation type and access pattern.

Workloads	Cassandra	Dbench	MySQL	SQLite	MongoDB	RocksDB	Varmail
Avg. Read Size (KB)	70.39	n/a	n/a	n/a	8.59	4.80	n/a
Avg Write Size (KB)	103.82	7.66	5.77	4.89	4.52	4.61	4.56
Avg. Delete Size (KB)	422.17	51.74	n/a	14.30	14.34	10.03	10.20
Avg. Seq. Read Size (KB)	108.16	n/a	n/a	n/a	13.03	12.53	n/a
Avg. Seq. Write Size (KB)	438.36	51.91	22.06	12.00	12.00	11.88	12.23
Avg. Seq. Delete Size (KB)	421.72	51.31	n/a	14.29	14.33	9.03	9.21

complements this by detailing the request-size distribution by operation type and access pattern. Together, these statistics offer a comprehensive view of workload diversity, essential for evaluating the generality and effectiveness of our proposed GC scheduling scheme. For several workloads—including Dbench, MySQL, SQLite, and Varmail—the proportion of read requests is extremely small, as reported in Table 4. Because these traces do not contain enough read operations to produce statistically meaningful latency measurements, the corresponding read-latency entries in Table 4 and Table 5 are marked as “n/a” (not applicable). This notation indicates that read-latency analysis is not meaningful for those workloads and avoids misinterpretation of incomplete or unreliable values.

4.3. Experimental Results

We conducted a series of simulations using our C-based SSD simulator to evaluate the effectiveness of the proposed adaptive GC scheduling scheme. Specifically, we measured both average and maximum read/write latencies under a variety of real-world workload traces. We conducted a series of simulations using our C-based SSD simulator to evaluate the effectiveness of the proposed adaptive GC (Garbage Collection) scheduling scheme. Specifically, we measured both average and maximum read/write latencies under a variety of real-world workload traces. To establish a meaningful comparison, we implemented three conventional GC strategies:

• Conv_0_AllCh: GC is enabled for all channels from the very beginning of SSD operation (i.e., at 0% storage utilization).
• Conv_0.7_AllCh: GC is postponed until the SSD reaches 70% storage capacity, at which point all channels may participate.
• Conv_0.7_HalfCh: This variant follows the same 70% usage threshold but introduces a concurrency constraint, allowing at most half of the channels to perform GC operations simultaneously.

These configurations allow controlled evaluation of GC trigger timing and concurrency effects, enabling a focused and fair comparison with our proposed Adaptive GC method.

Table 6. Latency comparison across GC policies. (γ: Best conventional latency/Proposed latency).

Avg. Read Latency (ms)	Cassandra	Dbench	MySQL	SQLite	MongoDB	RocksDB	Varmail
Conv_0_AllCh	427	n/a	n/a	n/a	0.6	29	n/a
Conv_0.7_AllCh	16	n/a	n/a	n/a	0.08	164	n/a
Conv_0.7_HalfCh	13	n/a	n/a	n/a	0.06	163	n/a
Proposed	0.6	n/a	n/a	n/a	0.3	9	n/a
γ	21.7	n/a	n/a	n/a	0.27	3.22	n/a
Avg. Write Latency (ms)	Cassandra	Dbench	MySQL	SQLite	MongoDB	RocksDB	Varmail
Conv_0_AllCh	22	8.79	0.64	0.53	0.5	1	1.16
Conv_0.7_AllCh	50	14.02	18.02	34.97	8.9	1	1.23
Conv_0.7_HalfCh	50	8.89	16.35	0.46	11.3	3	1.07
Proposed	21	6.15	0.44	0.44	0.4	0.84	0.91
γ	1.05	1.43	1.45	1.05	1.25	1.19	1.18
Max. Read Latency (ms)	Cassandra	Dbench	MySQL	SQLite	MongoDB	RocksDB	Varmail
Conv_0_AllCh	5123	n/a	n/a	n/a	31.6	31,390	n/a
Conv_0.7_AllCh	2342	n/a	n/a	n/a	6.9	31,391	n/a
Conv_0.7_HalfCh	2355	n/a	n/a	n/a	0.77	21,374	n/a
Proposed	460	n/a	n/a	n/a	30.4	363	n/a
γ	5.09	n/a	n/a	n/a	0.03	58.88	n/a
Max. Write Latency (ms)	Cassandra	Dbench	MySQL	SQLite	MongoDB	RocksDB	Varmail
Conv_0_AllCh	678	1020	99	35.7	39	187	234
Conv_0.7_AllCh	3711	9066	16,326	6057	10,884	187	2630
Conv_0.7_HalfCh	678	5192	14,519	651	8767	187	1038
Proposed	774	793	36	70.3	145	45	187
γ	0.88	1.29	2.75	0.51	0.27	4.16	1.25

summarizes the measured average and maximum latencies for all configurations. For each workload, we compare the proposed method against the best-performing configuration among the three conventional GC schemes (Conv_0_AllCh, Conv_0.7_AllCh, and Conv_0_7_HalfCh). The average improvement factor was 4.86×. When excluding two extreme outliers (Cassandra’s average read latency and RocksDB’s maximum read latency), the improvement factor still remained substantial with an average of 1.55× and a standard deviation of 1.17, highlighting the consistency and robustness of the proposed method across diverse workload characteristics.

For several workloads—including Dbench, MySQL, SQLite, and Varmail—the proportion of read requests is extremely small, as reported in Table 4. Because these traces do not contain enough read operations to produce statistically meaningful latency measurements, the corresponding read-latency entries in Table 6 are marked as “n/a” (not applicable). This notation indicates that read-latency analysis is not meaningful for those workloads and avoids misinterpretation of incomplete or unreliable values

The proposed GC scheme delivered particularly strong performance gains for workloads such as Cassandra and RocksDB. To understand the cause, we examined each workload’s I/O behavior. Figure 3 illustrates host I/O request patterns over time, and Figure 3a highlights Cassandra’s distinctive access pattern marked by intermittent spikes in read and write activity. These idle periods provide ideal windows for GC to operate with minimal interference, which our adaptive scheduling effectively exploits.

To analyze this effect in more detail with Cassandra workload, we examined key runtime metrics such as the host request rate, the number of GC operations executed, and the depth of pending I/O queues across the SSD system. Under the conventional GC strategy, Conv_0_AllCh, Figure 4a shows that spikes in user requests coincide with GC activity, causing sudden increases in queue depth and degraded responsiveness. This contention is particularly harmful during sequential reads, where data is striped across channels and the slowest channel dictates overall completion time. In contrast, the proposed adaptive GC method dynamically limits the number of channels engaged in GC. As illustrated in Figure 4b, this results in more evenly distributed GC activity, which smooths queue depth fluctuations and improves latency. By avoiding GC bursts and maintaining steady space reclamation, the system achieves superior responsiveness and stability.

Large sequential data is typically striped across multiple channels to maximize parallelism and throughput. While this enhances bandwidth, it also creates interdependence: a sequential read cannot be completed until all its segments are retrieved from the respective channels. When GC occupies all channels simultaneously—as is common in conventional schemes—this dependency leads to pronounced delays in sequential reads as with Cassandra workload. Our adaptive GC mechanism addresses this by throttling the number of GC-active channels based on current SSD usage. This ensures that a sufficient number of channels remain free to handle user I/O, significantly reducing the risk of system-wide stalls. As a result, sequential reads are more likely to complete without interruption, particularly under workloads with intermittent access patterns such as Cassandra. Although it remains possible that a GC-active channel may hold multiple segments of a sequential file, such worst-case overlaps are statistically rare in SSDs with high channel counts. Thus, the adaptive throttling approach not only smooths average latency but also robustly guards against extreme tail latencies, offering improved responsiveness under mixed and sequential workloads.

The MongoDB workload presented a particularly challenging case for the proposed GC scheme, showing higher latencies across all metrics compared with the best-performing conventional approaches. From the beginning of operation, MongoDB generates a continuous stream of interleaved read and write requests, with frequent delete operations overlapping write activity. Once SSD utilization exceeds roughly 70%, these deletions lead to a large number of invalid blocks and trigger intensive GC activity, as illustrated in Figure 5a. Under the Conv_0.7_AllCh configuration, this results in a sharp increase in write latency, as nearly all channels become occupied by GC tasks. However, since GC requests are prioritized ahead of user reads in this configuration, read latency remains comparatively lower despite the heavy background activity.

In contrast, the proposed adaptive GC method intentionally limits the number of channels engaged in GC at any given time. While this design successfully prevents full-channel blocking, it also means that GC extends over a longer duration. In workloads like MongoDB, where write and delete operations occur continuously, this prolonged GC overlap with user I/O increases queue depth and response times. Consequently, both read and write latencies rise as the SSD remains under sustained mixed-load pressure. Figure 5b reflects this behavior, showing how the adaptive scheme trades immediate throughput for more evenly distributed—but ultimately heavier—GC interference in continuously active workloads. This illustrates a key trade-off: by preventing all-channel GC activation, our method avoids system-wide contention, yielding significantly improved latency stability and predictability.

We also examined how the SSD’s available storage capacity evolves over time under different GC strategies, as shown in Figure 6. Figure 6a plots the number of empty blocks at each time interval, where a block is only counted as empty after its garbage collection process is fully completed. Until GC is executed, blocks selected for reclamation remain marked as occupied.

As expected, Conv_0_AllCh shows the slowest decline in storage availability because it initiates GC immediately and aggressively, reclaiming space as soon as possible. This behavior is confirmed in Figure 6b, which illustrates the number of GC executed. In contrast, the proposed adaptive GC scheme, like the other two threshold-based methods—Conv_0.7_AllCh and Conv_0.7_HalfCh—begins reclamation only after the SSD reaches a designated utilization threshold. However, the key distinction is in how GC proceeds after activation. Whereas Conv_0.7_AllCh and Conv_0.7_HalfCh exhibit steep drops in the number of empty blocks, followed by sudden surges—reflecting large bursts of simultaneous GC activity across many channels—the proposed scheme maintains a smooth, gradual decrease in available space. These abrupt oscillations in the conventional approaches result from initiating GC across all or half the channels simultaneously, leading to short-lived but intensive space reclamation events.

By contrast, the proposed adaptive method evenly distributes GC activity over time, preventing abrupt shifts and maintaining a stable, consistent pattern of space recovery. This not only aligns GC execution with actual storage pressure but also helps to avoid performance degradation caused by sudden bursts of background activity.

Overall, this behavior demonstrates a key advantage of the proposed scheme: it avoids inefficient, burst-driven GC, supports continuous background cleaning, and enables more predictable and stable SSD performance across varying workloads and usage levels.

Overall, these results highlight several strengths of the proposed scheme:

• It smoothly adapts GC intensity to usage conditions, reducing both average and tail latency.
• It avoids channel-wide stalls by limiting concurrent GC, preserving throughput for foreground tasks.
• It proves especially beneficial under burst-driven and journal-heavy workloads, where latency spikes from conventional GC methods can be severe.

These findings suggest that dynamic, usage-aware GC scheduling is essential for maintaining SSD responsiveness across diverse workloads, and that a fixed-threshold approach may be insufficient—especially in multi-channel architectures.

To validate the parameter choices used in our GC-concurrency control model, we conducted a sensitivity analysis examining how different threshold values and GC-concurrency limits affect latency and GC activity.

Table 7. Latency comparison across various ${\theta }_1$ and ${\theta }_2$ values.

Avg. Read Latency (ms)	Cassandra	Dbench	MySQL	SQLite	MongoDB	RocksDB	Varmail
${\theta }_1$ = 0.4, ${\theta }_2$ = 0.75	0.6	n/a	n/a	n/a	0.4	13	n/a
${\theta }_1$ = 0.5, ${\theta }_2$ = 0.85	0.6	n/a	n/a	n/a	0.3	9	n/a
${\theta }_1$ = 0.6, ${\theta }_2$ = 0.95	0.6	n/a	n/a	n/a	0.3	162	n/a
Avg. Write Latency (ms)	Cassandra	Dbench	MySQL	SQLite	MongoDB	RocksDB	Varmail
${\theta }_1$ = 0.4, ${\theta }_2$ = 0.75	21	6.16	0.44	0.46	0.4	0.94	0.91
${\theta }_1$ = 0.5, ${\theta }_2$ = 0.85	21	6.15	0.44	0.44	0.4	0.84	0.91
${\theta }_1$ = 0.6, ${\theta }_2$ = 0.95	21	6.11	0.43	0.44	0.4	0.94	0.91
Max. Read Latency (ms)	Cassandra	Dbench	MySQL	SQLite	MongoDB	RocksDB	Varmail
${\theta }_1$ = 0.4, ${\theta }_2$ = 0.75	460	n/a	n/a	n/a	39.5	21,374	n/a
${\theta }_1$ = 0.5, ${\theta }_2$ = 0.85	460	n/a	n/a	n/a	30.4	363	n/a
${\theta }_1$ = 0.6, ${\theta }_2$ = 0.95	460	n/a	n/a	n/a	48.6	21,368	n/a
Max. Write Latency (ms)	Cassandra	Dbench	MySQL	SQLite	MongoDB	RocksDB	Varmail
${\theta }_1$ = 0.4, ${\theta }_2$ = 0.75	832	793	42	64.4	75	187	187
${\theta }_1$ = 0.5, ${\theta }_2$ = 0.85	774	793	36	70.3	145	45	187
${\theta }_1$ = 0.6, ${\theta }_2$ = 0.95	803	767	26	50.0	53	187	187

and

Table 8. Latency comparison across various N_ch Values.

Avg. Read Latency (ms)	Cassandra	Dbench	MySQL	SQLite	MongoDB	RocksDB	Varmail
2 channels (Nch·1/4)	14.4	n/a	n/a	n/a	0.3	163	n/a
4 channels (Nch·2/4)	0.6	n/a	n/a	n/a	0.3	9	n/a
6 channels (Nch·3/4)	0.6	n/a	n/a	n/a	0.3	163	n/a
Avg. Write Latency (ms)	Cassandra	Dbench	MySQL	SQLite	MongoDB	RocksDB	Varmail
2 channels (Nch·1/4)	21	6.12	0.43	0.44	0.4	0.94	0.91
4 channels (Nch·2/4)	21	6.15	0.44	0.44	0.4	0.84	0.91
6 channels (Nch·3/4)	21	6.18	0.44	0.45	0.4	0.94	0.91
Max. Read Latency (ms)	Cassandra	Dbench	MySQL	SQLite	MongoDB	RocksDB	Varmail
2 channels (Nch·1/4)	2355	n/a	n/a	n/a	43.9	21,357	n/a
4 channels (Nch·2/4)	460	n/a	n/a	n/a	30.4	363	n/a
6 channels (Nch·3/4)	460	n/a	n/a	n/a	29.3	30,064	n/a
Max. Write Latency (ms)	Cassandra	Dbench	MySQL	SQLite	MongoDB	RocksDB	Varmail
2 channels (Nch·1/4)	772	766	26	98.3	130	187	187
4 channels (Nch·2/4)	774	793	36	70.3	145	45	187
6 channels (Nch·3/4)	736	795	42	61.6	38.6	187	187

summarize the results obtained from varying ${\theta }_1$ and ${\theta }_2$, and G_max across a broad range of configurations. These results confirm that the selected values—${\theta }_1$ = 0.5, ${\theta }_2$ = 0.85, and G_max = N_ch/2 = 4—provide the most consistent trade-off between cleaning effectiveness and user-level responsiveness.

In addition,

Table 9. Latency comparison across GC policies with 8K page size. (γ: Best conventional latency/Proposed latency).

Avg. Read Latency (ms)	Cassandra	Dbench	MySQL	SQLite	MongoDB	RocksDB	Varmail
Conv_0_AllCh	432	n/a	n/a	n/a	0.7	18	n/a
Conv_0.7_AllCh	0.4	n/a	n/a	n/a	13.8	161	n/a
Conv_0.7_HalfCh	0.4	n/a	n/a	n/a	14.5	5	n/a
Proposed	0.4	n/a	n/a	n/a	0.4	172	n/a
γ	1.0	n/a	n/a	n/a	1.75	0.03	n/a
Avg. Write Latency (ms)	Cassandra	Dbench	MySQL	SQLite	MongoDB	RocksDB	Varmail
Conv_0_AllCh	23	11.34	1.16	1.26	1.0	2.78	2.90
Conv_0.7_AllCh	22	14.02	3.24	52.43	1.3	1.90	1.92
Conv_0.7_HalfCh	21	7.06	0.70	0.85	0.7	1.90	1.92
Proposed	21	7.15	0.69	0.41	0.7	1.90	1.93
γ	1.0	0.99	1.01	2.07	1.0	1.0	0.99
Max. Read Latency (ms)	Cassandra	Dbench	MySQL	SQLite	MongoDB	RocksDB	Varmail
Conv_0_AllCh	7217	n/a	n/a	n/a	37.9	24,561	n/a
Conv_0.7_AllCh	460	n/a	n/a	n/a	3714.4	9447	n/a
Conv_0.7_HalfCh	460	n/a	n/a	n/a	3317.8	9447	n/a
Proposed	460	n/a	n/a	n/a	73.3	24,559	n/a
γ	1.0	n/a	n/a	n/a	0.52	0.38	n/a
Max. Write Latency (ms)	Cassandra	Dbench	MySQL	SQLite	MongoDB	RocksDB	Varmail
Conv_0_AllCh	680	939	64	87.7	85	194	221
Conv_0.7_AllCh	2615	9066	2883	7640.7	3276	194	194
Conv_0.7_HalfCh	678	767	94	2300.3	528	194	194
Proposed	678	767	22	43.6	163	194	194
γ	1.0	1.0	2.91	2.01	0.52	1.0	1.0

presents an evaluation using a larger NAND page size (8 KB) to examine the robustness of the proposed GC-concurrency control under different flash-geometry configurations. Increasing the page size alters the granularity of write and GC operations, which reduces the overall frequency of GC events and consequently narrows the performance gap between the proposed method and the conventional schemes. While the proposed method generally maintains stable and predictable performance across workloads, the results also reveal important workload-dependent behavior. For MongoDB, the proposed approach continues to show slightly worse performance than the best conventional configuration, consistent with the observations made under the 4 KB page size. For RocksDB, the proposed scheme clearly outperformed the conventional approaches at 4 KB, but this advantage diminishes under the 8 KB geometry, and one of the conventional configurations produces lower average write latency. This shift appears to stem from the way RocksDB’s compaction bursts interact with the coarser page granularity, which reduces GC frequency and alters the balance between GC concurrency and foreground I/O.

5. Conclusions

This paper introduced an adaptive, channel-aware garbage collection (GC) control mechanism for multi-channel SSDs that dynamically adjusts the number of GC-active channels based on real-time storage utilization. Unlike conventional controllers that permit uncoordinated GC across all channels—often causing full-channel blocking and user I/O stalls—our approach throttles GC concurrency in proportion to SSD usage. This design distributes GC activity more evenly over time, maintaining availability of channels for foreground requests and ensuring responsiveness under varying workloads.

Comprehensive evaluations using real-world workloads verified the effectiveness of the proposed method. On average, it achieved a 4.86× latency improvement over conventional schemes. The gains were especially pronounced under burst-intensive workloads, where the proposed approach reduced the average read latency from 427 ms to 0.6 ms, demonstrating its ability to suppress GC-induced contention and mitigate latency spikes effectively. While the method substantially enhances latency stability and responsiveness, it also introduces a trade-off: in sustained, high-intensity mixed I/O workloads such as MongoDB, the longer duration of moderated GC activity can lead to slightly higher write latency compared with more aggressive conventional schemes. This increase reflects a deliberate compromise to prevent channel-wide stalls and maintain predictable performance under heavy load.

Further analysis using a larger NAND page size (8 KB) showed that geometric scaling can influence the relative differences between GC strategies. Although the proposed method remained consistently stable across workloads, the performance gap between our approach and the best conventional scheme narrowed for some workloads, and for RocksDB the advantage observed under the 4 KB geometry diminished under the 8 KB configuration. This indicates that page size and related geometry parameters can shift the balance between GC frequency and foreground I/O and suggests that fully optimal concurrency-control parameters may benefit from adaptive tuning as flash geometry changes.

These results underscore the importance of dynamically regulating GC concurrency—particularly in SSDs with increasing parallelism and higher channel counts. By adapting GC intensity to real-time storage pressure, the proposed method offers a scalable and practical solution for latency-stable SSD management. Future work may explore combining this mechanism with advanced GC techniques, wear-leveling strategies, and I/O schedulers, as well as extending the framework to storage-class memory systems. In addition, validating the approach within publicly available SSD simulation environments such as SSDsim [41] and FEMU [42] remains an important next step, as these platforms provide richer flash-translation-layer designs and full-stack execution contexts that can further strengthen the realism and reproducibility of the evaluation.