noriwiki - 최근 바뀜 [ko]

GPU Memory Architecture

2026-10-13T08:20:38Z

← 이전 판		2026년 10월 13일 (화) 08:20 판
1번째 줄:		1번째 줄:
	[[분류: GPU]]		[[분류: GPU Memory Management]]

	== 개요 ==		== 개요 ==

분류:GPU Memory Management

2026-10-13T08:20:01Z

새 문서: 분류: GPU

새 문서

[[분류: GPU]]

RAPIDS Memory Allocator

2026-10-13T08:19:51Z

← 이전 판		2026년 10월 13일 (화) 08:19 판
(같은 사용자의 중간 판 하나는 보이지 않습니다)
1번째 줄:		1번째 줄:
	[[분류: GPU ~~아키텍쳐~~]]		[[분류: GPU Memory Management]]

	== 개요 ==		== 개요 ==

RAPIDS Memory Allocator

2026-10-13T08:17:48Z

새 문서: 분류: GPU 아키텍쳐 == 개요 == RAPIDS Memory Manager(RMM)는 High-frequency memory allocation/deallocation에서 발생하는 병목현상을 줄이고, 다양한 메모리 할당 전략을 제공하는 Memory management library이다. Pooling을 사용하는 경우, 큰 메모리 영역을 확보한 뒤 개별 Allocation 요청에 따라 Suballocation하고 재사용함으로써 <code>cudaMalloc</code>이나 <code>cudaFree</code>의 호출 빈도와 관련 Overhead...

새 문서

[[분류: GPU 아키텍쳐]]

== 개요 ==
RAPIDS Memory Manager(RMM)는 High-frequency memory allocation/deallocation에서 발생하는 병목현상을 줄이고, 다양한 메모리 할당 전략을 제공하는 Memory management library이다. Pooling을 사용하는 경우, 큰 메모리 영역을 확보한 뒤 개별 Allocation 요청에 따라 Suballocation하고 재사용함으로써 <code>cudaMalloc</code>이나 <code>cudaFree</code>의 호출 빈도와 관련 Overhead를 줄인다.

RMM은 공통된 Memory resource interface를 통해서 단순한 CUDA Allocation부터 Pooling, 크기별 Allocation, Logging 등 다양한 방식을 선택하고 조합할 수 있도록 한다.

== 배경 ==
GPU workflow를 최적화하기 위해서는 Host와 Device memory의 할당 방식도 함께 고려해야 한다. 예를 들어서 빈번한 Device memory allocation의 비용을 줄이기 위해 Memory pool을 사용하거나, 비동기 Host-device memory transfer를 위해 Pinned host memory를 사용할 수 있다.

더 나아가서 Memory diagnostics, logging, leak detection, profiling, debugging 등의 기능을 메모리 할당 과정에 적용할 필요가 있다. 이러한 기능을 각각 구현하기보다는 공통된 Memory allocation interface를 통해서 제공하면 메모리 관리를 쉽게 확장할 수 있다.

RMM은 이런 환경에서 Device와 Host memory allocation을 쉽고 효과적으로 Customizing할 수 있는 Interface와 이를 사용하는 자료구조를 제공한다. RMM은 이미 [[NVIDIA]] [[RAPIDS 라이브러리]] 전반에 걸쳐서 사용되고 있다.

== 내부 구조 ==
=== Stream-ordered Memory Allocation ===
RMM은 Stream을 인자로 받는 Allocation과 Deallocation interface를 제공한다. 전통적인 <code>cudaMalloc</code>과 <code>cudaFree</code>는 Stream을 인자로 받지 않으며, 특히 <code>cudaMalloc</code>으로 할당한 메모리를 <code>cudaFree</code>로 해제하는 과정에서는 Device 전체의 Synchronization이 발생할 수 있다.

Stream-ordered allocation은 메모리의 할당, 사용, 해제, 재사용 순서를 Stream의 실행 순서와 연결한다. 같은 Stream에서는 앞선 작업이 끝난 뒤 다음 작업이 실행되므로, 해제된 메모리를 재사용할 때 별도로 Stream 전체가 끝나기를 기다리는 Synchronization을 피할 수 있다. 즉, 매번 해당 Stream을 Synchronize하는 방식이 아니라 Stream ordering을 이용해서 불필요한 동기화를 줄이는 방식이다.

=== Suballocation in RMM ===
RMM은 여러 종류의 Suballocator를 제공한다. Suballocator는 Upstream memory resource에서 큰 메모리 영역을 확보한 뒤, 이를 작은 영역으로 나누어서 개별 Allocation 요청을 처리한다. 따라서 매번 CUDA Allocation을 수행하지 않고도 Pool 내부에서 메모리를 할당하고 재사용할 수 있다.

