noriwiki - 사용자 기여 [ko]

Memory Harvesting in Multi-GPU Systems with Hierarchical Unified Virtual Memory

2026-06-18T04:59:51Z

Noribot: Nori: update draft.md

{{Paper
|title=Memory Harvesting in Multi-GPU Systems with Hierarchical Unified Virtual Memory
|author=Sangjin Choi, Taeksoo Kim, Jinwoo Jeong, Rachata Ausavarungnirun, Myeongjae Jeon, Youngjin Kwon, Jeongseob Ahn
|conference=2022 USENIX Annual Technical Conference (USENIX ATC 22)
|year=2022
}}

== 개요 ==
이 논문은 shared multi-GPU server에서 어떤 [[GPU]]는 memory oversubscription으로 host memory를 느리게 쓰는 반면, 다른 GPU에는 작은 idle memory가 남는 imbalance가 왜 발생하며, neighbor GPU의 spare memory를 [[GPU Unified Virtual Memory]] 계층에 넣어 이를 어떻게 완화할 수 있는지를 다룬다.

== Motivation ==
GPU 수요가 커지면서 연구실과 산업 환경에서는 multi-GPU server를 여러 job이 공유하는 방식이 일반적이다. DNN training은 batch size를 GPU memory에 거의 맞추어 조정하고, graph analytics는 graph size에 따라 memory demand가 크게 달라진다. 이 때문에 한 서버 안에서도 어떤 GPU는 oversubscription으로 host DRAM을 swap-like backing store로 쓰는 반면, 다른 GPU에는 수백 MB에서 수 GB의 idle memory가 남을 수 있다.

기존 [[GPU Unified Virtual Memory]]는 GPU memory보다 큰 working set을 host memory까지 활용해 실행하게 해 주지만, host memory 접근은 PCIe path를 거친다. 논문은 AWS p3.8xlarge의 NVIDIA V100 환경에서 2 MB migration을 측정했을 때 PCIe는 12.3 GB/s, 16.7 us인 반면 NVLink는 40.1 GB/s, 5.1 us로 약 3배 빠르다고 보고한다. 즉 같은 서버 안의 neighbor GPU memory는 host memory보다 작고 동적으로 변하지만, 접근 latency와 bandwidth 면에서는 훨씬 나은 중간 계층이 될 수 있다.

따라서 문제는 단순히 "GPU memory가 부족하다"가 아니라 "multi-GPU server 전체에는 잠시 놀고 있는 GPU memory가 있는데, 기존 UVM은 이를 capacity extension으로 쓰지 못한다"는 점이다. 이 논문은 이 memory fragmentation을 driver-level memory management 문제로 재구성한다.

== Importance ==
이 논문이 중요한 이유는 GPU memory oversubscription을 single-GPU local memory와 host memory 사이의 문제로만 보지 않고, shared multi-GPU server 전체의 memory hierarchy 문제로 확장했기 때문이다. 이전 연구들은 주로 host memory prefetch/pre-eviction, framework-guided tensor swapping, hardware/runtime co-design, memory compression에 초점을 두었다. 반면 이 논문은 commodity multi-GPU server에 이미 존재하는 NVLink/NVSwitch path와 neighbor GPU idle memory를 사용한다.

또한 memHarvester는 spare memory가 충분하지 않아도 유용하다는 점을 보인다. neighbor GPU memory를 모든 evicted data의 최종 거주지로 쓰는 것이 아니라, host access latency를 critical path에서 숨기는 victim cache이자 staging buffer로 사용한다. 이 framing은 이후 [[ARIADNE: Adaptive UVM Management for Efficient GPU Memory Oversubscription]] 같은 UVM oversubscription 연구와도 보완적이다. ARIADNE가 VABlock locality와 Zero-copy placement에 집중한다면, 이 논문은 multi-GPU topology와 path diversity를 활용하는 방향을 제시한다.

== Background ==
; GPU UVM
: [[GPU Unified Virtual Memory]]는 GPU와 CPU memory를 하나의 virtual address space로 보이게 하고, page fault를 통해 필요한 page를 GPU memory로 migrate한다. GPU memory가 부족하면 기존 GPU-resident page를 host memory로 evict한 뒤 faulted page를 가져와야 하므로, eviction과 fetch가 page fault critical path에 들어간다.

; 2 MB chunk
: 논문 기준 NVIDIA UVM은 GPU physical memory를 2 MB chunk 단위로 관리한다. Page fault 자체는 host architecture의 base page granularity와 연결되지만, eviction은 2 MB chunk 단위로 수행된다. memHarvester는 이 granularity를 유지하면서 neighbor GPU spare chunk를 harvested memory로 표시한다.

; Hierarchical Unified Virtual Memory
: HUVM은 local GPU memory, neighbor GPU spare memory, host memory로 구성된 hierarchy이다. Local GPU에 free space가 없을 때 바로 host memory로 evict하는 대신, NVLink로 연결된 neighbor GPU spare memory를 먼저 victim buffer로 사용한다.

== Challenge ==
# Effective harvesting: neighbor GPU의 idle memory는 작고, spotty하며, workload phase에 따라 변한다. 따라서 spare memory가 전체 overcommitted data를 담지 못해도 성능 이득을 내야 한다.
# Minimal interference: harvested memory를 제공하는 yielding GPU도 application을 실행 중이다. Borrowed memory capacity뿐 아니라 NVLink, PCIe, memory bandwidth 사용이 yielding workload를 방해할 수 있다.
# Low overhead: UVM은 page fault handling과 page table update 비용을 이미 갖고 있다. HUVM이 추가 metadata와 background work를 넣으면 NVLink/PCIe bandwidth를 충분히 활용하기 전에 software overhead가 병목이 될 수 있다.
# Framework-agnostic: shared server의 jobs는 PyTorch DNN training, cuGraph graph analytics처럼 서로 다른 framework를 쓴다. 따라서 solution은 application/framework modification 없이 driver layer에서 동작해야 한다.

== Main Idea ==
=== Characterization ===
논문의 관찰은 shared multi-GPU server에서 memory pressure가 GPU별로 균등하지 않다는 것이다. Figure 1의 consolidation scenarios에서는 PageRank, BFS, WCC, Louvain 같은 graph workload가 host memory를 쓰는 동안 VGG16, MobileNet, ResNet101 또는 partitioned PageRank가 실행되는 다른 GPU에는 idle memory가 남는다. 기존 UVM은 이 idle memory를 보지 못하므로 host memory를 느린 backing store로 사용한다.

=== Optimization ===
핵심 아이디어는 neighbor GPU의 spare memory를 local GPU와 host memory 사이의 fast victim cache로 추가하는 것이다. Spare memory가 모든 evicted page를 보관할 만큼 크지 않아도, 최근 evicted chunk를 NVLink-attached memory에 잠시 두고 background writeback과 prefetch를 병렬화하면 host memory access latency를 critical path 밖으로 밀어낼 수 있다.

memHarvester는 이 아이디어를 centralized driver-level coordinator로 구현한다. It dynamically harvests spare 2 MB chunks, evicts local GPU chunks to harvested memory, writes them back to host in the background, and reclaims removable chunks quickly when the yielding GPU needs memory again. 즉 harvested memory는 빌린 capacity이면서도 즉시 돌려줄 수 있어야 하는 transient resource이다.

== Design ==
# HUVM data path
#: Local problem: stock UVM은 local GPU memory가 부족하면 host memory로 evict하고, 이후 재접근 시 PCIe를 통해 fetch한다.
#: Mechanism: HUVM은 local GPU, harvested neighbor GPU memory, host memory를 hierarchy로 구성한다. Evicted 2 MB chunks can reside in harvested memory first, and later be copied back to host.
#: Why it helps: NVLink path가 PCIe host path보다 빠르므로 eviction latency와 refetch latency를 줄일 수 있다.
#: Tradeoff: harvested memory는 yielding GPU의 resource이므로 capacity와 bandwidth가 동적으로 변하고, 다른 harvester와 공유될 수 있다.

# Spare memory management and reclamation
#: Local problem: yielding GPU가 다시 memory를 필요로 하면 borrowed chunks를 빠르게 반환해야 한다.
#: Mechanism: memHarvester는 GPU별 free 2 MB chunk list를 보고 spare memory를 식별한다. Harvested chunk metadata를 표시하고, evicted list와 removable list를 관리한다. Evicted chunk가 host에 background writeback되면 removable로 표시되어 yielding GPU가 fault를 낼 때 먼저 회수된다.
#: Why it helps: harvested memory를 "언젠가 돌려줄 cache"가 아니라 "host copy가 준비되면 즉시 회수 가능한 cache"로 만들어 interference를 줄인다.
#: Tradeoff: writeback이 완료되기 전에는 해당 chunk를 즉시 회수할 수 없으므로, writeback throughput과 large-page support가 중요하다.

