[논문 리뷰] BaM

GPU-Initiated On-Demand High-Throughput Storage Access in the BaM System Architecture

---

Abstract

기존 GPU가 data를 가져오는 방법은 CPU 메모리에 존재하는 data를 받아서 사용했다. Data 크기가 커짐에 따라서 DRAM 메모리뿐만 아니라 NAND까지 사용하게 되었다. 하지만 기존 방식은 coarse-grained 방법으로 데이터를 전송했으며 이는 I/O amplification 문제를 야기한다. 이를 해결하고자 GPU orchestrate 방식의 BaM을 제안한다.

 

---

Introduction

AI model이 커지고, Dataset도 커지면서 Memory 부족 문제가 더욱 심해졌다. 이를 해결하기 위해 사람들은 두 가지 방법을 사용했는데,

1. GPU 개수를 늘려서 용량 확보
2. CPU의 SSD를 사용하여 CPU orchestration을 통해 용량 확보

1번의 경우 가격이 비싸고, 2번의 경우 CPU가 bottleneck이 되는 경우가 있으며, data-dependent하고 sparsity 문제의 경우 coarse-grained 한 방법의 proactive tiling이 I/O amplification을 야기한다는 문제가 있었다. 즉, 불필요한 데이터까지 한 번에 많이 가져오는 문제이다. 이를 해결하기 위한 BaM은 다음과 같은 contribution을 가진다.

1. Storage에 있는 data를 on-demand access를 할 수 있다.
2. SQ/CQ를 이용한 high-throughput & fine-grained access를 보장한다.
3. Software caching을 통해서 high-throughput을 보장한다
4. Massive storage data에 대해서 prototype으로 성능 평가를 하였다.

---

BaM System and Architecture

BaM의 목표는 storage 접근에 대해서 1. on-demand 2. fing-grained 3. high-throughput access를 제공하는 것이다. 이를 제공하기 위해 아래 그림 1에서 보이듯, I/O queue를 GPU memory에 두었고, storage에 대한 doorbell register에 mapping 된 address를 GPU memory에 두었다.

3 Challenges

(1) GPU는 massive parallelsim을 가지고 있기 때문에 SSD의 significant latency에 대해 throughput을 만족시켜야 한다.

(2) SSD의 low bandwidth와 GPU의 limited memory capacity를 적절히 최대한 활용해야 한다.

(3) 기존 GPU kernel은 SSD를 접근하는 것을 기반으로 만들어진 것이 아니기 때문에 user가 사용하기 편한 API를 제공해야 한다.

BaM System Overview

 

그림 2를 통해 전반적인 BaM System에 대해 설명하겠다. (1) array-like API를 제공하여 thread ID를 이용한 접근이 가능하도록 하였다. (2) offset(cache line)을 계산하고 (3) coalescer를 통해서 같은 cache line에 접근하는 것들을 coalescing한다. (4) cache에서 hit이 되면 데이터를 반환하고, miss가 나면 I/O stack에 들어가게 된다. (5) I/O request를 (6) submission queue에 넣고, (7) storage controller가 completion queue에 넣어줄 때까지 기다린다. (A) Doorbell register를 update 하고 (B) stroage controller가 SQ entrie들을 fetch 한다. (C) CMD를 처리하고 (D) SSD의 data를 GPU memory에 전송한다. (E) 마지막으로 Completion Queue에 Post 한다. (8) 이후 cache state를 업데이트하고 (9) SQ/CQ head도 업데이트한다.

 

Comparison With the CPU-Centric Approaches

 

기존 Proactive tiling CPU-centric apporach와 비교하였을 때 3가지 이점을 가진다.

 

1. GPU-GPU synchronization overhead를 줄일 수 있다.

2. I/O amplification overhead를 줄일 수 있다.

3. programmer가 proactive tiling을 위해 드는 effort를 줄일 수 있다.

 

BaM Software Cache

기존의 OS-kernel-model memory management는 상당히 큰 critical section을 포함하고 있다. 특히 GPU와 같은 multi-threaded implementation에서는 상당한 성능 저하가 일어난다. 이를 해결하기 위해 Software Caching을 하였다.

이를 통해서 Memory Management 문제도 해결하고, concurrent access가 발생했을 때, warp coalescing도 지원하게 하였다.

---

Evaluation

 

 

BaM과 Target system을 비교하였다. Target System은 충분한 CPU memory가 있다고 가정한 system이다. 이때 SSD가 1개일 때는 충분히 throughput을 만족시키지 못해 성능 저하가 발생하지만, 4개 SSD를 사용하면서 throughput이 올라가 성능이 더 높아진다.

---

 

Conclusion

BaM은 GPU-orchestrated 시스템으로 high-throughput, fine-grained storage access를 가능하게 했으며, I/O amplification problem을 해결했다.

 

해당 논문은 NVIDIA에서 발표한 논문으로 GPU와 SSD 사이의 direct access를 가능하게 했다. 실제 Prototype과 API를 제공함으로써 실현 가능성을 보였고, 실제로 GPU에서 SSD 접근 시 생기는 많은 문제들을 해결했다.