ARM의 Big.LITTLE: 삼성 엑시노스는 뜨거울 수 밖에 없다. #2/2

일단 제1편 ARM의 Big.LITTLE: 이게 무엇인가? 부터 읽고 보시는 쪽이 이해가 쉽습니다. 글이 굉장히 늦어졌는데, 삼성이 갤럭시 S4A, 노트3 등에 퀄컴 스냅드래곤 800을 주로 탑재하면서 이리저리 미루다가 기다리시는 분들이 계신다는 이야기를 듣고 정리, 완성했습니다. 기대하라고 써 놓고 너무 늦어서 죄송합니다. 기다리신 분들에게 양해의 말씀 드립니다. ^^;

삼성은 처음부터 빅.리틀 프로세서를 동일 클럭 방식(Synchronous Clock Architecture, 이하 sync 구조)로 만들려고 했다. 이 문서에서 삼성은 코어별 클럭 방식(Asynchronous Clock Architecture, 이하 async 구조)에 비해 sync 구조가 성능은 물론이고, 전력 소모와 발열 면에서도 더 나을 수 있다고 주장한다. 요약하면 다음 그래프와 같이, 코어를 고클럭으로 짧게 구동함으로서 async 구조가 갖는 여러 추가부담 없이 바로 전력 소모를 줄일 수 있다고 본 것이다.

Cap 2013-12-08 23-37-55-475
전력소모 = 전력소비율(Power) x 구동시간(Time) 이므로, 높은 클럭을 빠르게 구동한 후 코어를 꺼버리는 방법으로 sync 구조의 전력소모를 async 구조와 같은 수준으로 줄일 수 있다는 삼성의 그래프.

또한 해당문서에서 삼성은 빅.리틀 아키텍쳐의 경쟁자로서 asynchronous architecture를 명시하면서 빅.리틀 자체를 sync 구조로 이해하고 있음을 드러낸다. 이렇다면 코어별로 클럭을 통해 개별 변환되는, aync 구조가 필연적인 CPU별 변환(CPU Migration)은 최소한 삼성의 빅.리틀 프로세서에서는 불가능한 방식이었다. ARM 개발사들의 모임인 Linaro의 이 문서에서도 현행 하드웨어(삼성 엑시노스 5410)에서는 클러스터가 각각 sync 구조라서 IKS, 즉 CPU별 변환이 불가능하다고 명시적으로 밝히고 있다. CPU별 변환 개념이 사실상 MP모드 이후에 나온 절충적 개념이라서 생긴 문제로 보인다. MP모드는 이론상으로는 가장 완벽해보이지만 실질적으로 상당한 문제가 있는데, 이는 이 글 후반부에서 다루겠다.

클러스터 변환이 왜 문제인가? 이는 곧 왜 갤럭시S4는 온도 제한을 90도까지 올려서 발매해야 했는가?라는 문제이다. 가장 큰 문제는 안드로이드 앱들이 대부분 싱글 스레드라는 점에 있다. 한 앱이 고성능을 요구하는 상황을 생각해보자. 당연히 리틀 코어로는 성능이 부족하므로 빅 코어로 변환이 일어난다. 클러스터 변환이므로 리틀 코어들은 꺼지고, 빅 코어들이 모두 구동된다. 그리고 빅 코어 하나는 이 앱을 돌리기 위해서 클럭을 필요할 수준까지 계속 올라가야 한다. Sync 구조이기 때문에 나머지 빅 코어들 또한 할 일이 없음에도! 그 고클럭으로 동작해 버린다. 실 동작은 안 하므로 그나마 일하고 있는 코어보다는 낫겠지만, 클럭이 올리는 이상 전력 소모와 발열을 피할 수 없다. 멀티 스레드 앱이라면 그나마 빅 코어들이 분담하면서 클럭 상승이 억제되겠지만, 싱글 스레드는 그렇지 않다. 엑시노스 5410의 경우 한 클러스터가 4개 코어를 가지므로, 빅 코어 하나를 구동시키기 위해서 나머지 3개를 모두 같은 클럭으로 올려야 하는 낭비가 일어나는 것이다. 만약 온도 제한을 낮춘다면, 엑시노스 5410은 다른 프로세서에 비해 훨씬 더 빨리 온도로 인한 클럭 제한을 받을 수 밖에 없다.  갤럭시S4는 뜨거울 수 밖에 없는 것이다.

잠깐, 그렇다면 할 일 없는 빅 코어들은 꺼버리면 되지 않을까? MP모드에서도 코어들을 모두 동작시킬 수는 없으므로 이 기능은 필요하지 않은가. 이는 결국 CPU hotplugging 문제가 되는데, 현재 리눅스에서 제대로 지원되고 있지는 않다.(참고) Linaro에서도 올해 8월에는 작업 중이었다고 한다. 리눅스에서도 개발 중이므로 실제 안드로이드에 적용되려면 더 많은 시간이 필요할 것이다.

실제로도 사용시간 벤치마크를 보면, 디스플레이와 GPU가 꺼지고 CPU와 모뎀만이 동작하는 통화시간에서 엑시노스 5410을 장착한 갤럭시 S4는 퀄컴 스냅드래곤 600을 장착한 버전에 비해 사용시간이 60% 수준밖에 되지 않는다. 디스플레이가 켜지는 다른 작업들도 스냅드래곤 버전을 이기지는 못한다. 특히 비디오 재생에서는 1시간 정도까지 차이가 난다. 성능은 준수한 것으로 나오지만, 온도 제한이 강화된 S4에 대한 벤치마크는 찾을 수가 없었다.

