ARM의 Big.LITTLE: 이게 무엇인가? #1/2

모바일 시스템은 성능과 전력의 trade-off가 큰 문제다. 대기 중 기능할 필요가 없는 노트북의 경우는 그나마 나으나 스마트 기기, 특히 계속 통화대기가 필수인 스마트폰은 더욱 심각하다. 하지만 스마트기기의 고성능화를 멈출 수는 없고 배터리 용량을 늘리는 것도 한계가 있다. 이를 해결하기 위해서 ARM은 Big.LITTLE(이후 “빅.리틀”로 표기)이라 불리는 구조를 고안했다.

핵심은 저전력-저성능 코어(리틀 코어)와 고성능-고전력 코어(빅 코어)를 한 칩에 박아넣어서 나누어 쓰는 것. 대기상태나 낮은 부하의 작업에는 리틀 코어만을 구동시키다가 게임, HD동영상 플레이 등 고부하의 작업이 시작되면 리틀 코어를 끄고 꺼두었던 고성능 코어(빅 코어)를 켜서 실행한다는 아이디어다. 한 종류의 코어들만으로 구성된 칩에 비해 얻어지는 이득은 두 가지로,

  1. 대부분의 사용시간을 점하는 저부하 작업에서의 전력 소모가 줄어들고,
  2. 고성능 코어는 성능향상에 좀 더 집중할 수 있으므로 더 높은 최고 성능을 제공할 수 있다.

이 점들을 ARM(과 삼성)은 이 문서와 이 문서에서 다음 그림들과 같이 설명하고 있다. (현 세대에서 ARM과 삼성은 리틀 코어로 Cortex-A7 아키텍쳐를, 빅 코어로는 Cortex-A15 아키텍쳐를 적용하고 있다.)

Cap 2013-08-04 22-13-06-866
녹색 실선으로 칠해진 부분이 고성능 코어만으로 구성했을 때보다 저부하 상황에서 절감되는 소비전력이다.
Cap 2013-08-04 22-14-00-610
Async Architecture는 단일 종류 코어들만으로 구성된 구조를 뜻한다. 전력관리를 위해 코어별로 서로 다른 전압/클럭 주파수를 적용하게 된다.

단점이라면 (동시사용모드인 MP는 아직 제대로 구현되지 않았으므로) 빅, 리틀 코어들을 동시에 구동할 수는 없어서 OS에 제공되는 코어수에 비해 칩이 더 커진다는 점인데, 삼성은 엑시노스 시리즈에서 리틀 코어들이 빅 코어들의 칩 다이 면적 대비 13% 정도만 차지하므로 큰 부담은 아니라고 밝히고 있다. 또한 빅-리틀 코어간 변환(Migration)이 멈추는 느낌이 들지 않도록 매우 빠르게 이루어져야 하는데, ARM은 20000 사이클, 1GHz 속도에서 0.02초 이내에 마칠 수 있다고 언급하고 있다. 실제 최초로 판매된 빅.리틀 구조의 엑시노스 5 옥타 (엑시노스 5410, 갤럭시S4에 탑재)에서 갑자기 느려지거나 잠깐 멈추는 등의 불만은 찾을 수 없는 점으로 보아 이 점도 잘 보완되어 있다고 생각된다. 사실 이 칩의 실 동작으로부터 추정할 수 있는 문제점들이 더 있긴 한데, 일단 이는 이 글의 후속편에서 다루도록 하겠다.

이론상으로는 칩 다이 면적의 증가를 감수할 수 있다면 구동시간과 성능을 모두 잡아낼 수 있는 매력적인 솔루션이다. ARM은 빅.리틀 구조를 향후 핵심 구조로 삼고 계속 발전시키겠다는 전략을 표방하고 있다.

다만 현실에서 그렇다고 하기에는 아직 문제가 많이 남아있다. 이를 이해하기 위해서 일단 ARM이 이 빅.리틀 구조를 어떻게 구성했는지 알아보자. AMD의 불도저 아키텍쳐처럼 빅-리틀 코어 2개를 각각 붙여서 하나의 모듈로 만드는 방법이 직관적이지만, ARM은 빅 코어들과 리틀 코어들을 각각 클러스터로 묶고, 이를 버스(Cache Coherent Interconnect라 칭한다. 명칭대로 각 클러스터의 L2캐시들을 동일하게 유지하는 것이 역할)로 연결하는 방법을 택했다. 이렇게 함으로서 AMD처럼 완전히 새로운 모듈 시스템을 디자인하지 않고(불도저-파일드라이버 아키텍쳐의 개발지연을 보라.), 각각의 멀티코어 CPU를 통합하는 형식으로 빠르게 개발이 가능했을 것으로 보인다. 또한 리틀 코어와 빅 코어의 숫자가 같을 필요가 없어지는 장점이 있다. (ARM은 제어SW가 너무 복잡해지지 않도록 그 두 숫자가 같기를 권장하고 있기는 하다.) 이를 간단하게 개념화시키면 다음 그림과 같다. (출처)

