[Article] Zorua: A Holistic Approach to Resource Virtualization in GPUs (Micro 2016)

Zorua는 2016년 MICRO (홈페이지)에 발표된 논문이다. 논문을 읽고 내용을 정리해 보았다.

Motivation

Thread Block (Cooperative Thread Array, CTA)는 thread의 묶음을 의미한다. 하나의 thread block은 보통 수십 또는 수백 개의 thread를 포함한다. Thread block은 GPU의 SM에 스케줄링 되는 최소단위이다. 한 SM에 총 실행 가능한 thread block의 개수는 크게 아래의 3가지 이유로 결정된다.

• Thread의 register 사용량 (SM의 register 크기)
• Thread block의 scratchpad memory 사용량 (SM의 scratchpad memory 크기)
• Thread block의 thread 개수 (SM에서 실행가능한 thread의 개수)

위의 3개 제한으로 인해서 SM에 실행되는 thread block의 개수가 달라진다. 각 thread의 register 사용량, thread block의 scratchpad memory 사용량, thread block의 thread 개수 등은 프로그램을 제작하는 과정에서 프로그래머(제작자)가 선택할 수 있다. 각 값을 어떤 값으로 선택하느냐에 따라 GPU에서 성능 차이가 발생할 수 있다. 이러한 문제점을 본 논문에서는 크게 3가지 포인트로 정리하였다.

• Programming Ease: GPU 프로그램 작성 시 GPU의 구조를 알아야 최적화된 GPU 프로그램 제작이 가능하다. GPU의 구조를 알더라도 GPU에 적합한 register 사용량, scratchpad memory 사용량 등을 파악하기가 어렵다. 또한, 프로그램 작성 시 register 사용량과 scratchpad memory 사용량을 조금만 변경하여도 성능에서는 큰 차이가 발생할 수 있다. 그림 1은 여러 GPU 프로그램의 register, scratchpad memory 사용량에 따른 성능 차이를 보여준다.

그림 1: Register, Scratchpad Memory 사용량에 따른 성능 차이

• Portability: 새로운 GPU 구조가 소개될 때마다 GPU 프로그램을 다시 작성해야 한다. GPU 구조마다 SM의 scratchpad memory 크기, register 크기, 실행 가능한 thread의 개수가 다르므로 대부분의 GPU 프로그램이 새로운 GPU 구조에서도 좋은 성능을 낼 수 있도록 프로그램 변경이 필요하다. 그림2는 MST 프로그램을 Fermi, Kepler, Maxwell에서 실행한 성능 결과이다. Fermi, Kepler, Maxwell 구조에 따라 최적 성능 포인트가 다른 것을 확인할 수 있다.

그림 2: MST를 Fermi, Kepler, Maxwell에서 실행한 성능 결과

• Performance: 컴파일러가 Kernel마다 thread의 register 사용량, thread block의 scratchpad memory 사용량을 static 하게 정한다. Kernel 당 사용값은 kernel이 실행되는 동안 최대 사용량을 기준으로 하므로 항상 register와 scratchpad를 다 사용하고 있는 것은 아니다. 결과적으로 GPU의 resource가 낭비되어서 GPU의 최대 성능을 낼 수 없는 구조이다.

Goal 

GPU에 Virtualization 개념을 추가하여서 프로그램을 작성할 때 실제 하드웨어보다 더 많은 GPU resource가 있는 것처럼 보이게 만들어준다. 그리고 GPU 하드웨어에서 dynamic 하게 resource 사용량을 조절하여 resource underutilization문제를 해결한다 (Resource underutilization문제를 제거하여 성능 향상을 목표로 한다).

Zorua Architecture

그림 3: 각 Phase마다 사용되는 resource 사용량

• Compiler: Compiler가 phase를 나누어서 각 phase에 사용되는 resource양을 측정한다.  그림3은 compiler를 사용하여 phase의 resource양의 측정한 예제이다. 기존 compiler의 경우 kernel 단위로 register와 scratchpad 사용량을 정한다. 반면 Zorua의 경우 phase 단위로 resource 사용량을 정하여 특정 phase에서는 더 많은 thread가 동시에 실행된다. 예를 들어 Phase #1과 phase #3의 경우 phase #2보다 적은 리소스를 사용하기 때문에 더 많은 thread를 동시에 실행가능하다.

그림 4: Coordinator 구조

• Runtime System: Coordinator가 실시간으로 schedule이 가능한 thread와 pending thread를 선택한다. Compiler에서 제공한 resource 사용량을 기존으로 실행 가능한 thread를 정하고 scheduler는 실행 가능한 thread만을 이슈 하는 형태이다. Phase가 변하게 되면 실행 가능한 thread의 개수가 변경된다.

그림 5: Zorua Hardware 구조

• Hardware: Hardware 부분은 크게 2가지가 있다. Coordinator 부분과 Mapping table 부분이다. Coordinator의 경우 앞에서 설명한 것과 같이 schedule 가능한 thread와 pending thread를 정하는 부분이다. Mapping table의 경우 실제 resource가 어디에 할당되어 있는지를 확인하는 부분이다. 기존 GPU보다 더 많은 thread를 실행할 수 있도록 변경하였기 때문에 physical 한 resource와 virtual resource를 같이 사용해야 한다. 추가도 제공되는 resource의 경우 global memory에 저장하였다고 한다. 여기서 Virtual resource를 너무 많이 사용하면 global memory access가 많이 발생하여 실제로 성능이 떨어질 수도 있다고 한다. 이러한 문제점도 논문에서는 언급하였고 해결 방안을 제시하였다.

Evaluation

결과는 따로 정리하지 않았고 따로 정리할 계획이 없다 (다른 논문들도 정리하지 않을 계획이다). Architecture 논문의 경우 각자 다른 simulator를 사용하여 측정하기 때문에 서로 단순한 결과로 비교할 수 없다. 그리고 논문이 publish가 된 경우 자기 기술이 다른 기술보다 우수하다고 이야기하기 때문에 결과를 정리하는 것은 무의미하다고 생각한다.

본 논문에서는 Zoura를 사용하면 static 하게 정한 resource의 사용량에 따른 성능의 차이가 작게 발생한다고 한다. (Resource의 사용량을 프로그래머가 임의로 선택하였을 때의 성능 차이가 최소화되었다고 이야기하였다) 그리고 특정 하드웨어에 최적화된 GPU 프로그램을 다른 GPU 하드웨어에 돌려도 만족할 만한 성능이 나온다고 한다.

아쉬운 점

많은 다른 논문 아이디어를 합쳐 놓은 듯한 기분이 든다. Warp Level Management [77], Shared Memory Multiplexing [84], Virtual Thread [85], 등의 논문을 하나로 합쳐 놓은 기분이다. 그리고 hardware관련 설명이 너무 부족하다. Architecture분야에서 저명한 저자들이 작성한 논문이라 많은 tackle을 피할수 있었던게 아닌가하는 생각이 든다. 내가 읽기에는 rebuttal과정에서 많은 공격을 받았을 것 같다는 기분이 든다.

출처

1. Zorua: A Holistic Approach to Resource Virtualization in GPUs (Micro 2016)
2. https://www.microarch.org/micro49/