멀티 스레드 안드로이드 앱들이 일반화된다면 상황은 많이 나아질 것이나, 멀티 스레드는 그 자체로 개발업무량을 몇 배로 증가시킨다. 더해 파편화가 심각한 안드로이드 시장에서 개발자/사가 저가형 기기에서는 오히려 성능이 떨어질 수도 있는 멀티 스레드화를 선호할 것이라 기대하기 힘든 상황이다.

CPU별 변환이 안 된다면, MP모드(삼성 표현으로는 Heterogeneous Mulit-Processing, 이후 HMP로 표기.)는 가능하지 않을까? 삼성은 올해 4분기에 고객들에게 HMP 지원을 하겠다고 발표했었지만, 12월 중순이 되어가는 지금까지도 별다른 결과물은 나오지 않고 있다. 이게 쉬운 일이 아니다. 내 예상으로는 (빅.리틀 아키텍쳐를 계속 쓴다면) (가장 빠르게 잡아서) 갤럭시 S5에서나 가능하지 않을까 싶다.

HMP가 어려운 가장 큰 이유는 삼성이 붙인 이름대로 Heterogeneous해서, 즉 상이한 코어들을 관리해야 하기 때문이다. 지금까지 대부분의 멀티 프로세서 OS들은 SMP(Symmetric Multi-Processing) 구조이다. 말 그대로 각 코어들이 모두 같고 동등하다는 가정 하에 (그래서 대칭적 Symmetric이라는 이름이 붙었다.) 개발된 것이다. 리눅스도 마찬가지이다. 이를 Heterogeneous하게 만들려면 단순한 기능추가로 끝나는 것이 아니라 알고리즘부터 완전히 새로 설계해야 한다. 현 리눅스 커널의 스케쥴러는 2003년 말 2.6 시절에 크게 바뀐 후 지금까지 끊임없이 보강, 개선되어 온 코드인데 이보다 더 복잡한 스케쥴러를 안정적으로 개발한다? 결코 쉬운 일이 아니다. 단순히 우선도를 부여하는 정도로는 역부족이다. 거기에 덧붙여 아까 이야기했듯이 cpu hotplugging 또한 아직 준비가 되어 있지 않다. 쓰지 않은 코어들을 끄지 못하는 HMP는 전력소모에서 결코 유리하지 못하다. 비유하자면, 땅은 평평하다고 생각하고 설계하고 지어왔던 집을 이번에는 언덕 위에 만들어야 하는 상황이다.

예를 들자면, 어떤 앱이 고성능을 요구하는지 어떻게 알 수 있는가? 일단 돌려보고 CPU를 많이 잡아먹으면 빅 코어에 할당한다? 그럼 그 기간 동안 앱은 동작이 끊길 것이다. 구동 내내 별 성능요구가 없던 앱이 동영상 등을 재생하면서 갑자기 높아질 수도 있다. HW적으로 변환을 매끄럽게 만들어 낸 ARM은 대단하지만, SW적으로 구현하는 것은 또다른 문제다.

HW에서도 L2 캐시를 클러스터 별로 따로 쓰므로 상시 동기화에 들어가는 비용에 더해 용량이 상대적으로 줄어든다는 문제가 있다. L2캐시에 더해 Cache Coherent Interconnect까지 구현하려면 다이 크기 문제도 있고 수율에서 강점을 보이는 삼성만이 현재 빅.리틀을 채용한 이유가 있다. 매우 비싼 아키텍쳐인 것이다.

빅.리틀 구조에 대해 알아볼수록 SW, 특히 OS에 대한 이해가 적었던 두 개발사 -ARM과 삼성-이 SW 작업을 너무 가볍게 보고 진행한 아키텍쳐가 아닌가 싶다. 인텔도 IA64 아이태니엄 개발하면서 비슷한 실수를 했던 사례가 있다. 특히 서버 등을 노린 고성능 프로세서와 값싼 임베디드용 저전력 프로세서를 개발하면서, “이걸 한데 묶으면 굳이 새 거 안 만들어도 하이엔드 모바일 프로세서로 잘 써먹을 수 있지 않을까?”라는 기똥찬 잔머리?를 굴렸던 ARM은 삼성이 결국 독자적인 아키텍쳐를 준비하기로 하는 등 그 대가를 호되게 치르고 있다. 삼성은 갤럭시 S4 이후 S4A, 노트 3에 이르기까지 (통신 모뎀의 이유도 있지만) 주력 하이엔드 제품들에 퀄컴 프로세서를 사다 써야 했다.

현재로서는 빅.리틀 프로세서 즉 엑시노스 옥타는 퀄컴 스냅 드래곤 등 async 구조의 프로세서에 비해 장점이 없다. HMP가 제대로 구현된다면 나름 장점이 생기겠지만, 그 SW는 여전히 개발단계에 머물러 있다. 안정화되려면 년 단위의 시간이 더 필요할 것이다. 지금 엑시노스는 구입할 이유가 없다. 그러니까 결론은 하나입니다. 갤럭시 S4 사지 마세요, 굳이 갤럭시가 필요하면 S4A로 사세요.

 

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의 잘못된 설계가 불러온 것이다. 이 점을 까는 게 다음 글의 주제다. 사실 이 이야기를 하고 싶어서 배경지식으로서 이 글을 작성했다고 보아도 무방하다. 기대하시라.