GPU 컴퓨팅에서 빠른 데이터 전송을 위한 메모리 피닝 자동 관리

요약

엔비디아 CUDA 프로그래밍 모델은 CPU 호스트에서 GPU에서 실행될 인풋 데이터를 만들어 GPU로 보낸다. 이 불가피한 CPU-GPU 데이터 전송에 소요되는 시간이 실제 커널이 돌아가는 시간에 비해 너무 그 비중이 크다. 이 커뮤니케이션 시간을 최소화하기 위해 pinned 메모리를 이용한 해결책이 제시되어 있지만 그 활용법은 사용자가 직접 pinned 메모리를 지정해주어야 하는 수준에 머무르고 있다. 이전 연구에서 밝혀진 어느 정도 이상의 데이터 전송일 때 메모리 pinning이 이점을 가지는지에 대한 데이터들은 최신 아키텍처에서는 더이상 맞지 않아 사용자들의 pinned 메모리 활용을 더욱 힘들게 하고 있다.
본 연구에서는 pinned 메모리를 활용하면 TitanV 모델에서는 기존의 16MB의 데이터보다 더 작은 2MB의 데이터에서도 전송시간의 2.5배의 성능향상이 있는 것을 밝혀냈으며, 이 별도의 데몬이 pinned 메모리를 관리하여 데이터 전송을 극대화하는 방법을 제시한다.
 

---

1. 서론

CUDA의 경우 데이터 전송을 위해 두 가지 기법을 사용한다.
▶ 더블 버퍼링 기법: 두 개의 버퍼들을 pinning해 사용해 디바이스에서 안정적으로 호스트의 주 메모리에 접근하는 기법
▶ 목표 데이터의 메모리 영역 전체를 pinning해서 직접 디바이스가 접근하게 하는 방법
 
CUDA에서 해당 기법들의 세부적 동작을 알기 위해 분석한 결과 메모리를 pinning하는데 내부적으로 os_lock_user_pages() 함수를 사용하는 것으로 밝혀졌다. 이 함수는 CUDA 라이브러리를 사용하는 프로그램이 실행되면, 더블 버퍼링을 위한 두 개의 버퍼들을 할당하기 위해 총 두 번 부른다. 이 버퍼들의 가상 메모리 주소는 모든 프로세스마다 일정하고, 물리 메모리 주소는 무작위이다. 위의 함수를 좀 더 분석하면, 먼저 kmalloc()이나 vmalloc()을 이용해 버퍼들을 할당하고, 할당한 영역들을 리눅스 커널 함수인 get_user_pages()을 이용해 실질적으로 pinning한다.
 
대부분의 시스템들은 PCIe 대역폭과 호스트 주 메모리 복사 대역폭 간의 불균형이 존재한다. CUDA의 초창기에 불균형이 두드러지지 않았지만, 현재는 PCIe 대역폭이 향상된 반면, 복사 대역폭의 경우 따라가지 못했고, 더블 버퍼링을 사용하는 경우 PCIe 대역폭을 최대로 활용하지 못한다.정리하자면, 더블 버퍼링의 경우, PCIe 대역폭이 복사 대역폭보다 빠른 경우, PCIe 최대 대역폭을 사용하지 못하고 대기하는 구간이 나타난다.
 
이 문제를 해결하기 위해서는 위에서 언급한 다른 기법인 목표 메모리 영역 자체를 pinning해 디바이스가 직접 접근해야 한다.
그러나 이 기법도 한계점이 분명한데, 많은 메모리의 영역을 pinning한다면, 시스템에서 사용할 수 있는 메모리 양이 적어져 시스템 성능 저하를 유발하고, pinning한 영역을 관리하는 로직이 존재하지 않아 사용자가 수동으로 할당하고 해제하는 방식이기 때문에, 프로세스 상에서 불필요한 pinning을 자동으로 해제할 방법이 존재하지 않는다.
 
그래서 본문에서는 두 번째 기법을 기반으로 데이터 전송 방식을 향상시키고자 한다. 먼저 모든 호스트 주 메모리상에 존재하고 디바아스가 사용할 데이터를 모두 pinning하고, 시스템에서 가용 메모리 부족으로 페이지 폴트가 많이 발생한다면, 백그라운드에서 동작하는 데몬을 통해 자동으로 pinning을 해제하는 방식을 사용할 것이다.
 
 

2. 메모리 피닝 관리 기법

대역폭들의 불균형을 맞추기 위해 나온 사용자가 할 수 있는 최적화 기법들이 많지 않다. 
▶ 옮기는 데이터 양의 최소화
▶ 분할되어 있는 데이터 전송의 병합
▶ 데이터 전송과 커널 실행의 오버랩
▶ pinned 메모리의 활용
 