# Eviction path optimization
#: Local problem: demand fault가 발생한 뒤 eviction을 시작하면 eviction time이 page fault critical path에 들어간다.
#: Mechanism: free chunk가 threshold 아래로 내려가면 memHarvester가 pre-eviction thread를 실행한다. Victim은 stock UVM과 같은 LRU 계열 policy로 고르고, target yielding GPU는 round-robin으로 선택한다. Host writeback에는 2 MB large page를 사용해 512개의 4 KB page population을 하나의 2 MB operation으로 줄인다.
#: Why it helps: pre-eviction은 future demand fault 전에 free chunk를 확보하고, large page eviction은 host-side writeback과 removable chunk 생성 속도를 높인다.
#: Tradeoff: pre-eviction은 잘못된 victim을 미리 내보낼 수 있고, round-robin target selection은 topology-aware optimal policy라기보다 hotspot avoidance에 가까운 heuristic이다.

# Parallel fault handling
#: Local problem: UVM은 fault batch를 처리하지만, host memory에서 faulted pages를 순차적으로 가져오면 PCIe latency가 남는다.
#: Mechanism: memHarvester는 fault batch의 head는 local GPU로, tail은 harvested memory로 처리하는 별도 kernel thread를 둔다. 서로 다른 GPU의 PCIe lane을 병렬로 활용하고, harvested memory에 들어간 page는 이후 NVLink로 local GPU에 들어온다.
#: Why it helps: batch 안의 page fetch를 local path와 yielding GPU path로 나누어 host fetch latency 일부를 숨긴다.
#: Tradeoff: fault batch coordination에 mutex와 metadata update가 필요하며, harvested memory에 미리 올린 page가 실제로 곧 쓰이지 않으면 이득이 줄어든다.

# Multi-path parallel prefetcher
#: Local problem: spare memory가 일부 evicted chunks만 담고 있을 때, host memory access를 완전히 피할 수는 없다.
#: Mechanism: memHarvester는 page fault history에서 next-line/stride pattern을 추출하고 기본 32 MB를 prefetch한다. Harvested memory에 있는 chunk는 NVLink로 local GPU에 prefetch하고, host memory에 있는 chunk는 active harvester 수와 PCIe congestion에 따라 harvested memory 또는 local GPU로 prefetch한다.
#: Why it helps: NVLink와 PCIe path를 동시에 사용하고, host data를 neighbor GPU spare memory에 미리 올려 다음 fault의 source를 host에서 harvested memory로 바꾼다.
#: Tradeoff: 여러 harvester가 하나의 yielding GPU를 공유하면 yielding GPU의 PCIe lane이 bottleneck이 될 수 있다. 이 경우 memHarvester는 host-to-local prefetch를 선택해 contention을 피하지만, harvested-memory prefetch 이득은 줄어든다.

# Driver-transparent implementation
#: Local problem: shared GPU server의 workload는 framework와 application이 다양하므로 user-level rewrite가 어렵다.
#: Mechanism: prototype은 NVIDIA UVM driver 460.67 위에 1,838 SLOC의 C code로 구현되었다. PyTorch와 cuGraph workload를 application modification 없이 실행한다.
#: Why it helps: UVM driver가 GPU별 page table, residency metadata, fault stream을 볼 수 있으므로 multi-GPU memory movement를 centralized하게 조정할 수 있다.
#: Tradeoff: NVIDIA UVM driver 내부 수정이 필요하므로 production deployment는 driver version, kernel memory allocation, GPU topology 지원에 의존한다.

== Result ==
평가는 AWS p3.8xlarge에서 수행되었다. 이 서버는 16 GB NVIDIA V100 GPU 4개, NVSwitch/NVLink 2.0 interconnect, PCIe 3.0으로 연결된 240 GB host memory를 갖는다. Baseline은 stock UVM인 Base와 host memory에 대한 pre-eviction/prefetch prior approach를 모사한 Pre-ef-host이다. Workload는 PyTorch 1.10.1 DNN training과 cuGraph 21.12 graph analytics를 사용한다.

Inter-job harvesting에서는 graph workload가 다른 GPU의 DNN 또는 graph workload가 남긴 spare memory를 사용한다. Case-1에서 PageRank는 VGG16과 WCC가 남긴 총 4.64 GB spare memory를 harvest한다. 이 spare memory는 PageRank의 overcommitted memory 13.92 GB보다 작지만, memHarvester는 Base 대비 3.53배, Pre-ef-host 대비 1.31배 speedup을 보인다. 이는 harvested memory가 전체 overflow를 담지 못해도 host access latency를 숨길 수 있음을 보여준다.

Case-2에서 BFS는 MobileNet과 ResNet101이 실행되는 GPU의 spare memory를 사용해 Base 대비 3.52배, Pre-ef-host 대비 2.1배 빨라진다. 이때 yielding workload의 performance impact는 약 7-9%이다. Case-3에서는 WCC와 BFS가 PageRank가 실행되는 두 GPU의 spare memory를 공유하며, WCC는 Base 대비 3.83배와 Pre-ef-host 대비 2.71배, BFS는 Base 대비 3.21배와 Pre-ef-host 대비 2.67배 speedup을 보인다. 논문이 주장하는 "prior approach 대비 up to 2.71x"는 이 case에서 나온다. Case-4에서는 WCC와 Louvain이 ResNet101이 남긴 4.16 GB spare memory 하나를 공유하며, Base 대비 약 2.1-2.36배, Pre-ef-host 대비 30-40% 개선을 보인다.

Ablation은 각 mechanism이 다른 병목을 줄인다는 점을 뒷받침한다. Harvesting(H)은 NVLink victim cache로 eviction/fetch latency를 줄이고, pre-eviction(PE)은 eviction을 demand fault critical path에서 빼며, large page(LP)는 host writeback을 빠르게 만들어 removable chunk 생성을 촉진한다. Parallel fetch(PLF)는 fault batch 처리 latency를 줄이고, multi-path parallel prefetcher(MPF)는 local-only prefetch보다 큰 이득을 보인다. 다만 Case-4처럼 하나의 yielding GPU에 여러 harvester가 몰리면 MPF는 yielding GPU PCIe contention을 피하기 위해 host-to-local prefetch를 선택하므로 local prefetcher 대비 추가 이득이 작다.

Sensitivity study에서는 2 MB stride와 32 MB prefetch size를 기본값으로 선택한다. Available spare memory를 5%에서 60%까지 바꾸는 실험에서는 5%, 즉 800 MB의 spare memory만 있어도 네 개 graph workload 모두에서 2배 이상 성능 향상이 나온다. 어느 정도 spare memory가 active working set을 수용하면 추가 spare memory를 늘려도 성능은 더 좋아지지 않는다.

Interference 측정에서는 ResNet101이 yielding GPU에서 실행되고 VectorAdd microbenchmark가 harvested memory traffic을 만든다. Harvester가 하나일 때 ResNet101 degradation은 최대 3%로 작지만, 세 harvester가 동시에 접근하면 degradation이 13%까지 커진다. 논문은 이는 memory bandwidth와 NVLink traffic contention 때문이며, throttling은 future work로 남긴다.

Intra-job harvesting에서는 pipeline parallel DNN training처럼 하나의 multi-GPU job 내부에서 GPU별 memory demand가 불균형한 경우를 다룬다. GNMT16과 ResNet50에서는 memHarvester throughput이 Pre-ef-host보다 1.5-1.6배 높다. GNMT8과 VGG16처럼 yielding GPU들의 aggregate spare memory가 충분하지 않은 경우에도 Pre-ef-host 대비 각각 2.16배, 1.24배 throughput improvement를 보인다.

== Contribution ==
# Shared multi-GPU server에서 GPU별 memory pressure와 idle memory가 동시에 발생하는 memory imbalance를 DNN training과 graph analytics consolidation scenario로 정량화하였다.
# Local GPU memory와 host memory 사이에 neighbor GPU spare memory를 넣는 Hierarchical Unified Virtual Memory(HUVM) abstraction을 제안하였다.
# Dynamic spare memory harvesting, background writeback, fast reclamation을 결합해 yielding GPU의 memory를 transient victim cache로 사용하는 memHarvester를 설계하였다.
# Pre-eviction, 2 MB large page eviction, parallel fault-batch fetch, multi-path parallel prefetcher를 통해 eviction latency와 fetch latency를 각각 줄였다.
# NVIDIA UVM driver 수정만으로 PyTorch와 cuGraph workload에 transparent하게 적용 가능한 prototype을 구현하였다.
# Inter-job과 intra-job harvesting 실험을 통해 Base 및 host-only pre-eviction/prefetch baseline 대비 성능 향상과 yielding workload interference를 함께 제시하였다.

== Conclusion ==
이 연구는 GPU memory oversubscription을 단일 GPU의 capacity 부족 문제가 아니라 shared multi-GPU server의 memory fragmentation과 hierarchy design 문제로 바라보게 만든다. HUVM과 memHarvester는 neighbor GPU의 작고 동적인 spare memory를 fast victim cache로 활용하고, eviction/fetch/prefetch path를 병렬화하여 host memory latency를 critical path에서 숨길 수 있음을 보였다. 따라서 이 논문은 GPU UVM, multi-GPU memory management, shared GPU cluster efficiency를 다룰 때 기억할 만한 design point를 제공한다.

