GPU VRAM, 이제 스왑 공간으로 활용 가능!

해당 프로젝트는 NVIDIA GPU의 VRAM을 리눅스 스왑 공간으로 활용하는 독창적인 접근 방식을 제시합니다. 특히 노트북 환경에서 업그레이드가 어려운 경우, 유휴 VRAM을 활용하여 시스템의 주소 가능 메모리(Addressable Memory)를 확장하는 것을 목표로 합니다. RAM이 가득 차면 VRAM으로, 그 다음에는 zram으로, 마지막으로 SSD로 스왑하는 계층적 구조를 통해 성능 저하를 최소화하려 합니다. 이는 데이터 격리 아키텍처(Data Isolation Architecture)를 VRAM 레벨에서 구현한 사례로 볼 수 있습니다.

이 솔루션은 CUDA 드라이버 API를 사용하여 VRAM을 할당하고, NBD(Network Block Device) 프로토콜을 통해 이를 블록 디바이스로 노출시키는 방식을 사용합니다. 커널 모듈이나 NVIDIA 커널 심볼 없이 작동하며, 커널 및 드라이버 업데이트에도 유연하게 대응할 수 있다는 장점이 있습니다. 이는 기존의 데이터 미저장 정책(Zero-Retention Policy)을 유지하면서도 스왑 성능을 개선하려는 시도로 해석됩니다. 다만, PCIe 대역폭(Bandwidth) 대비 약 1.3 GB/s의 순차 처리량(Sequential Throughput)은 기대보다 낮다는 지적이 있습니다.

개발자는 NVIDIA P2P API를 사용하려 했으나, 소비자용 GeForce GPU에서는 `EINVAL` 오류가 발생하는 한계를 경험했습니다. Quadro/데이터센터 SKU에만 제한적으로 지원되는 이 API 대신, NBD 접근 방식을 선택한 것입니다. 직접 BAR1 물리 주소를 `ioremap_wc`하는 시도 역시 GPU 내부 페이지 테이블의 제한으로 실패했습니다. 이러한 제약 사항은 하드웨어 아키텍처(Hardware Architecture)의 특성과 드라이버 정책이 기술 구현에 미치는 영향을 보여줍니다.

커뮤니티에서는 1.3 GB/s의 순차 처리량이 PCIe 4.0 x16의 64 GB/s나 GDDR6의 448 GB/s에 비해 현저히 낮다는 점을 지적합니다. 또한, 실제 사용 시나리오에서는 랜덤 읽기/쓰기 속도(Random Read/Write Speed)가 더 중요할 수 있다는 의견이 제기되었습니다. 일부 사용자는 AI 모델 학습 등 VRAM을 많이 사용하는 워크로드에서는 오히려 성능 저하를 유발할 수 있다고 우려하며, 동적 VRAM 활용(Dynamic VRAM Utilization) 및 백프레셔(Backpressure) 관리의 중요성을 강조했습니다.

과거 Windows 환경에서 VRAM을 활용한 유사한 드라이버가 존재했으며, AMD GPU 지원을 위한 포크(Fork)도 언급되었습니다. 또한, 리눅스의 MTD/phram 드라이버나 OpenCL 기반의 FUSE 파일 시스템 구현 등 기존 기술과의 연관성도 논의되었습니다. 이러한 논의는 GPU 메모리 활용에 대한 지속적인 관심과 다양한 기술적 접근이 시도되어 왔음을 시사합니다. 다만, Wayland 환경에서의 동적 할당 문제나 GPU 드라이버 충돌 가능성 등은 해결해야 할 과제로 지적됩니다.