pinned 메모리를 활용하면 메모리가 스토리지로 swap되지 않는다. 
pinned 메모리를 사용하면 pinned 메모리 자체에서 얻을 수 있는 데이터 전송시간의 절약에 더불어 커널의 비동기 실행이 가능하기 때문에, pinned 데이터는 CUDA 프로그램에서 아주 중요한 역할을 맡을 수 있다.
 
이에, 메모리 pinning을 자동화하는 데몬을 만들에 데몬이 전체 CUDA 프로그램에서 사용하는 메모리들을 관리하는 기법을 제안한다.데몬을 엔비디아 드라이버에 구현하자면 커널 모드에서 수행이 가능하기 때문에 swap된 페이지들의 개수를 모니터할 수 있다. 드라이버에서 구현하지 않고, <deamon.h> 라이브러리를 만들어 별개의 쓰레드에서 돌아가는 방법이 연구자들이 실제 구현을 할 수 있는 방법이다. 
 
데몬을 CUDA 프로그램에 포함시키면 library interpositioning을 하여 호스트의 주 메모리 공간을 할당하는 malloc()을 CUDA 라이브라리 내에서 pinning하는 cudaHostAlloc()으로 전부 바꾸어, 처음부터 할당하는 모든 메모리들을 pinned 메모리로 만든다. 
 
기본 메모리 할당을 pinned 메모리로 하게 되면 생기는 문제점이 같은 머신에서 돌아가는 다른 프로세스들에게 가용한 메모리의 용량이 줄게 되고, 커널 내부의 메모리 알로케이터도 해당 메모리가 pinned 되었는지 실제 할당을 시도하기 전에는 모르기 때문에 메모리 allocating 실패도 많아진다. 이 문제를 최소화하기 위해 커널 내에 시스템 함수를 따로 만들어 page swap의 개수를 모니터링하여 데몬이 동작하도록 한다. 시스템 구성에 맞추어 high, low watermark를 지정하여 페이지 swap이 hgith watermark 이상으로 올라가면 데몬을 실행해서 pinned 메모리를 풀어 pageable 메모리로 전환을 하고, 페이지 swap의 수가 low watermark 이하로 내려가면 다시 데몬이 메모리들을 pinning하도록 한다.
 
이 방법의 쟁점에는 두 가지 이슈가 있다.▶ High watermark와 low watermark를 어떻게 정해야 하는가?High watermark와 low watermark를 정하는 이슈에 대해서는 CUDA 프로그램이 돌아가는 하드웨어의 구성에 따라 많이 달라질텐데, 그 중에서도 주 메모리의 크기와 다른 프로세스들의 개수가 가장 영향을 끼치는 요인들이다. 
 
▶ 어떤 pinned 메모리를 풀어야 프로그램이 문제없이 그대로 작동하는가?
본고에서 언급하는 pinned 메모리는 정말 PCIe를 오고가는 데이터들의 속도를 높이기 위해 메모리 pinning을 하는 것이지, 디바이스에서 직접 접근하여 호스트 메모리의 연장선으로 쓰기 위함이 아니다. 따라서 Zero copy가 아닌 이상, 커널의 비동기 실행이 되지 않는 메모리들은 전부 메모리 pinning을 해제해도 프로그램 동작에 영향을 주지 않는다. 소프트웨어 분석을 통해 데이터 전송이 잦은 메모리들을 메모리 pinning을 해제하는 우선순위에서 미루는 것이 성능향상에 도움이 된다.
 
 

3. 결론

▶ Problem: CPU-GPU 이기종 환경에서의 데이터 전송 지연
 
▶ Solution: 
1) 목표 데이터의 메모리 영역 전체를 pinning한다.
2) High/Low watermark를 통해 메모리 pinning을 자동화하는 데몬을 만들어, 데몬이 전체 CUDA 프로그램에서 사용하는 메모리를 관리하도록 한다.
<deamon.h> 라이브러리를 통해 데몬은 별개의 쓰레드에서 돌아가고, 이렇게 커널 모드에서 수행하는 데몬은 swap된 페이지들의 개수에 접근할 수 있다. 따라서 High/Low watermark의 실행이 가능하게 되는 것이다.
High/Low watermark에 의거하여 어떤 pinned 메모리를 풀어야 하는가에 대한 이슈가 있다. 하지만 여기서 pinned 메모리는 데이터 전송 속도를 높이기 위한 것뿐이기 때문에, zero copy가 아닌 이상, 커널의 비동기 실행이 되지 않는 메모리들은 전부 메모리 pinning을 해제해도 된다. 따라서 소프트웨어 분석을 통해 데이터 전송이 잦은 메모리들을 메모리 pinning을 해제하는 우선순위에서 미루는 것이 성능 향상에 도움이 된다.
 
 
 
 
 
https://www.dbpia.co.kr/pdf/pdfView.do?nodeId=NODE07613995&googleIPSandBox=false&mark=0&ipRange=false&accessgl=Y&language=ko_KR&hasTopBanner=true 

DBpia