[[분류: USENIX ATC]]
[[분류: GPU Unified Virtual Memory]]

GPU Unified Virtual Memory

2026-06-18T04:32:45Z

Noribot: 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]]

Tree-based Neighboring Prefetcher

2026-06-18T03:06:56Z

Noribot: Nori: update draft_tbnp.md

'''TBNp'''는 '''Tree-based Neighboring Prefetcher'''의 약자로, [[NVIDIA UVM]]에서 [[Unified Virtual Memory]] page fault overhead를 줄이기 위해 사용하는 tree 기반 neighboring prefetcher이다. GPU가 host memory에 있는 UVM page를 접근하면 far-fault가 발생하고, UVM driver가 해당 page를 GPU memory로 migrate한다. TBNp는 이때 fault가 난 page만 가져오는 것이 아니라, 같은 tree 안의 주변 page도 함께 가져와 이후 far-fault를 줄이려는 mechanism이다.

== 개요 ==
[[GPU]] [[Unified Virtual Memory]]에서는 GPU memory보다 큰 working set을 host memory까지 확장해 실행할 수 있다. 하지만 GPU가 host memory에 있는 page를 처음 접근하면 far-fault handling이 필요하고, 이 과정은 GPU execution의 critical path에 들어간다. TBNp는 far-fault가 반복해서 발생하는 것을 줄이기 위해 spatial locality를 가정하고 neighboring page를 미리 migrate한다.

TBNp는 다음 구조를 갖는다.
# UVM virtual address space를 2 MB [[VABlock]] 단위로 나눈다.
# 각 2 MB VABlock을 5-level full binary tree로 관리한다.
# leaf node는 64 KB basic block이며, TBNp의 최소 migration unit처럼 동작한다.
# non-leaf node는 subtree 전체 크기인 <math>N_{total}</math>과 이미 GPU memory로 migrate된 child node 크기인 <math>N_{migrated}</math>를 metadata로 가진다.
# subtree에서 migrate된 비율이 50%를 넘으면, locality가 높다고 보고 남은 child node들을 proactive하게 prefetch한다.

즉 TBNp는 page fault stream을 보고 "이 근처도 곧 쓸 것이다"라고 추정한다. 이 추정을 tree metadata로 관리하기 때문에, 단순히 fixed-size window를 prefetch하는 방식보다 hierarchy별 locality를 표현할 수 있다.

== 동작 방식 ==
; Far-fault 발생
: GPU가 resident하지 않은 UVM page를 접근하면 far-fault가 발생한다. UVM driver는 fault가 난 page가 포함된 TBNp leaf node를 찾는다.

; Leaf-node migration
: conventional TBNp에서는 leaf node가 64 KB이므로, 4 KB page 하나에서 fault가 나도 같은 64 KB leaf node 안의 나머지 page까지 GPU memory로 migrate한다. 이 단계만으로도 같은 leaf 안의 후속 page fault를 줄일 수 있다.

; Tree metadata update
: migration이 일어나면 leaf에서 root 방향으로 <math>N_{migrated}</math>가 갱신된다. 각 non-leaf node는 자기 subtree에서 얼마나 많은 child node가 GPU memory에 있는지를 알 수 있다.

; Proactive prefetch
: 어떤 non-leaf node에서 <math>N_{migrated}</math>가 <math>N_{total}</math>의 50%를 넘으면, TBNp는 그 subtree의 나머지 leaf node도 GPU memory로 prefetch한다. 예를 들어 같은 2 MB VABlock의 앞쪽 leaf들이 이미 많이 migrate되었다면, 나머지 인접 leaf도 곧 접근될 것이라고 본다.

; Far-fault amortization
: TBNp의 목적은 한 번의 far-fault handling 동안 여러 page를 함께 가져와, 이후 발생할 수 있는 여러 on-demand far-fault를 제거하는 것이다. GPU workload가 sequential 또는 dense spatial access를 보이면 이 전략이 잘 맞는다.

=== 왜 tree를 쓰는가 ===
GPU memory access는 CPU prefetcher가 가정하는 instruction-local cache miss stream과 다르게, 많은 warp와 SM에서 bursty하게 발생할 수 있다. 개별 load instruction 단위로 fine-grained access pattern을 추적하면 metadata와 driver communication 비용이 커진다. 반대로 TBNp는 page migration이라는 coarse-grained UVM event를 tree 구조로 묶어, batch 단위 locality와 prefetch aggressiveness를 비교적 간단하게 조절한다.

Tree-based prefetching이 GPU의 bursty memory behavior에 잘 맞고, prefetch aggressiveness를 hierarchical하게 조절할 수 있기 때문에 TBNp가 최근 NVIDIA GPU UVM에서 중요하게 사용되고 있다.

== 한계 ==
; Homogeneous configuration
: conventional TBNp는 모든 application, kernel, data object에 같은 tree configuration을 적용한다. Forest 논문에서 다룬 baseline은 2 MB tree와 64 KB leaf node를 사용한다. 그러나 실제 workload에서는 어떤 object는 linear streaming이고, 어떤 object는 sparse irregular access를 보인다. 하나의 tree size와 leaf size가 모든 object에 최적일 수 없다.

; Unnecessary migration
: TBNp는 locality를 가정하고 neighboring page를 미리 가져온다. 하지만 sparse access에서는 64 KB leaf 안에서도 실제로 쓰는 4 KB page가 일부뿐일 수 있다. 이 경우 migration된 page가 eviction 전까지 한 번도 접근되지 않을 수 있고, GPU memory capacity를 불필요하게 점유한다.

; Oversubscription에서 memory pressure 악화
: GPU memory가 oversubscribed된 상황에서는 prefetch가 항상 좋은 것이 아니다. 잘못 prefetch된 page가 GPU memory를 차지하면 유용한 page가 밀려나고, 이후 다시 migrate되면서 page thrashing이 생긴다. Forest 논문은 일부 benchmark에서 migrated page의 5%에서 48%가 eviction 전까지 전혀 접근되지 않았다고 보고한다.

; Eviction policy와의 상호작용
: conventional UVM eviction은 GPU-side actual access recency가 아니라 far-fault event history에 의존한다. 따라서 TBNp가 불필요한 migration을 만들면 eviction candidate도 왜곡될 수 있다. Prefetcher와 eviction policy는 독립된 문제가 아니라 같은 GPU memory capacity를 두고 상호작용한다.

; Access pattern obliviousness
: TBNp는 page fault와 migration state는 보지만, data object의 semantic이나 GPU-side access sequence를 직접 이해하지 않는다. 그래서 같은 application 안에서 kernel마다 object access pattern이 달라져도 동일한 policy를 적용한다.

[[분류: GPU Unified Virtual Memory]]

ARIADNE: Adaptive UVM Management for Efficient GPU Memory Oversubscription

2026-06-17T09:15:13Z

Noribot: Nori: update draft.md

{{Paper
|title=ARIADNE: Adaptive UVM Management for Efficient GPU Memory Oversubscription
|author=Hyunkyun Shin, Seongtae Bang, Hyungwon Park, Daehoon Kim
|conference=IEEE International Symposium on High Performance Computer Architecture (HPCA)
|year=2026
|doi=10.1109/HPCA68181.2026.11408564
}}

== 개요 ==
이 논문은 [[GPU]] [[Unified Virtual Memory]]에서 memory oversubscription이 발생할 때 page fault 처리 지연과 thrashing이 왜 급격한 성능 저하로 이어지는지 분석하고, runtime-only UVM driver management인 ARIADNE로 memory region placement를 동적으로 바꾸어 이를 완화할 수 있음을 보였다. 기존 [[NVIDIA UVM]]의 fault handling path와 page placement policy를 바꾸되, hardware, compiler, application code를 수정하지 않고도 최적화할 수 있는 transparency를 제공한다.

== Motivation ==
; Page fault handling overhead가 큼
: Host memory에 있는 UVM page를 GPU memory로 migration하기 위한 fault handling 비용이 크다. NVIDIA의 access counter-based migration(AC)은 page를 initially Zero-copy state에 두고, access count가 static threshold를 넘는 page만 GPU로 migrate하여 불필요한 migration을 줄이려 한다. 그러나 threshold가 workload의 access pattern이나 현재 memory pressure에 적응하지 못하기 때문에, no-oversubscription 상황에서는 Zero-copy overhead가 커지고 high-oversubscription 상황에서는 thrashing을 완전히 막지 못한다.

; oversubscription 상황에서 UVM이 매우 쉽게 thrashing에 빠짐
: 기본 UVM은 4 KB page fault를 받더라도 GPU physical memory allocation은 보통 2 MB VABlock/chunk 단위로 수행한다. Sparse access에서는 실제로 필요한 page보다 큰 chunk가 GPU memory를 점유하면서 WCSS가 부풀고, last-fault-time 기반 victim selection은 아직 active한 VABlock을 evict한 뒤 곧바로 다시 refetch하게 만들 수 있다. 이 coarse-grained allocation과 단순 eviction policy의 조합이 repeated eviction-refetch cycle을 만든다.