Cap 2013-08-04 23-11-07-729

 

그리고 리틀-빅 코어간 변환은 세 가지 모드가 있다. 클러스터 변환, CPU별 변환, 그리고 리틀-빅 가리지 않고 모든 코어들을 사용하는 MP모드가 그들인데 이중 MP모드는 아직 제대로 구현되지 않은데다가 빅.리틀 구조의 장점을 대부분 포기하게 되므로 일단 클러스터와 CPU별 변환만을 보자.

클러스터 변환은 단순하게 리틀 코어 클러스터와 빅 코어 클러스터가 몽땅 변환되는 것이다. 즉, 빅.리틀 CPU는 리틀 코어들만 동작하고 있던가 아니면 빅 코어들만 동작하고 있던가 둘 중 하나다. 이렇게 하면 단순히 두 개의 멀티코어CPU 중 하나만 켜서 구동하고 있는 셈이므로 구현이 매우 쉬워진다. 현재 삼성 엑시노스 5410은 이 모드로만 동작한다. 그게 문제인데, 다음 글에서 다루겠다.

CPU별 변환(CPU Migration)은 각 코어들이 자유롭게 리틀-빅, 빅-리틀 변환을 한다. 즉 다음 그림과 같다. (출처는 바로 위 그림과 동일.)

Cap 2013-08-04 23-22-55-521

리틀 코어들 중 부하가 한계치를 넘어서는 하나의 코어만이, 빅 코어 하나를 깨워서 자기 일을 떠넘기는 게 가능한 모드이다. 즉 위 그림처럼 변환이 이루어지고 나면, 저 듀얼-듀얼 빅.리틀 CPU는 리틀 코어 하나(A7 CPU0)와 빅 코어 하나(A15 CPU0)만이 켜져서 동작하는 상태가 된다. 물론 빅 코어가 작업을 끝내고 저부하 상태가 되면 이제 다시 CPU1을 깨워서 넘겨주고 자기는 꺼진다. 이 작업을 OS에서 보면 다음 그림과 같은 형태로 제공된다. (출처)

Cap 2013-08-04 23-28-24-892
이 그림에서는 각 빅-리틀 코어가 1대1로 매칭되는 것처럼 보인다. 이론상으로는 그럴 필요가 없으나, 리눅스에서는 이렇게 여기게 되고 현재 실제 존재하는 칩들은 같은 숫자의 빅-리틀 코어들을 가지므로 실제로도 저렇게 동작하게 된다.

위 그림을 보면, 리틀-빅 코어간 변환 과정에 CPU freq 전환이 표시되어 있다. 바로 여러분들이 윈도 노트북, 데스크탑에서 자주 보는 CPU클럭 전환 기능을 이용하여 리틀-빅 간 변환을 한다. 부하가 걸리면, 리눅스는 리틀 코어의 클럭을 계속 올리게 되는데 빅.리틀 구조에서는 100%이상의 속도로 올릴 수 있도록 지원한다. 즉 100% 이상으로 올릴 때 빅 코어로의 전환이 일어나는 것이다. 빅 코어를 쓰다가 부하가 줄어들어 리눅스가 100% 이하의 클럭으로 내리면 그 때 다시 리틀 코어로 전환하게 되는 구조다. 바로 이런 특성 때문에 CPU Migration은 또한 In-Kernel Switching이라고도 불린다. 리눅스 커널의 컨트롤로 변환이 일어나기 때문이다.

필요한 만큼만 전력 많이 쓰고 뜨거운 빅 코어를 가동시킨다는 점에서 CPU별 변환이 되어야 빅.리틀 구조의 장점, 특히 저전력 특성이 살아난다. 실제로 현재 ARM 개발사들의 개발모임인 Linaro의 문서들에서는 클러스터 변환은 언급도 잘 되지 않고 있다. 또한 CPU별 변환을 하려면 각 코어별 클럭 주파수 조정이 핵심이라는 점을 위 문단에서 확인해볼 수 있다.

그런데… 정작 첫 판매물인 엑시노스 5, 그리고 갤럭시S4는 클러스터 변환만이 가능한 상태다. CPU별 변환이 가능하지 않다른 이야기도 흘러나오고 있다. 사실 엑시노스 5410의 구조상 불가능해 보인다. 그렇다. 현재 발매 중인 갤럭시 S4는 발열도 악명이 높은데, 이는 엑시노스 5 5410의 잘못된 설계가 불러온 것이다. 이 점을 까는 게 다음 글의 주제다. 사실 이 이야기를 하고 싶어서 배경지식으로서 이 글을 작성했다고 보아도 무방하다. 기대하시라.