---
# System prepended metadata

title: 'Sprinkler : Maximizing Resource Utilization in Many-Chip Solid State Disks'
tags: [SSD]

---

# Sprinkler : Maximizing Resource Utilization in Many-Chip Solid State Disks
###### tags: `SSD`
###### paper origin: `HPCA ’20`
###### [paper](http://camelab.org/uploads/Main/sprinkler-HPCA-MJ.pdf)

### Introduction
Problem
* Parallelism dependency exhibited by an I/O request **access pattern**
* **Low flash-level transactional-locality** may introduce poor data access concurrency and extra idleness

### Many-Chip Solid State Disks
SSD
![](https://i.imgur.com/D3SwutV.png)
Flow
![](https://i.imgur.com/fROAHTQ.png)
#### System-Level Parallelism (SLP)
While serving an I/O request, many associated memory requests can be scattered across multiple internal resources
* Channel stripping
    After the physical addresses have been determined by FTL, the corresponding accesses can be parallelized over multiple flash controllers and channels
#### Flash-Level Parallelism (FLP)
Multiple dies can independently work without any circuit-level modification.
* Die interleaving
### I/O Scheduleing in Modern Controllers
I/O scheduling schemes in NVMHCs can be broadly classified as virtually address schedulers (VAS) and physically address schedulers (PAS) 

![](https://i.imgur.com/mnxgViR.png)

#### Virtually Address Scheduler (VAS)
Builds and commits memory requests relaying only on the virtual addresses of the I/O requests
#### Physically Address Scheduler (PAS)
PAS schedules the I/O requests by being aware of the physical addresses
*  Reorder I/O requests

##### Problem of PAS
* The total number of chips is relatively fewer than the total number of memory requests 
* There exist many requests heading to the same chip but to different internal resources

### Sprinkler
#### Resource-Driven I/O Scheduling
Sprinkler schedules memory requests based on the **physical resource information**
![](https://i.imgur.com/Ix5noJB.png)


#### FLP-Aware Memory Request Over-commitment
FARO **brings as many requests as possible** to flash controllers as early as possible
![](https://i.imgur.com/7XF49GT.png)

In certain cases, FARO might only increase the flash-level resource contention if it over-commits the memory requests without any preference. Consider...
* Overlap depth
The number of memory requests targeting different planes and dies in the same flash chip
* Connectivity
The maximum number of memory requests that belong to the same I/O request
![](https://i.imgur.com/oYHymKJ.png)

### Evaluation
#### Configuration
We evaluate five different I/O schedulers:
* VAS – Virtual address scheduler, using FIFO
* PAS – Physical address scheduler, using extra flash queues
* SPK1 – Sprinkler, using only FARO
* SPK2 – Sprinkler, using only RIOS
* SPK3 – Sprinkler, using both FARO and RIOS
#### System Performance
![](https://i.imgur.com/7ZrkBew.png)
#### Device-Level Idleness
![](https://i.imgur.com/gJfEQnP.png)
#### Time Series Analysis
![](https://i.imgur.com/2hWQZpe.png)
#### Execution Time Breakdown
![](https://i.imgur.com/nWDxMDE.png)
#### Parallelism Analysis
![](https://i.imgur.com/gtcXqrD.png)
#### Resource Utilization Analysis
![](https://i.imgur.com/tNOLTIP.png)
#### Memory Transaction Reduction Rate
![](https://i.imgur.com/BBMd4eu.png)

### Conclusions
In this paper, we propose Sprinkler, a novel device-level SSD controller, which provides at least 56.6% shorter latency and 1.8 ∼ 2.2 times better throughput than the modern SSD controllers
* Relaxes parallelism dependency by scheduling I/O requests based on internal resource layout