기존 대응은 크게 prefetching, access counter 기반 migration, Zero-copy placement로 나뉜다. 그러나 prefetching은 thrashing 자체를 제거하지 못하고, access counter 방식은 static threshold에 의존하며, compiler/hardware 기반 Zero-copy 선택은 UVM의 장점인 binary transparency와 hardware portability를 약화시킨다.

== Main Idea ==
; Design Principle #1. Reduce UVM fault-handling latency through pipelined execution
: ARIADNE는 UVM fault handling의 latency bottleneck이 Copy/Eviction보다 Populate에 있다는 관찰을 사용한다. Populate, Copy, Eviction을 VABlock 간 pipeline으로 분리하여 long-latency Populate를 다른 VABlock의 Copy/Eviction과 overlap시킨다. 즉 ARIADNE는 placement policy와 fault handling pipeline을 함께 바꾸어 thrashing과 migration latency를 동시에 줄이려 한다.

; Design Principle #2. Sharing Degree: a runtime access-pattern metric leveraging thread-level information
: GPU thread execution architecture가 VABlock-level spatial locality의 runtime signal을 남긴다는 관찰을 이용하는 것이다. GPU kernel에서 thread block은 SM에 배치되고, 인접 SM들은 uTLB를 공유한다. 어떤 VABlock을 여러 uTLB/SM이 동시에 faulting한다면, 서로 다른 thread block이 그 VABlock 내부의 여러 page를 접근하고 있을 가능성이 높다. 반대로 unique uTLB가 적으면 일부 thread group만 sparse하게 접근하는 영역일 가능성이 높다. 이를 반영하는 Sharing Degree라는 runtime metric을 정의하였다. UVM driver는 kernel source나 per-thread address expression을 보지 못하지만, page fault record의 source uTLB ID는 볼 수 있다. ARIADNE는 최근 fault를 발생시킨 unique uTLB 수를 VABlock별로 추적하여, 해당 VABlock을 동시에 접근하는 SM/thread group의 수를 근사한다. 이 값이 높으면 VABlock 내부의 page utilization이 높고 dense access일 가능성이 크다는 것이 논문의 핵심 관찰이다.

; Design Principle #3. Managing memory region placement between GPU memory and Zero-copy based on runtime memory access characteristics
: 특히 migration은 2 MB chunk 단위이고 Zero-copy는 128 B cache line 단위이므로, dense VABlock은 GPU memory에 두는 것이 유리하고 sparse VABlock은 host memory의 Zero-copy로 두는 것이 유리하다는 placement framing을 제시한다. ARIADNE는 Sharing Degree를 이용해 VABlock을 GPU memory와 Zero-copy 사이에서 동적으로 배치한다. Dense VABlock은 2 MB chunk를 GPU에 올려도 내부 활용도가 높으므로 migration이 유리하다. Sparse VABlock은 chunk를 통째로 점유하면 WCSS를 부풀리므로, evicted 이후 재접근되더라도 곧장 GPU로 다시 올리지 않고 일시적으로 Zero-copy로 둔다.

== Background ==
; VABlock과 chunk
: NVIDIA UVM은 virtual address range를 VABlock으로 관리하고, GPU physical memory는 chunk 단위로 할당한다. 논문 기준으로 보통 VABlock과 chunk는 각각 2 MB이다. Page fault는 4 KB 단위로 발생하지만 allocation과 eviction은 더 coarse-grained하게 일어난다.

; Populate, Eviction, Copy
: UVM fault handling은 GPU chunk를 준비하는 Populate, victim chunk를 host로 내보내는 Eviction, host page를 GPU memory로 복사하는 Copy로 구성된다. 논문은 Populate latency가 Copy/Eviction의 거의 두 배이며, fault batch 전체 latency를 지배한다고 분석한다.

; Zero-copy
: Zero-copy는 page를 host memory에 pin한 뒤 GPU가 remote access하도록 하는 방식이다. GPU memory bandwidth보다 느리지만, sparse VABlock을 2 MB chunk로 migrate하지 않아도 되므로 oversubscription thrashing을 줄일 수 있다.

== Design ==
; Working Chunk Set Size (WCSS) estimation
: ARIADNE는 workload가 실제로 요구하는 GPU chunk 수를 WCSS로 추적한다. 단순히 GPU-resident VABlock만 세면 방금 evict되었지만 곧 재접근될 active VABlock을 놓칠 수 있으므로, GPU resident VABlock, Zero-copy VABlock, re-access 가능성이 높은 recently evicted VABlock을 함께 포함한다. 초기 정보가 부족할 때는 GPU-wide average Sharing Degree가 낮으면 sparse workload로 보고 최근 evicted VABlock을 500 ms 동안 WCSS에 보존한다.

; Sharing Degree measurement
: 각 VABlock에 대해 최근 16개 page fault의 source uTLB ID를 circular queue에 저장하고, unique uTLB ID 개수를 Sharing Degree로 계산한다. Source uTLB ID는 UVM driver의 fault record에서 얻을 수 있으므로 hardware나 compiler modification이 필요 없다. 논문은 ATAX/GEMV 같은 sparse workload는 Sharing Degree가 주로 1이고, GEMM/HEL 같은 dense workload는 4보다 큰 값이 많으며, BFS/NW/XSB처럼 mixed pattern인 workload는 VABlock별로 다른 값을 보인다고 제시하였다. 이 Sharing Degree는 VABlock을 접근하는 SM/thread group의 다양성을 통해 spatial locality를 근사한다. 따라서 ARIADNE에서는 '''Sharing Degree로 VABlock이 sparse한지 dense한지 판단'''하는 것이 placement decision의 핵심이다.

; Pipelined VABlock fault handling
: 기본 UVM은 Populate, Eviction, Copy를 monolithic sequential routine으로 처리한다. ARIADNE는 Populate를 Copy와 분리하고, 다른 VABlock의 Populate/Copy/Eviction을 병렬로 실행한다. Populate는 GPU chunk allocation과 metadata 준비만 끝낸 뒤 Copy worker에 넘기고, Eviction은 free chunk가 부족해진 뒤 반응적으로 실행되는 대신 dedicated thread에서 proactive하게 실행된다. 이 구조는 Populate의 긴 latency를 다른 작업 뒤에 숨기는 것이 목적이다.

; Sharing Degree-aware eviction
: ARIADNE는 fault recency만 보는 eviction queue 대신 Sharing Degree를 반영한 priority key를 사용한다. 논문이 제시한 형태는 <math>last fault time + (SD Weight * Sharing Degree / Nfault_history)</math>이며, 구현에서는 fault history 길이 16과 SD Weight 100 us를 사용한다. Sharing Degree가 높은 VABlock은 GPU memory에 남길 가치가 높다고 보고 eviction priority를 낮춘다.

; Dynamic Zero-copy
: Memory demand가 GPU capacity를 넘으면 ARIADNE는 evicted 뒤 재접근된 VABlock을 즉시 GPU로 refetch하지 않고 100 ms 동안 Zero-copy state로 유지한다. 이 second-chance policy는 방금 쫓겨난 sparse VABlock이 다시 fault를 내며 eviction-refetch cycle을 만드는 것을 줄인다. 100 ms가 지나도록 재사용되지 않으면 Zero-copy state를 해제하고, 이후에도 계속 재사용되면 GPU memory로 promote될 수 있다.

; Dynamic prefetching
: Copy 단계에서는 기본 UVM prefetcher가 선택한 page를 복사하되, GPU memory 여유가 충분하거나 VABlock의 Sharing Degree가 threshold보다 높으면 VABlock 전체를 적극적으로 copy한다. 논문 구현의 Sharing Degree threshold는 3이다. 이 정책은 dense VABlock에 대해서는 future fault를 줄이고, sparse VABlock에 대해서는 불필요한 2 MB migration을 피하려는 tradeoff를 갖는다.

== Result ==
평가는 NVIDIA RTX A5000, AMD Ryzen 7700X, PCIe 4.0 x16, 64 GB DDR5, Linux 6.0, NVIDIA open-source kernel driver 535.86 환경에서 수행되었다. Workload는 Rodinia, Polybench, HeCBench, XSBench에서 가져온 10개 benchmark(2DC, ATAX, BICG, GEMM, GEMV, MVT, XSB, BFS, HEL, NW)이며, 각 benchmark의 memory footprint는 4 GB로 맞추었다. Oversubscription ratio는 no oversubscription, 130%, 175%, 300%를 사용한다.

Baseline UVM은 oversubscription에서 급격히 무너진다. 논문은 baseline UVM의 geomean execution time이 200% oversubscription에서 33.2배, 300%에서 60.7배까지 증가한다고 보고한다. AC(access counter-based migration)는 Zero-copy를 활용해 thrashing을 줄이지만 no oversubscription에서는 평균 1.3배, 최대 2.5배 느려지고, 210%와 300% oversubscription에서는 no oversubscription 대비 각각 4.7배와 8.9배 느려진다.

