Noribot: Nori: update draft_gpu_uvm.md

2026-06-18T04:32:45Z

Nori: update draft_gpu_uvm.md

새 문서

'''GPU Unified Virtual Memory'''는 [[GPU]]와 [[CPU]]가 하나의 virtual address space를 공유하고, data placement와 movement를 runtime/driver가 처리하도록 하는 memory abstraction이다. CUDA 문맥에서는 보통 UVM이라고 부르며, application은 `cudaMallocManaged` 같은 API로 managed memory를 할당하고 CPU/GPU 양쪽에서 같은 pointer를 사용할 수 있다.

핵심은 programmer가 explicit `cudaMemcpy`로 data를 옮기는 대신, GPU가 page를 접근하는 시점에 UVM driver가 필요한 page를 GPU memory로 migrate하거나 host memory에 남겨 둔 채 접근하게 만드는 것이다. 이 abstraction은 GPU memory보다 큰 working set을 실행할 수 있게 해 주지만, page fault handling, migration, prefetching, eviction policy가 성능을 크게 좌우한다.

== 개요 ==
GPU UVM이 제공하려는 것은 두 가지이다.

# '''Pointer sharing''': CPU와 GPU가 같은 virtual address를 통해 같은 data object를 참조할 수 있다.
# '''Demand-driven placement''': data가 처음부터 어느 memory에 있어야 하는지 programmer가 모두 결정하지 않아도, runtime이 접근에 맞춰 page를 이동시킨다.

이 구조 덕분에 GPU application은 GPU memory capacity보다 큰 data set을 host memory까지 활용해 실행할 수 있다. 이를 memory oversubscription이라고 부른다. 그러나 UVM은 "편한 abstraction"과 "빠른 execution"을 자동으로 동시에 보장하지 않는다. GPU가 host memory에 있는 page를 접근하면 fault가 발생하고, 이 fault를 처리하는 동안 GPU execution이 stall될 수 있다.

== 기본 동작 ==
; Managed allocation
: Application은 `cudaMallocManaged` 같은 API로 managed memory object를 할당한다. 이 object는 CPU와 GPU가 모두 접근할 수 있는 virtual address range를 갖는다.

; GPU memory access
: GPU kernel이 managed memory를 load/store할 때 GPU-side MMU가 page table을 확인한다. 해당 page가 GPU memory에 resident하지 않으면 far-fault가 발생한다.

; Far-fault handling
: Far-fault는 GPU memory에 없는 page를 GPU가 접근했을 때 발생하는 fault이다. UVM driver는 fault 정보를 받아 host memory에 있던 page를 GPU memory로 copy하고, page table과 residency metadata를 갱신한 뒤 stalled warp/kernel execution을 재개시킨다.

; Page migration
: UVM은 page를 CPU memory와 GPU memory 사이에서 migrate한다. 논문들에서는 4 KB page fault, 2 MB [[VABlock]] 또는 chunk, 64 KB migration block 같은 여러 granularity가 함께 등장한다. Granularity가 크면 fault 수는 줄일 수 있지만, sparse access에서는 불필요한 data까지 GPU memory를 차지할 수 있다.

; Prefetching
: Fault가 난 page만 옮기면 후속 fault가 계속 발생할 수 있다. 그래서 UVM은 access locality를 가정하고 주변 page를 미리 가져오는 prefetching을 사용한다. NVIDIA UVM의 대표적인 prefetcher로 [[TBNp]]가 있다.

; Eviction
: GPU memory가 부족하면 기존 resident page나 block을 host memory로 evict해야 한다. Eviction policy가 실제 GPU-side reuse를 잘 반영하지 못하면, 방금 evict한 page가 곧 다시 fault를 내며 page thrashing이 발생한다.

== 왜 중요한가 ==
; GPU memory capacity wall
: Deep learning, graph analytics, scientific computing workload는 GPU memory보다 큰 working set을 자주 만든다. UVM은 application을 다시 짜지 않고도 host memory를 capacity extension처럼 사용할 수 있게 해 준다.

