# Processing in Storage Class Memory
###### tags: `PIM`
## Link
* [paper](https://www.usenix.org/system/files/hotstorage20_paper_nider.pdf)
* [slides](https://www.usenix.org/system/files/hotstorage20-paper75-slides-nider.pdf)
* [video](https://2459d6dc103cb5933875-c0245c5c937c5dedcca3f1764ecc9b2f.ssl.cf2.rackcdn.com/hotstorage20/hotstorage20-paper75-video-long-nider.mp4)
* [UPMEM](https://www.hotchips.org/hc31/HC31_1.4_UPMEM.FabriceDevaux.v2_1.pdf)
## Abstract
* SCM 的商業化
* PIM 用以解決 Memory Wall
* 兩者結合並透過實驗來證實潛力
## Introduction
* Intel Optane DC Persistent Memory 在2019年提出，使用 PCM 3D-XPoint 來減少 I/O latency
* Moore's Law and Dennard scaling 的趨緩證明 CPU 不該花資源在 I/O 上，且隨著 storage density 的增加，CPU 計算速度也不夠，因此使用 PIM 結合 SCM 可以更加有效的增加 Scalability
* 傳統的 PIM 結合 DRAM 會跟 PIM 結合 SCM 不太一樣，此論文提出將簡單的 data processing and manipulation operations(e.g., compression) 移到 SCM 來做
* 同樣的運算使用 PIM 結合 DRAM 會需要 CPU DMA 傳輸 data，PIM on SCM 消除這個問題
* PIM on SCM 的好處:
* Free the Bus:
* 因為 SCM 跟 in-storage processors 緊密結合，資料不需要透過 shared bus 移動，跟 PIM on DRAM (省掉 disk or ssd -> DRAM 的 memory wall)
* Scalable Processing:
* 隨著儲存單位增加，計算能力也會線性成長
* Post-processing of Stored Data:
* PIM on SCM 可以不斷地轉換 storage 的 data，確保他的永久性
## Background
* 將 PIM 視為 memory 中嵌入式小型處理器，稱為 Data Processing Units (DPU)
* 硬體 based on UPMEM，雖然是在 DRAM 上實作，但預期狀況會相同，並加上以下特點：
* Inter-PIM Communication:
* 使用第二階層的 bus (secondary bus)，可以在 runtime 時動態調整 load balance，並彼此分享部分結果，增強 locality
* 主要缺點除了增加 bus 會更貴更耗能外，還會讓 front-end 設計更加複雜，且難以有擴展性 (scalability)
* Address Translation:
* 為了支援 virtual memory，CPU 要維持 translation table，每個 process 都有自己的 tables，這些要跟 DPU 做分享，因為 DPU 常常只能 access 到限制 range 的 physical address space，PIM 常常不會有此設計
* Core Density:
* silicon area and power consumption vs. parallelism 的 tradeoff
* 不夠多的 core 代表平行化的限制，而過多的 cores 可能原本的空間有其他用途就不能使用
* 希望可以找到正確的 core density
* Instruction Set:
* 使用原本的 ISA，programmer 不需要有任何更動(compiler, linker, debugger)
* 設計新的 ISA 可能保留 PIM 較會使用到的 instruction，讓設計較為簡單，但就需要新的 tool 跟 developer training
## Architecture and Limitations
* 使用 UPMEM 作為實驗 PIM hardware 方法，雖然是 based on DRAM，不過有許多特性與 SCM 可相容
* UPMEM DRAM 是 DDR4-compatible，可直接取代 DDR4 DIMMs
* DPUs 是 general-purpose processors
* 接下來敘述 UPMEM PIM hardware 並介紹優勢及其限制
* UPMEM 每個 chip 都會有一個 DPU，可以直接存取 DRAM memory，隨著 memory 越多 DPUs 就會越多
* DPU 計算 data 前要先利用 DMA 將資料從 DRAM copy 到 64KB 的 private SRAM，不能直接使用 DRAM
* 每個 DPU 有很多 hardware thread，不過因為使用 IMT 設計，每個 cycle 只能有一個 thread 做操作
* 因為很多的 DMA operations 可以同時處理，所以隱藏移動 data 的 latency，而因為所有 memory chips 都獨立，所以 DPUs 可以平行且獨立的處理 data
* 因為 DPUs 間沒有溝通管道，所以 host 需要很小心的處理操作的順序，因為維持同步要消耗的 cost 很高
* 因為 PIM 所能做到的較少，因此也要設計有效率的 offload functions
### Virtual Memory
* host CPU 寫一個 cache line 到 DRAM 時會一次分配給好幾個 banks 一個 byte，這原先沒問題，但 DPU 只能讀自己 bank 的資料，因此 CPU 要放置 data 給 DPU 運算時要透過 API copy 資料到 DPU 可控管的資料區，為了達到快速轉換，需要將 virtual memory pages 直接放入 application 的 address space，而因為 striping 現在是不能做到的
* 因為 DPUs 會永久的在某個地方，因此不能用傳統的 wear levelling ，用 in-place methods 解決
### Wishlist for PIM architectures
* Data Triggered Functions
* host CPU 讀取到 DPU 擁有的 memory address 就觸發 function execution
* the address 首先 registered 在 DPU as a functino target
* 當 CPU issues a memory load，會觸發 DPU 執行 function，並等待 function 執行結束並回傳結果，因為不需要昂貴的 API calls 來執行 DPU functions，也不需要多餘的機制(polling,interrupt)，就能知道結果已經好了
* 這需要 memory controller 能支援較長的執行 function 的 latency
* Concurrent Memory Access
* DPU and CPU cannot operate on the same memory rank concurrently.
* 為了要支援 producer-consumer model，當 DPU 讀取 buffer N 時，CPU 要可以讀取 N-1 的結果並寫在 buffer N+1，此項 double-buffering 需要 memory bus 的支援，現行 DDR4 是不可行的
* Mix of Memory Types
* 希望 DPU 可以存取 DRAM 跟 SCM Mixed 的記憶體，讓 DRAM 儲存暫時的資料，而 SCM 儲存壓縮過或尚未解密的資料等
* 最終希望可以動態調整兩者的比例，如果做不到，也希望可以有固定的混合比例
* Tuning For Performance
* SCM 讀取較慢，在未來實作上也會遇到速度不均的問題
## Feasibility Experiments
* Format Parsing
* Decoding stored data formats (JSON, XML, ORC, etc.) into in-memory representations is an expensive task.
* The best known CPU implementation of SIMDJSON today can only operate at 2GB/s per-core
* SIMDJSON identifies all structural bytes of a record in parallel before traversing it.
* performed an experiment to compare the overhead of format conversion when the data is stored on Intel Optane NVRAM and on HDD.
* On NVRAM, the test takes 26s with 11s (42%) of parse time.
* On HDD it takes 80s with 11s (13%) of parse time.
* 透過使用 DPUs 可以加速運算
* Storage Compression
* the compression overhead becomes higher (relative to the total execution time) as the speed of the storage device increases.
* 資料庫再做儲存時常常需要壓縮解壓縮，這會造成很大的 overhead，而透過 PIM 也可以完成此工作
* Snappy Decompression
* By using a set of test files that vary in size and compression ratio, we compiled a benchmark to measure the performance compared to a CPU
* With the largest file size, we see a speedup of nearly 4.5x using only 172 DPUs.
* With the smallest file, we see a slowdown of 100% (i.e. 2x longer than the CPU).
* both cases, the amount of available parallelism is the cause.
### Throughput
* We maximized parallelism by starting all DPUs simultaneously, and by using 16 threads concurrently in each DPU. The threads only copied data, and did not perform any additional processing.
* a total throughput of approximately 252 GB/sec.Compared to the maximum theoretical bandwidth of a single DDR4-2400 channel between the DRAM and CPU of 19 GB/sec
### Other Use Cases
## Conclusions
## Discussion Topics