ARIADNE는 AC 대비 130%, 175%, 300% oversubscription에서 각각 1.9배, 2.3배, 4.0배 geomean speedup을 보인다. SUV 대비로는 같은 oversubscription ratio에서 각각 1.9배, 5.0배, 4.8배 speedup을 보인다. 또한 no-oversubscription 대비 runtime 증가는 130%, 175%, 300%에서 각각 1.6배, 1.8배, 2.3배로 보고되어, 논문은 near-linear degradation이라고 해석한다.

Mechanism-level evidence도 제시된다. Pipelined VABlock fault handling은 10개 benchmark에서 VABlock fault handling latency를 평균 17%, 최대 48%(BFS) 줄인다. Dynamic VABlock placement는 175% oversubscription에서 AC 대비 PCIe traffic을 평균 51% 수준으로 낮춘다. Breakdown에서는 Sharing Degree 기반 placement/eviction이 핵심 성능 요인이고, pipelining이 oversubscription 상황에서 정책 overhead를 숨기는 역할을 한다고 해석된다.

LLM inference 실험도 포함된다. Llama3.1 70B inference(input token length 2048)에서 ARIADNE는 AC 대비 Decode phase 4.2배, Prefill phase 1.6배 speedup을 보인다. Decode가 GEMV 중심이기 때문에 GEMV benchmark에서 큰 이득을 보인 결과와 일관된다고 설명한다.

Overhead는 작다고 보고된다. Additional metadata는 VABlock당 70 B 미만, GPU당 100 B 미만이며, 16 GB application 기준 약 560 KB이다. Sharing Degree/WCSS tracking과 Zero-copy process의 추가 latency는 최대 100 ns로, 단일 VABlock fault handling 약 20 us에 비해 무시 가능하다고 주장한다.

== Contribution ==
# UVM oversubscription에서 성능 저하의 원인을 Populate-dominated fault handling latency, 2 MB chunk granularity에 따른 WCSS amplification, last-fault-time eviction에 따른 thrashing으로 정리하였다.
# GPU thread execution architecture와 source uTLB ID를 이용해 VABlock-level spatial locality를 runtime에서 추정하는 Sharing Degree metric을 제안하였다.
# Sharing Degree와 WCSS를 기반으로 VABlock을 GPU memory와 Zero-copy 사이에서 동적으로 배치하는 runtime-only UVM management framework ARIADNE를 설계하였다.
# Populate, Copy, Eviction을 VABlock 간 pipeline으로 분리하여 UVM fault handling latency를 줄이는 driver-level execution structure를 구현하였다.
# NVIDIA open-source UVM driver 내부 수정 약 1600 LOC만으로 구현하고, hardware/compiler/application modification 없이 executable 또는 closed-source UVM application에 적용 가능한 설계를 보였다.
# 10개 GPU benchmark와 Llama3.1 70B inference에서 AC, SUV, baseline UVM 대비 성능 향상과 oversubscription scaling을 실험적으로 제시하였다.

== Criticisms ==
# Sharing Degree는 source uTLB ID를 thread group locality의 proxy로 사용하는 metric이다. 논문은 benchmark에서 utilization과의 상관을 보이지만, uTLB sharing topology, SM scheduling, phase behavior가 다른 GPU generation에서 threshold 3, history length 16, SD Weight 100 us, Zero-copy pin time 100 ms가 항상 좋은지는 제한적이다. 따라서 ARIADNE의 parameter choice가 특정 실험 환경에 과도하게 맞춰진 것은 아닌지 추가 검증할 필요가 있다.
# 전체적으로 ARIADNE는 여러 driver-level optimization을 조합한 system으로 보인다. 따라서 각 mechanism이 서로 다른 workload와 memory pressure에서 독립적으로 얼마나 기여하는지, 그리고 parameter가 바뀌어도 같은 design principle이 유지되는지를 더 강하게 분리해 보여주면 설득력이 커질 수 있다. 다만 Sharing Degree 자체는 UVM driver가 관찰 가능한 정보만으로 VABlock locality를 추정한다는 점에서 명확한 design point를 제공한다.
# no-oversubscription 또는 memory pressure가 낮은 일부 case에서는 SUV가 ARIADNE보다 빠르다. 논문은 SUV의 compile-time range prefetching이 ARIADNE의 2 MB VABlock granularity prefetch보다 큰 data range를 미리 가져올 수 있기 때문이라고 설명한다. 즉 ARIADNE는 transparency를 얻는 대신 static program knowledge를 활용한 aggressive prefetch opportunity를 일부 잃는다.

== [[Conclusion]] ==
이 연구는 GPU UVM oversubscription을 단순 page fault overhead가 아니라 VABlock placement와 GPU thread-level locality를 함께 다루어야 하는 문제로 바라보게 만든다. ARIADNE는 source uTLB 기반 Sharing Degree, WCSS estimation, Sharing Degree-aware eviction, transient Zero-copy, pipelined fault handling을 결합하여 hardware/compiler/application 수정 없이 oversubscription 성능을 개선할 수 있음을 보였다.

[[분류: 시스템 논문]]
[[분류: IEEE HPCA]]
[[분류: GPU Unified Virtual Memory]]

ARIADNE: Adaptive UVM Management for Efficient GPU Memory Oversubscription

2026-06-17T09:02:03Z

Noribot: Nori: update draft.md

{{Paper
|title=ARIADNE: Adaptive UVM Management for Efficient GPU Memory Oversubscription
|author=Hyunkyun Shin, Seongtae Bang, Hyungwon Park, Daehoon Kim
|conference=IEEE International Symposium on High Performance Computer Architecture (HPCA)
|year=2026
|doi=10.1109/HPCA68181.2026.11408564
}}

== 개요 ==
이 논문은 [[GPU]] [[Unified Virtual Memory]]에서 memory oversubscription이 발생할 때 page fault 처리 지연과 thrashing이 왜 급격한 성능 저하로 이어지는지 분석하고, runtime-only UVM driver management인 ARIADNE로 memory region placement를 동적으로 바꾸어 이를 완화할 수 있음을 보였다. 기존 [[NVIDIA UVM]]의 fault handling path와 page placement policy를 바꾸되, hardware, compiler, application code를 수정하지 않고도 최적화 할수 있는 Transparency를 제공한다.

== Motivation ==
; Pae fault handling overhead가 큼
: CPU메모리를 GPU로 Migration하기 위한 비용이 크다. 이를 줄이기 위해서 기존에는 access counter값이 특정 수치 이상이면, zero-copy를 수행하는 (Nvdia AC)기법을 활용했지만, 특정 workload에서는 오히려 성능이 감소하는 문제가 발생하였다.

; oversubscription 상황에서 UVM이 매우 쉽게 thrashing에 빠짐
: 기본 UVM은 4 KB page fault를 받더라도 GPU physical memory allocation은 보통 2 MB VABlock/chunk 단위로 수행한다. 따라서 CPU page evction policy와 GPU page evction policy가 일치하지 않는 문제가 발생한다.

기존 대응은 크게 prefetching, access counter 기반 migration, Zero-copy placement로 나뉜다. 그러나 prefetching은 thrashing 자체를 제거하지 못하고, access counter 방식은 static threshold에 의존하며, compiler/hardware 기반 Zero-copy 선택은 UVM의 장점인 binary transparency와 hardware portability를 약화시킨다.

== Main Idea ==
; Design Principle #1. Reduce UVM fault-handling latency through pipelined execution
: ARIADNE는 UVM fault handling의 latency bottleneck이 Copy/Eviction보다 Populate에 있다는 관찰을 사용한다. Populate, Copy, Eviction을 VABlock 간 pipeline으로 분리하여 long-latency Populate를 다른 VABlock의 Copy/Eviction과 overlap시킨다. 즉 ARIADNE는 placement policy와 fault handling pipeline을 함께 바꾸어 thrashing과 migration latency를 동시에 줄이려 한다.

; Design Principle #2. Sharing Degree: a runtime access-pattern metric leveraging thread-level information
: GPU thread execution architecture가 VABlock-level spatial locality의 runtime signal을 남긴다는 관찰을 이용하는 것이다. GPU kernel에서 thread block은 SM에 배치되고, 인접 SM들은 uTLB를 공유한다. 어떤 VABlock을 여러 uTLB/SM이 동시에 faulting한다면, 서로 다른 thread block이 그 VABlock 내부의 여러 page를 접근하고 있을 가능성이 높다. 반대로 unique uTLB가 적으면 일부 thread group만 sparse하게 접근하는 영역일 가능성이 높다. 이를 반영하는 Sharing Degree라는 runtime metric을 정의하였다. UVM driver는 kernel source나 per-thread address expression을 보지 못하지만, page fault record의 source uTLB ID는 볼 수 있다. ARIADNE는 최근 fault를 발생시킨 unique uTLB 수를 VABlock별로 추적하여, 해당 VABlock을 동시에 접근하는 SM/thread group의 수를 근사한다. 이 값이 높으면 VABlock 내부의 page utilization이 높고 dense access일 가능성이 크다는 것이 논문의 핵심 관찰이다.