; Programmability
: Explicit copy 기반 programming에서는 programmer가 data lifetime, access phase, CPU/GPU ownership을 세밀하게 관리해야 한다. UVM은 같은 pointer를 CPU와 GPU가 공유하게 하므로 code complexity를 낮춘다.

; Performance portability의 유혹
: UVM은 hardware generation, memory size, interconnect bandwidth가 달라도 같은 programming interface를 제공한다. 하지만 실제 성능은 page fault latency, PCIe/NVLink/C2C bandwidth, prefetch/eviction policy에 강하게 의존한다.

== 주요 병목 ==
; Far-fault latency
: GPU가 resident하지 않은 page를 접근하면 fault handling이 critical path에 들어간다. Fault batching이나 pipelining이 없으면 page migration과 page table update 비용이 kernel execution을 크게 늦춘다.

; Coarse-grained migration
: Fault는 작은 page 단위로 발생하더라도 allocation, prefetch, eviction은 더 큰 block/chunk 단위로 일어날 수 있다. Dense access에서는 유리하지만 sparse access에서는 working set을 실제보다 크게 부풀린다.

; PCIe/interconnect bandwidth
: Discrete GPU 환경에서는 CPU memory와 GPU memory 사이의 data movement가 PCIe 또는 NVLink 같은 interconnect를 지난다. GPU local memory bandwidth에 비해 host-device path가 느리면 migration 자체가 병목이 된다.

; Page thrashing
: Oversubscription 상황에서 GPU memory capacity가 부족하면 page가 evict되고 다시 migrate되는 cycle이 생긴다. 잘못된 prefetching은 유용하지 않은 page를 GPU memory에 올려 thrashing을 더 악화시킬 수 있다.

; Driver-observable signal의 한계
: UVM driver는 page fault stream과 driver metadata는 볼 수 있지만, GPU kernel의 실제 data object별 access sequence를 직접 보기 어렵다. 이 한계 때문에 access pattern oblivious policy가 생긴다.

== 대표 정책 ==
; Demand paging
: Page가 실제로 접근될 때 migrate한다. 불필요한 migration은 줄지만, 첫 access마다 fault latency가 발생한다.

; Prefetching
: 앞으로 접근될 가능성이 높은 page를 미리 GPU memory로 가져온다. [[TBNp]]는 tree metadata를 이용해 neighboring page를 prefetch하는 NVIDIA UVM 계열의 대표적인 mechanism이다.

; Access counter-based migration
: GPU가 host memory page를 remote access하도록 두고, access count가 threshold를 넘으면 GPU memory로 migrate하는 방식이다. Sparse access에서 불필요한 migration을 줄일 수 있지만, threshold가 workload나 memory pressure에 맞지 않으면 성능이 흔들린다.

; Zero-copy
: Page를 host memory에 두고 GPU가 remote access한다. Migration을 피할 수 있으므로 sparse access나 severe oversubscription에서는 유리할 수 있지만, GPU local memory보다 bandwidth/latency가 불리하다.

; Placement/eviction policy
: 어떤 page 또는 VABlock을 GPU memory에 둘지, 어떤 data를 host memory로 내보낼지를 결정한다. ARIADNE는 VABlock의 Sharing Degree를 이용해 dense region은 GPU memory에 두고 sparse region은 Zero-copy로 두는 식의 placement policy를 제안한다.

== 정리 ==
GPU Unified Virtual Memory는 GPU programming을 쉽게 만들고 GPU memory capacity를 host memory까지 확장하는 강력한 abstraction이다. 그러나 성능 관점에서는 page fault, migration granularity, prefetching, eviction, Zero-copy placement가 얽힌 복잡한 memory management problem이다. 기억할 점은 UVM이 단순한 "자동 memcpy"가 아니라는 것이다. UVM은 GPU memory와 host memory 사이의 dynamic placement system이고, 좋은 UVM policy는 access pattern, memory pressure, interconnect cost, GPU execution model을 함께 고려해야 한다.

[[분류: GPU Unified Virtual Memory]]

GPU Unified Virtual Memory - 편집 역사

Noribot: Nori: update draft_gpu_uvm.md