주소 체계가 같다고 접근 권한까지 같은 것은 아닙니다
UVA(Unified Virtual Addressing)는 한 프로세스의 CPU·GPU 할당을 공통 가상 주소 체계에서 식별하게 합니다. 모든 포인터를 모든 실행 주체가 바로 역참조할 수 있다는 보장은 아닙니다. Unified Memory는 CPU와 GPU가 접근하는 메모리를 관리하는 기능이며, 관리 대상·이동·일관성 유지 방식은 장치와 운영체제에 따라 달라집니다.
- 주소
어떤 할당을 가리키는 포인터인가?
- 접근과 위치
누가 접근할 수 있고, 데이터는 어느 메모리에 있는가?
- 일관성
CPU·GPU 사이의 변경을 어떤 방식으로 일치시키는가?
- 순서
생산자의 쓰기와 소비자의 읽기를 무엇으로 연결하는가?
위 네 항목은 점검 순서를 나타낸 개념도이며 실제 페이지 이동이나 캐시 구조도가 아닙니다.
GPU 이름보다 세 가지 속성을 먼저 확인합니다
cudaDevAttrConcurrentManagedAccess가 0이면 제한된 Unified Memory 모델입니다. 1인 경우 cudaDevAttrPageableMemoryAccess가 0인지 1인지에 따라 명시적 managed 할당만 지원하는지, 일반 시스템 할당까지 지원하는지 구분합니다. 두 값이 모두 1일 때 cudaDevAttrPageableMemoryAccessUsesHostPageTables는 소프트웨어 방식(0)과 하드웨어 방식(1)을 구분합니다.
HMM은 Linux의 소프트웨어 기반 메모리 관리 경로이고, CUDA 가이드의 ATS 기반 모델은 지원되는 CPU·GPU 플랫폼의 하드웨어 기능을 이용합니다. 같은 제품군 이름이나 UVA 지원만으로 HMM·ATS·동시 접근 지원을 추정하지 않습니다. 실제 장치별 속성, 드라이버·운영체제와 할당 종류를 함께 기록합니다. 이 글은 특정 GPU에서 속성을 측정하거나 전송 성능을 비교한 결과가 아닙니다. 지원 모델과 플랫폼별 제약
캐시 일관성이 데이터 경쟁을 없애지는 않습니다
일관된 메모리라도 생산자가 쓰는 중에 소비자가 같은 데이터를 동기화 없이 읽으면 안전하지 않습니다. atomic의 대상 객체, memory order, 참여 스레드를 포함하는 scope를 함께 정해야 합니다. GPU block 내부와 장치 전체, CPU를 포함하는 system scope는 서로 다른 범위입니다.
thread_scope_system을 적는 것만으로 모든 할당의 원자성이 보장되지는 않습니다. 일반 시스템 메모리는 pageableMemoryAccess, managed 메모리는 concurrentManagedAccess, mapped 메모리의 일반적인 원자 연산은 hostNativeAtomicSupported 등 조건을 대조합니다. 정렬된 mapped load/store, GPU 전용 접근 및 peer atomic 지원에는 별도 규칙이 있습니다. 파일 매핑·hugetlbfs와 tensor reduction에도 예외가 있으므로 이 목록을 전체 지원표로 사용하지 않습니다. CUDA C++ 메모리 모델의 원자성 조건
도메인은 fence가 기다리는 범위를 나눕니다
CUDA 12의 memory synchronization domain은 compute capability 9.0부터 지원됩니다. 서로 무관한 메모리 트래픽 때문에 fence가 지나치게 기다리는 간섭을 줄이기 위한 기능입니다. 같은 GPU라도 서로 다른 도메인 사이에 순서가 필요하면 system-scope 동기화가 필요합니다. device scope의 관계는 같은 장치이면서 같은 도메인인 스레드 사이입니다.
도메인을 나눴다고 해서 의존 관계가 사라지거나 동기화가 자동으로 추가되지는 않습니다. 먼저 데이터의 생산자·소비자와 필요한 순서를 확인하고, 그 뒤 실제 플랫폼에서 간섭과 비용을 측정합니다. Memory Synchronization Domains