; Design Principle #3. Managing CPU memory region placement between GPU memory and Zero-copy based on runtime memory access characteristics
특히 migration은 2 MB chunk 단위이고 Zero-copy는 128 B cache line 단위이므로, dense VABlock은 GPU memory에 두는 것이 유리하고 sparse VABlock은 host memory의 Zero-copy로 두는 것이 유리하다는 placement framing을 제시한다. ARIADNE는 Sharing Degree를 이용해 VABlock을 GPU memory와 Zero-copy 사이에서 동적으로 배치한다. Dense VABlock은 2 MB chunk를 GPU에 올려도 내부 활용도가 높으므로 migration이 유리하다. Sparse VABlock은 chunk를 통째로 점유하면 WCSS를 부풀리므로, evicted 이후 재접근되더라도 곧장 GPU로 다시 올리지 않고 일시적으로 Zero-copy로 둔다.

== Background ==
; VABlock과 chunk
: NVIDIA UVM은 virtual address range를 VABlock으로 관리하고, GPU physical memory는 chunk 단위로 할당한다. 논문 기준으로 보통 VABlock과 chunk는 각각 2 MB이다. Page fault는 4 KB 단위로 발생하지만 allocation과 eviction은 더 coarse-grained하게 일어난다.

; Populate, Eviction, Copy
: UVM fault handling은 GPU chunk를 준비하는 Populate, victim chunk를 host로 내보내는 Eviction, host page를 GPU memory로 복사하는 Copy로 구성된다. 논문은 Populate latency가 Copy/Eviction의 거의 두 배이며, fault batch 전체 latency를 지배한다고 분석한다.

; Zero-copy
: Zero-copy는 page를 host memory에 pin한 뒤 GPU가 remote access하도록 하는 방식이다. GPU memory bandwidth보다 느리지만, sparse VABlock을 2 MB chunk로 migrate하지 않아도 되므로 oversubscription thrashing을 줄일 수 있다.

== Design ==
; Working Chunk Set Size (WCSS) estimation
: ARIADNE는 workload가 실제로 요구하는 GPU chunk 수를 WCSS로 추적한다. 단순히 GPU-resident VABlock만 세면 방금 evict되었지만 곧 재접근될 active VABlock을 놓칠 수 있으므로, GPU resident VABlock, Zero-copy VABlock, re-access 가능성이 높은 recently evicted VABlock을 함께 포함한다. 초기 정보가 부족할 때는 GPU-wide average Sharing Degree가 낮으면 sparse workload로 보고 최근 evicted VABlock을 500 ms 동안 WCSS에 보존한다.

; Sharing Degree measurement
: 각 VABlock에 대해 최근 16개 page fault의 source uTLB ID를 circular queue에 저장하고, unique uTLB ID 개수를 Sharing Degree로 계산한다. Source uTLB ID는 UVM driver의 fault record에서 얻을 수 있으므로 hardware나 compiler modification이 필요 없다. 논문은 ATAX/GEMV 같은 sparse workload는 Sharing Degree가 주로 1이고, GEMM/HEL 같은 dense workload는 4보다 큰 값이 많으며, BFS/NW/XSB처럼 mixed pattern인 workload는 VABlock별로 다른 값을 보인다고 제시하였다. 이 Sharing Degree는 SM들에 접근하는 메모리의 spatial locality에 대한 정보를 효과적으로 보여준다고 주장한다. 따라서 '''Sparse memory의 값으로 sparse인지 아니면 dense한지 판단'''하는 것이 중요하다고 주장하였다.

; Pipelined VABlock fault handling
: 기본 UVM은 Populate, Eviction, Copy를 monolithic sequential routine으로 처리한다. ARIADNE는 Populate를 Copy와 분리하고, 다른 VABlock의 Populate/Copy/Eviction을 병렬로 실행한다. Populate는 GPU chunk allocation과 metadata 준비만 끝낸 뒤 Copy worker에 넘기고, Eviction은 free chunk가 부족해진 뒤 반응적으로 실행되는 대신 dedicated thread에서 proactive하게 실행된다. 이 구조는 Populate의 긴 latency를 다른 작업 뒤에 숨기는 것이 목적이다.

; Sharing Degree-aware eviction
: ARIADNE는 fault recency만 보는 eviction queue 대신 Sharing Degree를 반영한 priority key를 사용한다. 논문이 제시한 형태는 <math>last fault time + (SD Weight * Sharing Degree / Nfault_history)</math>이며, 구현에서는 fault history 길이 16과 SD Weight 100 us를 사용한다. Sharing Degree가 높은 VABlock은 GPU memory에 남길 가치가 높다고 보고 eviction priority를 낮춘다.

; Dynamic Zero-copy
: Memory demand가 GPU capacity를 넘으면 ARIADNE는 evicted 뒤 재접근된 VABlock을 즉시 GPU로 refetch하지 않고 100 ms 동안 Zero-copy state로 유지한다. 이 second-chance policy는 방금 쫓겨난 sparse VABlock이 다시 fault를 내며 eviction-refetch cycle을 만드는 것을 줄인다. 100 ms가 지나도록 재사용되지 않으면 Zero-copy state를 해제하고, 이후에도 계속 재사용되면 GPU memory로 promote될 수 있다.

; Dynamic prefetching
: Copy 단계에서는 기본 UVM prefetcher가 선택한 page를 복사하되, GPU memory 여유가 충분하거나 VABlock의 Sharing Degree가 threshold보다 높으면 VABlock 전체를 적극적으로 copy한다. 논문 구현의 Sharing Degree threshold는 3이다. 이 정책은 dense VABlock에 대해서는 future fault를 줄이고, sparse VABlock에 대해서는 불필요한 2 MB migration을 피하려는 tradeoff를 갖는다.

== Result ==
평가는 NVIDIA RTX A5000, AMD Ryzen 7700X, PCIe 4.0 x16, 64 GB DDR5, Linux 6.0, NVIDIA open-source kernel driver 535.86 환경에서 수행되었다. Workload는 Rodinia, Polybench, HeCBench, XSBench에서 가져온 10개 benchmark(2DC, ATAX, BICG, GEMM, GEMV, MVT, XSB, BFS, HEL, NW)이며, 각 benchmark의 memory footprint는 4 GB로 맞추었다. Oversubscription ratio는 no oversubscription, 130%, 175%, 300%를 사용한다.

Baseline UVM은 oversubscription에서 급격히 무너진다. 논문은 baseline UVM의 geomean execution time이 200% oversubscription에서 33.2배, 300%에서 60.7배까지 증가한다고 보고한다. AC(access counter-based migration)는 Zero-copy를 활용해 thrashing을 줄이지만 no oversubscription에서는 평균 1.3배, 최대 2.5배 느려지고, 210%와 300% oversubscription에서는 no oversubscription 대비 각각 4.7배와 8.9배 느려진다.

ARIADNE는 AC 대비 130%, 175%, 300% oversubscription에서 각각 1.9배, 2.3배, 4.0배 geomean speedup을 보인다. SUV 대비로는 같은 oversubscription ratio에서 각각 1.9배, 5.0배, 4.8배 speedup을 보인다. 또한 no-oversubscription 대비 runtime 증가는 130%, 175%, 300%에서 각각 1.6배, 1.8배, 2.3배로 보고되어, 논문은 near-linear degradation이라고 해석한다.

Mechanism-level evidence도 제시된다. Pipelined VABlock fault handling은 10개 benchmark에서 VABlock fault handling latency를 평균 17%, 최대 48%(BFS) 줄인다. Dynamic VABlock placement는 175% oversubscription에서 AC 대비 PCIe traffic을 평균 51% 수준으로 낮춘다. Breakdown에서는 Sharing Degree 기반 placement/eviction이 핵심 성능 요인이고, pipelining이 oversubscription 상황에서 정책 overhead를 숨기는 역할을 한다고 해석된다.

LLM inference 실험도 포함된다. Llama3.1 70B inference(input token length 2048)에서 ARIADNE는 AC 대비 Decode phase 4.2배, Prefill phase 1.6배 speedup을 보인다. Decode가 GEMV 중심이기 때문에 GEMV benchmark에서 큰 이득을 보인 결과와 일관된다고 설명한다.

Overhead는 작다고 보고된다. Additional metadata는 VABlock당 70 B 미만, GPU당 100 B 미만이며, 16 GB application 기준 약 560 KB이다. Sharing Degree/WCSS tracking과 Zero-copy process의 추가 latency는 최대 100 ns로, 단일 VABlock fault handling 약 20 us에 비해 무시 가능하다고 주장한다.

== Contribution ==
# UVM oversubscription에서 성능 저하의 원인을 Populate-dominated fault handling latency, 2 MB chunk granularity에 따른 WCSS amplification, last-fault-time eviction에 따른 thrashing으로 정리하였다.
# GPU thread execution architecture와 source uTLB ID를 이용해 VABlock-level spatial locality를 runtime에서 추정하는 Sharing Degree metric을 제안하였다.
# Sharing Degree와 WCSS를 기반으로 VABlock을 GPU memory와 Zero-copy 사이에서 동적으로 배치하는 runtime-only UVM management framework ARIADNE를 설계하였다.
# Populate, Copy, Eviction을 VABlock 간 pipeline으로 분리하여 UVM fault handling latency를 줄이는 driver-level execution structure를 구현하였다.
# NVIDIA open-source UVM driver 내부 수정 약 1600 LOC만으로 구현하고, hardware/compiler/application modification 없이 executable 또는 closed-source UVM application에 적용 가능한 설계를 보였다.
# 10개 GPU benchmark와 Llama3.1 70B inference에서 AC, SUV, baseline UVM 대비 성능 향상과 oversubscription scaling을 실험적으로 제시하였다.