<code>pool_memory_resource</code>는 Coalescing best-fit 방식의 Suballocator이다. 메모리가 Free되면 주소상 인접한 Free block들과 병합해서 Fragmentation을 줄인다. 또한 Stream마다 Free list를 관리해서 같은 Stream에서 해제된 Block을 동기화 없이 재사용할 수 있도록 한다. 해당 Stream의 Free list에 충분한 크기의 Block이 없으면 다른 Stream의 Free list를 검색할 수 있으며, 이 경우 Event를 통해서 필요한 실행 순서를 보장한다. 따라서 Stream마다 완전히 독립된 Pool이 존재한다기보다는, 재사용 가능한 Block을 Stream별 Free list로 관리한다고 보는 것이 정확하다.

<code>binning_memory_resource</code>는 Allocation 크기에 따라 서로 다른 Memory resource로 요청을 전달한다. 예를 들어서 작은 Allocation은 <code>fixed_size_memory_resource</code>로 처리하고, 큰 Allocation은 Upstream memory resource로 전달하는 Hybrid approach를 구성할 수 있다.

<code>arena_memory_resource</code>는 Global arena와 Default stream을 위한 Per-thread arena, Non-default stream을 위한 Per-stream arena를 사용한다. 각 Local arena는 Global arena에서 Superblock 단위로 메모리를 받아서 관리한다. 작은 Allocation은 Local arena에서 처리하고 큰 Allocation은 Global arena를 활용하는 방식으로, 여러 Thread와 Stream이 함께 사용하는 환경에서 동시성과 Fragmentation을 고려한다.

대문

2026-10-13T05:42:53Z