== Criticisms ==
# Sharing Degree는 source uTLB ID를 thread group locality의 proxy로 사용하는 metric이다. 논문은 benchmark에서 utilization과의 상관을 보이지만, uTLB sharing topology, SM scheduling, phase behavior가 다른 GPU generation에서 threshold 3, history length 16, SD Weight 100 us, Zero-copy pin time 100 ms가 항상 좋은지는 제한적이다. 약간 fine-tuning되어 있는 값처럼 보이는 경향이 있다.
# 전체적으로 논문이 Collection of fine-tuned optimization으로 보이는 경향이 있다. 그러나 논문에서 제시되는 Sharing Degree와 같은 개념은 좋은 Design point이기 떄문에, Collection-of-optimizations으로 보는 것이 오히려 불필요하게 Critical한 Review일 수 있을 것 같다는 생각도 든다. 이런 Optimization work의 숙명일 수도....
# no-oversubscription 또는 memory pressure가 낮은 일부 case에서는 SUV가 ARIADNE보다 빠르다. 논문은 SUV의 compile-time range prefetching이 ARIADNE의 2 MB VABlock granularity prefetch보다 큰 data range를 미리 가져올 수 있기 때문이라고 설명한다. 즉 ARIADNE는 transparency를 얻는 대신 static program knowledge를 활용한 aggressive prefetch opportunity를 일부 잃는다.

== [[Conclusion]] ==
이 연구는 GPU UVM oversubscription을 단순 page fault overhead가 아니라 VABlock placement와 GPU thread-level locality를 함께 다루어야 하는 문제로 바라보게 만든다. ARIADNE는 source uTLB 기반 Sharing Degree, WCSS estimation, Sharing Degree-aware eviction, transient Zero-copy, pipelined fault handling을 결합하여 hardware/compiler/application 수정 없이 oversubscription 성능을 개선할 수 있음을 보였다.

[[분류: 시스템 논문]]
[[분류: IEEE HPCA]]
[[분류: GPU Unified Virtual Memory]]

ARIADNE: Adaptive UVM Management for Efficient GPU Memory Oversubscription

2026-06-17T09:00:41Z

Noribot: Nori: update draft.md

{{Paper
|title=ARIADNE: Adaptive UVM Management for Efficient GPU Memory Oversubscription
|author=Hyunkyun Shin, Seongtae Bang, Hyungwon Park, Daehoon Kim
|conference=IEEE International Symposium on High Performance Computer Architecture (HPCA)
|year=2026
|doi=10.1109/HPCA68181.2026.11408564
}}

== 개요 ==
이 논문은 [[GPU]] [[Unified Virtual Memory]]에서 memory oversubscription이 발생할 때 page fault 처리 지연과 thrashing이 왜 급격한 성능 저하로 이어지는지 분석하고, runtime-only UVM driver management인 ARIADNE로 memory region placement를 동적으로 바꾸어 이를 완화할 수 있음을 보였다. 기존 [[NVIDIA UVM]]의 fault handling path와 page placement policy를 바꾸되, hardware, compiler, application code를 수정하지 않고도 최적화 할수 있는 Transparency를 제공한다.

== Motivation ==
; Pae fault handling overhead가 큼
: CPU메모리를 GPU로 Migration하기 위한 비용이 크다. 이를 줄이기 위해서 기존에는 access counter값이 특정 수치 이상이면, zero-copy를 수행하는 (Nvdia AC)기법을 활용했지만, 특정 workload에서는 오히려 성능이 감소하는 문제가 발생하였다.

; oversubscription 상황에서 UVM이 매우 쉽게 thrashing에 빠짐
: 기본 UVM은 4 KB page fault를 받더라도 GPU physical memory allocation은 보통 2 MB VABlock/chunk 단위로 수행한다. 따라서 CPU page evction policy와 GPU page evction policy가 일치하지 않는 문제가 발생한다.

기존 대응은 크게 prefetching, access counter 기반 migration, Zero-copy placement로 나뉜다. 그러나 prefetching은 thrashing 자체를 제거하지 못하고, access counter 방식은 static threshold에 의존하며, compiler/hardware 기반 Zero-copy 선택은 UVM의 장점인 binary transparency와 hardware portability를 약화시킨다.

== Main Idea ==
; Design Principle #1. Reduce UVM fault-handling latency through pipelined execution
: ARIADNE는 UVM fault handling의 latency bottleneck이 Copy/Eviction보다 Populate에 있다는 관찰을 사용한다. Populate, Copy, Eviction을 VABlock 간 pipeline으로 분리하여 long-latency Populate를 다른 VABlock의 Copy/Eviction과 overlap시킨다. 즉 ARIADNE는 placement policy와 fault handling pipeline을 함께 바꾸어 thrashing과 migration latency를 동시에 줄이려 한다.

; Design Principle #2. Sharing Degree: a runtime access-pattern metric leveraging thread-level information
: GPU thread execution architecture가 VABlock-level spatial locality의 runtime signal을 남긴다는 관찰을 이용하는 것이다. GPU kernel에서 thread block은 SM에 배치되고, 인접 SM들은 uTLB를 공유한다. 어떤 VABlock을 여러 uTLB/SM이 동시에 faulting한다면, 서로 다른 thread block이 그 VABlock 내부의 여러 page를 접근하고 있을 가능성이 높다. 반대로 unique uTLB가 적으면 일부 thread group만 sparse하게 접근하는 영역일 가능성이 높다. 이를 반영하는 Sharing Degree라는 runtime metric을 정의하였다. UVM driver는 kernel source나 per-thread address expression을 보지 못하지만, page fault record의 source uTLB ID는 볼 수 있다. ARIADNE는 최근 fault를 발생시킨 unique uTLB 수를 VABlock별로 추적하여, 해당 VABlock을 동시에 접근하는 SM/thread group의 수를 근사한다. 이 값이 높으면 VABlock 내부의 page utilization이 높고 dense access일 가능성이 크다는 것이 논문의 핵심 관찰이다.

; Design Principle #3. Managing CPU memory region placement between GPU memory and Zero-copy based on runtime memory access characteristics
특히 migration은 2 MB chunk 단위이고 Zero-copy는 128 B cache line 단위이므로, dense VABlock은 GPU memory에 두는 것이 유리하고 sparse VABlock은 host memory의 Zero-copy로 두는 것이 유리하다는 placement framing을 제시한다. ARIADNE는 Sharing Degree를 이용해 VABlock을 GPU memory와 Zero-copy 사이에서 동적으로 배치한다. Dense VABlock은 2 MB chunk를 GPU에 올려도 내부 활용도가 높으므로 migration이 유리하다. Sparse VABlock은 chunk를 통째로 점유하면 WCSS를 부풀리므로, evicted 이후 재접근되더라도 곧장 GPU로 다시 올리지 않고 일시적으로 Zero-copy로 둔다.

== Background ==
; VABlock과 chunk
: NVIDIA UVM은 virtual address range를 VABlock으로 관리하고, GPU physical memory는 chunk 단위로 할당한다. 논문 기준으로 보통 VABlock과 chunk는 각각 2 MB이다. Page fault는 4 KB 단위로 발생하지만 allocation과 eviction은 더 coarse-grained하게 일어난다.

; Populate, Eviction, Copy
: UVM fault handling은 GPU chunk를 준비하는 Populate, victim chunk를 host로 내보내는 Eviction, host page를 GPU memory로 복사하는 Copy로 구성된다. 논문은 Populate latency가 Copy/Eviction의 거의 두 배이며, fault batch 전체 latency를 지배한다고 분석한다.

; Zero-copy
: Zero-copy는 page를 host memory에 pin한 뒤 GPU가 remote access하도록 하는 방식이다. GPU memory bandwidth보다 느리지만, sparse VABlock을 2 MB chunk로 migrate하지 않아도 되므로 oversubscription thrashing을 줄일 수 있다.

== Design ==
; Working Chunk Set Size (WCSS) estimation
: ARIADNE는 workload가 실제로 요구하는 GPU chunk 수를 WCSS로 추적한다. 단순히 GPU-resident VABlock만 세면 방금 evict되었지만 곧 재접근될 active VABlock을 놓칠 수 있으므로, GPU resident VABlock, Zero-copy VABlock, re-access 가능성이 높은 recently evicted VABlock을 함께 포함한다. 초기 정보가 부족할 때는 GPU-wide average Sharing Degree가 낮으면 sparse workload로 보고 최근 evicted VABlock을 500 ms 동안 WCSS에 보존한다.

; Sharing Degree measurement
: 각 VABlock에 대해 최근 16개 page fault의 source uTLB ID를 circular queue에 저장하고, unique uTLB ID 개수를 Sharing Degree로 계산한다. Source uTLB ID는 UVM driver의 fault record에서 얻을 수 있으므로 hardware나 compiler modification이 필요 없다. 논문은 ATAX/GEMV 같은 sparse workload는 Sharing Degree가 주로 1이고, GEMM/HEL 같은 dense workload는 4보다 큰 값이 많으며, BFS/NW/XSB처럼 mixed pattern인 workload는 VABlock별로 다른 값을 보인다고 제시하였다. 이 Sharing Degree는 SM들에 접근하는 메모리의 spatial locality에 대한 정보를 효과적으로 보여준다고 주장한다. 따라서 '''Sparse memory의 값으로 sparse인지 아니면 dense한지 판단'''하는 것이 중요하다고 주장하였다.

; Pipelined VABlock fault handling
: 기본 UVM은 Populate, Eviction, Copy를 monolithic sequential routine으로 처리한다. ARIADNE는 Populate를 Copy와 분리하고, 다른 VABlock의 Populate/Copy/Eviction을 병렬로 실행한다. Populate는 GPU chunk allocation과 metadata 준비만 끝낸 뒤 Copy worker에 넘기고, Eviction은 free chunk가 부족해진 뒤 반응적으로 실행되는 대신 dedicated thread에서 proactive하게 실행된다. 이 구조는 Populate의 긴 latency를 다른 작업 뒤에 숨기는 것이 목적이다.

; Sharing Degree-aware eviction
: ARIADNE는 fault recency만 보는 eviction queue 대신 Sharing Degree를 반영한 priority key를 사용한다. 논문이 제시한 형태는 <code>last fault time + SD Weight * Sharing Degree / Nfault_history</code>이며, 구현에서는 fault history 길이 16과 SD Weight 100 us를 사용한다. Sharing Degree가 높은 VABlock은 GPU memory에 남길 가치가 높다고 보고 eviction priority를 낮춘다.

; Dynamic Zero-copy
: Memory demand가 GPU capacity를 넘으면 ARIADNE는 evicted 뒤 재접근된 VABlock을 즉시 GPU로 refetch하지 않고 100 ms 동안 Zero-copy state로 유지한다. 이 second-chance policy는 방금 쫓겨난 sparse VABlock이 다시 fault를 내며 eviction-refetch cycle을 만드는 것을 줄인다. 100 ms가 지나도록 재사용되지 않으면 Zero-copy state를 해제하고, 이후에도 계속 재사용되면 GPU memory로 promote될 수 있다.

; Dynamic prefetching
: Copy 단계에서는 기본 UVM prefetcher가 선택한 page를 복사하되, GPU memory 여유가 충분하거나 VABlock의 Sharing Degree가 threshold보다 높으면 VABlock 전체를 적극적으로 copy한다. 논문 구현의 Sharing Degree threshold는 3이다. 이 정책은 dense VABlock에 대해서는 future fault를 줄이고, sparse VABlock에 대해서는 불필요한 2 MB migration을 피하려는 tradeoff를 갖는다.

== Result ==
평가는 NVIDIA RTX A5000, AMD Ryzen 7700X, PCIe 4.0 x16, 64 GB DDR5, Linux 6.0, NVIDIA open-source kernel driver 535.86 환경에서 수행되었다. Workload는 Rodinia, Polybench, HeCBench, XSBench에서 가져온 10개 benchmark(2DC, ATAX, BICG, GEMM, GEMV, MVT, XSB, BFS, HEL, NW)이며, 각 benchmark의 memory footprint는 4 GB로 맞추었다. Oversubscription ratio는 no oversubscription, 130%, 175%, 300%를 사용한다.

Baseline UVM은 oversubscription에서 급격히 무너진다. 논문은 baseline UVM의 geomean execution time이 200% oversubscription에서 33.2배, 300%에서 60.7배까지 증가한다고 보고한다. AC(access counter-based migration)는 Zero-copy를 활용해 thrashing을 줄이지만 no oversubscription에서는 평균 1.3배, 최대 2.5배 느려지고, 210%와 300% oversubscription에서는 no oversubscription 대비 각각 4.7배와 8.9배 느려진다.

ARIADNE는 AC 대비 130%, 175%, 300% oversubscription에서 각각 1.9배, 2.3배, 4.0배 geomean speedup을 보인다. SUV 대비로는 같은 oversubscription ratio에서 각각 1.9배, 5.0배, 4.8배 speedup을 보인다. 또한 no-oversubscription 대비 runtime 증가는 130%, 175%, 300%에서 각각 1.6배, 1.8배, 2.3배로 보고되어, 논문은 near-linear degradation이라고 해석한다.

Mechanism-level evidence도 제시된다. Pipelined VABlock fault handling은 10개 benchmark에서 VABlock fault handling latency를 평균 17%, 최대 48%(BFS) 줄인다. Dynamic VABlock placement는 175% oversubscription에서 AC 대비 PCIe traffic을 평균 51% 수준으로 낮춘다. Breakdown에서는 Sharing Degree 기반 placement/eviction이 핵심 성능 요인이고, pipelining이 oversubscription 상황에서 정책 overhead를 숨기는 역할을 한다고 해석된다.

LLM inference 실험도 포함된다. Llama3.1 70B inference(input token length 2048)에서 ARIADNE는 AC 대비 Decode phase 4.2배, Prefill phase 1.6배 speedup을 보인다. Decode가 GEMV 중심이기 때문에 GEMV benchmark에서 큰 이득을 보인 결과와 일관된다고 설명한다.

Overhead는 작다고 보고된다. Additional metadata는 VABlock당 70 B 미만, GPU당 100 B 미만이며, 16 GB application 기준 약 560 KB이다. Sharing Degree/WCSS tracking과 Zero-copy process의 추가 latency는 최대 100 ns로, 단일 VABlock fault handling 약 20 us에 비해 무시 가능하다고 주장한다.

== Contribution ==
# UVM oversubscription에서 성능 저하의 원인을 Populate-dominated fault handling latency, 2 MB chunk granularity에 따른 WCSS amplification, last-fault-time eviction에 따른 thrashing으로 정리하였다.
# GPU thread execution architecture와 source uTLB ID를 이용해 VABlock-level spatial locality를 runtime에서 추정하는 Sharing Degree metric을 제안하였다.
# Sharing Degree와 WCSS를 기반으로 VABlock을 GPU memory와 Zero-copy 사이에서 동적으로 배치하는 runtime-only UVM management framework ARIADNE를 설계하였다.
# Populate, Copy, Eviction을 VABlock 간 pipeline으로 분리하여 UVM fault handling latency를 줄이는 driver-level execution structure를 구현하였다.
# NVIDIA open-source UVM driver 내부 수정 약 1600 LOC만으로 구현하고, hardware/compiler/application modification 없이 executable 또는 closed-source UVM application에 적용 가능한 설계를 보였다.
# 10개 GPU benchmark와 Llama3.1 70B inference에서 AC, SUV, baseline UVM 대비 성능 향상과 oversubscription scaling을 실험적으로 제시하였다.

== Criticisms ==
# Sharing Degree는 source uTLB ID를 thread group locality의 proxy로 사용하는 metric이다. 논문은 benchmark에서 utilization과의 상관을 보이지만, uTLB sharing topology, SM scheduling, phase behavior가 다른 GPU generation에서 threshold 3, history length 16, SD Weight 100 us, Zero-copy pin time 100 ms가 항상 좋은지는 제한적이다. 약간 fine-tuning되어 있는 값처럼 보이는 경향이 있다.
# 전체적으로 논문이 Collection of fine-tuned optimization으로 보이는 경향이 있다. 그러나 논문에서 제시되는 Sharing Degree와 같은 개념은 좋은 Design point이기 떄문에, Collection-of-optimizations으로 보는 것이 오히려 불필요하게 Critical한 Review일 수 있을 것 같다는 생각도 든다. 이런 Optimization work의 숙명일 수도....
# no-oversubscription 또는 memory pressure가 낮은 일부 case에서는 SUV가 ARIADNE보다 빠르다. 논문은 SUV의 compile-time range prefetching이 ARIADNE의 2 MB VABlock granularity prefetch보다 큰 data range를 미리 가져올 수 있기 때문이라고 설명한다. 즉 ARIADNE는 transparency를 얻는 대신 static program knowledge를 활용한 aggressive prefetch opportunity를 일부 잃는다.

== [[Conclusion]] ==
이 연구는 GPU UVM oversubscription을 단순 page fault overhead가 아니라 VABlock placement와 GPU thread-level locality를 함께 다루어야 하는 문제로 바라보게 만든다. ARIADNE는 source uTLB 기반 Sharing Degree, WCSS estimation, Sharing Degree-aware eviction, transient Zero-copy, pipelined fault handling을 결합하여 hardware/compiler/application 수정 없이 oversubscription 성능을 개선할 수 있음을 보였다.

[[분류: 시스템 논문]]
[[분류: IEEE HPCA]]
[[분류: GPU Unified Virtual Memory]]