← 이전 판		2026년 10월 13일 (화) 05:42 판
22번째 줄:		22번째 줄:
	✉️ junhoahn@kaist.ac.kr <br>		✉️ junhoahn@kaist.ac.kr <br>
	<div class="home-link__button">[https://sites.google.com/view/junhoahn/ Curriculum Vitae]</div>		<div class="home-link__button">[https://sites.google.com/view/junhoahn/ Curriculum Vitae]</div>
			<div class="home-link__button">[https://tech.junhoahn.kr/ Tech Blog]</div>
	</div>		</div>
	</div>		</div>

Scalable Address Spaces using Concurrent Interval Skiplist

2026-10-12T10:02:18Z

@@ 36번째 줄: / 36번째 줄: @@
 == Main Idea ==
-핵심은 주소 구간의 '''검색과 잠금 획득을 한 자료구조의 연속된 동작으로 통합'''하는 것이다. Concurrent interval skiplist는 각 node와 뒤따르는 gap을 잠그면서 필요한 구간을 찾아가므로, map을 먼저 읽고 별도의 range lock을 나중에 잡는 사이의 race를 피한다. 겹치지 않는 구간의 갱신은 병렬로 진행하고, lock-free Query를 위해 여러 node의 교체는 [[Read-copy-update|RCU]] 방식으로 한 번에 commit한다(§4).
+기존의 Address Space는 다음 세개의 Operation만을 제공하였다.
-이를 실제 kernel 주소 공간으로 확장하려면 전역 작업에는 별도의 per-core lock 층을 쓰고, Alloc은 core별 arena로 분산하며, 엄격한 resource limit을 유지하는 counter도 분산해야 한다(§5). 즉 skiplist가 핵심이지만, 성능 개선은 이 주변 메커니즘을 함께 적용한 결과다.
+== Design ==
-== Design ==
+; Two-level Locking for Hybrid Granularity
-# '''Concurrent interval skiplist (§4):''' 기존 interval map의 Query·Map·Alloc에 Lock·Unlock·Swap을 더한다. Lock은 predecessor부터 대상 node와 gap을 순차적으로 잠근다. level-0 link의 <code>LOCKED</code> 표시가 node와 뒤따르는 gap을 보호하므로, 인접한 VMA나 빈 구간을 함께 다뤄야 하는 Modify에도 적용된다. Skip link는 탐색을 빠르게 하되 잠금은 level 0에서만 수행한다.
+: 전체 Address space를 보호하는 Global read/write(GR/GW)와 특정 interval을 보호하는 Local read/write(LR/LW)를 제공한다. 이를 위해 per-core read-write lock을 두고, Global operation은 모든 core의 lock을 획득하며 Local operation은 현재 core의 lock과 필요한 skiplist interval lock을 획득한다. 이를 통해서 fork, exit과 같은 operation에서 모든 VMA의 lock을 개별적으로 획득하는 오버헤드를 줄이면서, 서로 다른 interval의 operation은 병렬로 실행할 수 있다.
-# '''원자적 다중 node 갱신과 Query (§4):''' Map/Swap은 새 node들을 준비한 후 predecessor link를 CAS로 바꾸어 교체를 commit하고, 옛 node를 <code>INVALIDATED</code>로 표시한다. Query는 잠금 없이 전·후 상태 중 하나를 읽도록 설계한다. 높은 skiplist level의 link는 교체 전후에 묶어서 정리·삽입한다. 이 방식은 구간 전체를 잠그지 않고도 여러 VMA에 걸친 갱신을 처리하지만, tree보다 Query의 cache locality가 나쁠 수 있다.
-# '''전역/국소 2단계 잠금 (§5.1):''' global read/write(GR/GW)는 모든 per-core RW lock을 잡고, local read/write(LR/LW)는 실행 core의 lock과 해당 skiplist interval lock을 잡는다. 따라서 <code>fork()</code>·<code>exit()</code> 같은 전역 작업에서 모든 VMA lock을 열거할 필요가 없고, 겹치지 않는 국소 작업은 병렬 실행된다. 지원하지 않는 일부 경로는 전역 lock으로 fallback한다.
+; Page Fault
-# '''Fault·Alloc·Modify 경로 (§5.2–5.4):''' Fault는 가능한 경우 주소 공간 lock 없이 시도하고, page table 생성·VMA 초기화 등 동기화가 필요하면 LR, 예외적 file-backed 경로에서는 GR로 진행한다. Alloc은 새 VMA를 삽입 전에 준비하고 CAS 삽입으로 commit한다. <code>munmap()</code>·<code>mprotect()</code> 등의 Modify는 동적으로 확인한 구간을 LW로 잠그며, 미적응 경로에서는 GW를 사용한다.
+: 먼저 Address space lock 없이 page fault를 처리하도록 시도한다. 이때 다른 interval의 update로 인한 불필요한 abort를 줄인다. 새로운 page table의 할당이나 VMA 초기화, file system과의 동기화가 필요하면 LR mode와 interval lock을 획득하여 처리한다. 이 방식으로 처리할 수 없는 일부 file-backed memory 경로에서는 GR mode로 fallback한다.
-# '''분산 Alloc과 제한 계수 (§5.3):''' 각 core는 우선 자기 64 GiB arena에서 빈 공간을 찾는다. Separator node와 계층화한 skiplist level이 arena 간 skip-link 간섭을 줄이고, arena hint는 해제된 공간의 재사용을 돕는다. Resource counter는 per-core batch를 사용하다가 limit에 가까워지면 global counter 직접 갱신으로 전환하여 strict limit을 지킨다. 구현에서 최대 128개 arena는 256 TiB 주소 공간의 4% 미만을 차지한다.
 == Result ==
@@ 60번째 줄: / 99번째 줄: @@
 |}
-== Contribution ==
+[[분류:ACM SOSP]]

파일:SOSP 2025 Skiplist Figure 8.png

2026-10-12T07:11:53Z

Ahn9807님이 파일:SOSP 2025 Skiplist Figure 8.png 파일을 올렸습니다

새 문서

SOSP 2025 Skiplist Figure 8

Scalable Address Spaces using Concurrent Interval Skiplist

2026-10-12T06:31:14Z

@@ 10번째 줄: / 10번째 줄: @@
 == Motivation ==
-Linux 6.8.0은 per-VMA locking으로 많은 page fault를 갱신과 병렬 실행할 수 있지만, 주소 공간을 할당하는 Alloc과 기존 mapping을 바꾸는 Modify는 여전히 <code>mmap_lock</code>을 write mode로 잡는다. 다중 arena를 사용하는 [[Memory allocator]]와 file-backed mapping을 많이 여닫는 응용에서는 이 직렬화가 커진다. 논문의 lockstat 측정에서 높은 thread 수의 <code>mmap_lock</code> 대기 시간 비율은 Apache 최대 90%, Metis 60%, Psearchy 41%, LevelDB 40%에 이른다(Fig. 1).
+Linux 6.8.0은 per-VMA locking으로 많은 page fault를 갱신과 병렬 실행할 수 있지만, 주소 공간을 할당하는 Alloc과 기존 mapping을 바꾸는 Modify는 여전히 <code>mmap_lock</code>을 write mode로 잡는다. 다중 arena를 사용하는 [[Memory allocator]]와 file-backed mapping을 많이 여닫는 응용에서는 이 직렬화가 커진다. 논문의 lockstat 측정에서 높은 thread 수의 <code>mmap_lock</code> 대기 시간 비율은 Apache 최대 90%, Metis 60%, Psearchy 41%, LevelDB 40%에 이른다고 한다.
-단순한 range lock 교체도 어렵다. 작업 대상 구간과 VMA 또는 page table의 경계가 일치하지 않아 실제 잠글 범위가 현재 mapping 상태에 따라 바뀐다. 예를 들어 <code>munmap()</code>은 빈 page table을 안전하게 해제하려면 이웃한 gap까지 보호해야 한다(Fig. 3–4). 먼저 map을 탐색하고 나중에 range를 잠그면 그 사이의 갱신으로 탐색 결과가 낡을 수 있다.
+== Challenges ==
 == Main Idea ==
@@ 50번째 줄: / 71번째 줄: @@
-[[분류: ACM SOSP]]
+[[index.php?title=분류:ACM SOSP]]