갤럭시 S4의 엑시노스 5 옥타는 첫번째 big.LITTLE

 

삼성이 발표한 스마트폰 갤럭시 S4의 칩 아키텍처에서 핵심은 big.LITTLE입니다. ARM 아키텍처 차원에서 절전을 실현하기 위해 도입한 새 아이디어로 고성능 big CPU와 저전력 LITTLE CPU를 탑재해 평균 소비 전력을 낮춥니다.

 

갤럭시 S4의 일부 모델에는 삼성이 제조한 모바일 SoC(System on a Chip) 엑시노스 5 옥타가 들어갑니다. 이 프로세서는 고부하에선 1.6GHz의 Cortex-A15(반도체의 스펙을 보면 최고 1.8GHz이상), 저부하에선 1.2GHz의 Cortex-A7로 CPU 코어를 전환합니다. Cortex-A15와 Cortex-A7은 각각 쿼드코어 구성이니 두개를 더하면 옥타코어가 됩니다. 하지만 Cortex-A15와 Cortex-A7은 같이 동작하지 않으니까 최대 동작 코어 수는 4개, 최대 성능은 이론적으로 Cortex-A15 쿼드코어와 같지만 평균 소비 전력은 단순한 Cortex-A15 쿼드코어보다 훨씬 낮습니다.

 

01.jpg

 

엑시노스 5 옥타의 다이에서 CPU 코어 부분을 확대한 것. Cortex-A15 쿼드코어(오른쪽)과 Cortex-A7 쿼드코어(왼쪽).

 

02.jpg

 

big.LITTLE 아키텍처의 개념

 

03.jpg

 

04.jpg

 

big.LITTLE의 정보

 

big.LITTLE은 2011년 가을에 ARM이 발표한 후 줄곧 주목을 받아 왔는데 삼성 SoC에서 마침대 실현되었습니다. 삼성이 제일 먼저 달성할 수 있었던 배경에는 소프트웨어 개발이 있습니다. 또 여기에는 인텔이 비해 압도적으로 떨어지는 ARM 시스템 소프트웨어 개발&최적화라는 문제가 있습니다.

 

ARM은 2011년에 big.LITTLE을 발표했을 때는 가상화를 사용해 CPU 코어를 전환하다고 설명했습니다. 그러나 삼성 갤럭시 S4에서 big.LITTLE의 소프트웨어 계층 구현은 가상화를 사용하지 않고 안드로이드의 리눅스 커널에서 CPU 코어를 바꾸는 In-Kernel Switcher(IKS)를 사용합니다.

 

이 In-Kernel Switcher는 ARM이 제공한 것도 삼성이 독자 개발한 것도 아닙니다. ARM 기반의 리눅스 핵심 기술을 공동 개발하는 비영리 엔지니어링 조직 Linaro가 개발한 것입니다. Linaro의 목적은 자사 하드웨어를 위한 소프트웨어 계층의 개발을 수행해, 방대한 자원으로 압박하는 인텔에 맞서 ARM이 경쟁할 수 있도록 하는 것입니다. 더욱 복잡해지는 하드웨어 때문에 소프트웨어 개발 총량은 부풀어 오르고 있고 따라서 소프트웨어 공동 개발이 필요합니다.

 

05.jpg

 

ARM의 비즈니스 모델

 

06.jpg

 

Linaro를 설립한 이유

 

07.jpg

 

인텔과 ARM의 오픈 소스 기본 소프트웨어 개발의 차이

 

 

2종류의 CPU 코어로 저전력을 실현하는 big.LITTLE

 

ARM의 big.LITTLE 프로세싱은 헤테로지니어스 멀티 코어를 써서 전력을 절약하는 아이디어입니다. 명령어 셋트는 완벽 호환되지만 성능과  소비 전력이 다른 2종류의 CPU 코어를 가지고 작업의 부하에 따라 CPU 코어를 전환합니다. 고부하 작업은 고성능 CPU 코어에서 짧은 시간에 실행하고 부하가 낮은 작업은 저전력 코어로 실행해 성능과 저전력을 모두 확보합니다. 대부분의 태스크는 저전력 위주로 실행하기 때문에 평균 소비 전력은 줄어들게 됩니다.

 

08.jpg

 

big.LITTLE의 전력과 성능

 

ARM은 그 때문에 고성능 코어의 Cortex-A15와 여기에 호환되는 저전력 위주의 Cortex-A7 사이에서 일관성을 유지할 장치를 마련했습니다. 전력 소비가 늘어난 Cortex-A15를 탑재한 시스템에서 부하가 낮을 때 Cortex-A7로 전력 소비를 줄이고, 이걸로 모바일 SoC의 성능과 전력의 범위를 확장합니다.

 

이 배경에는 모바일 장치에 요구되는 성능 범위가 확장됐다는 사실이 있습니다. 보다 높은 성능이 필요한 앱이 등장했지만 높은 성능을 필요로 하지 않는 작업도 여전히 있습니다. 하지만 배터리 용량이 거의 늘어나지 않았기 때문에 ARM CPU는 성능과 전력이라는 상반된 요구에 맞춰 성능과 전력의 범위를 넓히는 방법을 고른 것입니다.

 

문제는 단일 CPU 아키텍처에선 이 2가지 요구를 동시에 만족시킬 수 없다는 점입니다. big.LITTLE에서는 2종류의 서로 다른 CPU 코어를 조합해 이 문제를 해결합니다. 다른 성능 범위의 CPU 2개를 조합해 넓은 성능 범위를 커버하는 것입니다.

 

09.jpg

 

big.LITTLE와 아키텍처 비교

 

 

big.LITTLE 소프트웨어 모델 3가지

 

big.LITTLE은 하드웨어보다 소프트웨어 쪽이 더 어렵습니다. 어떻게 2종류의 서로 다른 코어를 효율적으로 작동시키는가. 제일 이상적인 것은 OS가 고부하 작업을 big 코어, 저부하 작업을 LITTLE 코어로 실시간으로 분배하는 것이지만 여기에는 많은 어려움이 있습니다. 그리고 OS에 특수한 대응이 필요하게 되는 것을 시스템 벤더는 싫어합니다.

 

그 때문에 2011년에 ARM은 CPU 코어를 가상화하고 하이퍼바이저가 CPU 코어 사이에 OS를 넘기는 작업을 소프트웨어적으로 처리한다고 설명했습니다. 그러나 미래에는 OS를 big.LITTLE에 최적화해 코어를 최대한 사용하는 다중 처리 모델도 가능하게 될 것으로 보았습니다. 이 시점에선 전자를 big.LITTLE 작업 마이그레이션 모델(Task Migration Use Model), 후자를 big.LITTLE MP 모델(Multiprocessing Use Model)이라고불렀습니다.

 

10.jpg

 

big.LITTLE 소프트웨어 아키텍처

 

작업 마이그레이션 모델에서는 Cortex-A15의 클러스터와 Cortex-A7의 클러스터 중 어느 한쪽이 동작합니다. OS나 앱은 코드를 전혀 바꿀 필요가 없고 하이퍼바이저가 CPU 코어의 스위치를 관리합니다. 실제로 이 구현을 염두에 두고 프로토타입 소프트웨어를 만들었습니다.

 

그러나 그 후 ARM은 노선을 변경했습니다. 2012년 가을에 열린 ARM Techcon 컨퍼런스에서 작업 마이그레이션이라 부르던 모델을 클러스터 마이그레이션 모델(Cluster Migration Model)로 이름을 바꿨습니다. 클러스타 마이그레이션은 프로토타입만으로 끝나고 실제 제품으로 제공되진 못했습니다.

 

현재 ARM은 big.LITTLE에 대해 3개의 활용 모델을 제시하고 있습니다. 프로토타입인 big.LITTLE 클러스터 마이그레이션과, OS에 스위치 소프트를 더해 실형하는 big.LITTLE CPU 마이그레이션 모델(CPU Migration Use Model), big.LITTLE MP 모델의 3개입니다. 새로 CPU 마이그레이션 모델이 추가되고 이것이 big.LITTLE의 첫 모델로 제안됐습니다. 또 CPU 마이그레이션 모델과 MP 모델 모두 Linaro에서 소프트웨어 개발을 합니다.

 

11.jpg

 

big.LITTLE의 각 활용 모델

 

12.jpg

 

big.LITTLE의 활용 모델

 

13.jpg

 

마이그레이션 소프트웨어는 Lianro가 개발

 

CPU 마이그레이션 모델과 클러스터 마이그레이션 모델의 큰 차이는 CPU 클러스터 단위가 아니라 CPU 코어 단위로 바꾼다는 점입니다. big 코어가 LITTLE 코어를 1대 1로 페어링해 각각의 조합에서 한 쪽 코어만 작동하는 것입니다. LITTLE 코어에서 실행하던 작업이 부하가 높아지면 페어링된 big 코어로 바꿔 시행하는 구조입니다. ARM은 CPU 마이그레이션 모델이 2013년 전반기에 이용 가능한 소프트웨어 솔루션이라고 설명합니다.

 

 

big.LITTLE를 만들 CPU 마이그레이션 모델

 

big.LITTLE의 CPU 마이그레이션 모델에서 가장 중요한 점은 CPU 코어의 전환에 하이퍼바이저를 사용하지 않지만 OS의 스케줄에도 변경을 하지 않는다는 것입니다. 클러스터 마이그레이션과 MP 모델의 중간에 위치한 솔루션입니다.

 

14.jpg

 

Liano 멤버 서비스 FAE, 엔지니어인 츠카모토 아키라

 

CPU 마이그레이션 모델이 태어난 것은 원래 ARM이 처음으로 제시한 클러스터 마이그레이션 모델이 실용적이지 않아서라고 합니다. MP 모델은 OS의 스케줄을 변경해야 하니 구현에 시간이 걸리며 big.LITTLE의 도입을 늦추게 하는 요소입니다. 그래서 CPU 마이그레이션이란 아이디어가 떠올랐다고 츠카모토 아키라는 설명합니다.

 

"클러스터 마이그레이션은 클러스터 단위니까 Cortex-A15와 A7의 어느 한쪽만 작동하지 않습니다. 이보다 더 큰 문제는 스위칭을 하이퍼바이저를 통해 한다는 것입니다. 하이퍼바이저에 들어가서 스위칭하고 하이퍼바이저에서 나와야 하니 2번의 작업 스위치가 생깁니다. 그래서 CPU의 싸이클만 300 싸이클을 소비하고 L2 캐시까지 합치면 3000 싸이클을 소비하니 상당히 느립니다.

 

클러스터 마이그레이션은 빠른 스위칭이 불가능하니 실제 제품에 쓰기엔 문제가 있다는 결론에 도달하게 됩니다. 그래서 ARM은 차선책으로 big.LITTLE MP가 가능한지 검토했는데, 2013년 전반기까지 MP 소프트웨어 개발을 하긴 무리라고판단했습니다. 그래서 Linaro의 핵심 멤버들이 CPU 코어 마이그레이션을 만들어 구현하고, 2012년 12월까지 완성해 삼성의 스마트폰 출시에 맞추게 됐습니다."

 

15.jpg

 

Linaro의 멤버

 

16.jpg

 

CPU 마이그레이션의 개발

 

17.jpg

 

Linaro의 로드맵

 

ARM은 원래 쿨러스터 마이그레이션에서도 스위칭의 공백은 문제가 되지 않는다고 설명했지만 현실은 그렇지 않았습니다. 현실적인 답이 CPU 마이그레이션 모델이었다는 것입니다.

 

이런 사정으로 현재 Linaro에서 개발한 CPU 마이그레이션 모델 소프트웨어는 Linaro의 멤버에게만 제공하진 않았습니다. 그리고 Linaro에 주력하는 삼성은 여기에 맞춰 big.LITTLE의 제품화에 성공할 수 있었습니다.

 

 

리눅스의 스케줄을 변경하지 않고 big.LITTLE을 지원

 

CPU 마이그레이션 모델의 장점은 OS 쪽에서 CPU 코어는 대칭형의 SMP(Symmetric Multi-Processor)구성인 것으로 보이나 하드웨어적으로는 비대칭인 AMP(Asymmetric Multiple Processor) 구성이란 점입니다. 삼성을 예로 들면 안드로이드의 리눅스 커널에서 하드웨어는 쿼드코어 SMP 구성으로 보이지만 실제로는 Cortex-A15의 쿼드와 Cortex-A7의 쿼드, 2종류 8코어가 서로 섞인 AMP 구성이 됩니다. 그리고 CPU 마이그레이션 모델은 리눅스 커널 스케줄러 자체에는 손을 대지 않습니다. 이것은 매우 중요하며 개발 기간이 짧아진 이유이기도 합니다.

 

"리눅스 커널의 스케줄러 소스 코드는 1만 줄 정도인데 여기에는 전혀 손대지 않았습니다. 그 밑에 애드온으로2천줄 정도의 코드를 더 넣어 CPU 코어 스위치를 하도록 했습니다. OS의 스케줄에서 가상적으로 CPU 코어는 4개만 보입니다. 그러나 그 아래에서 Cortex-A7과 A15를 바꾸고 있습니다. 스위칭이 커널 안에 들어 있으니 이것을 In-Kernel Switcher:IKS라 부릅니다.

 

18.jpg

 

IKS와 MP

 

19.jpg

 

IKS 솔루션

 

20.jpg

 

MP 솔루션

 

In-Kernel Switcher(IKS)가 OS의 스케줄을 속임여 SMP인 것처럼 하면서 AMP 구성을 활성화하는 구조입니다. 애드온인 IKS를 사용해 OS의 근본 기능인 스케줄러 코드는 바꾸지 않습니다. 리눅스의 역사에서도 스케줄러 변경은 2번 정도만 진행됐으니 이것을 수정하는 건 큰 작업이라는 건 명확합니다. 그래서 IKS는 애드온을 쓴 것입니다.

 

Linaro의 IKS는 CPU 부하에 따라 2개의 코어를 전환합니다. 전환 포인트의 결정은 부하에 따라 CPU 코어의 전압과 클럭을 바꾸는 DVFS(Dynamic Voltage and Frequency Scaling)로, 리눅스의 경우 CPUFreq Governor라 불리는 하위 시스템이 있으며 CPU 사용률을 모니터링하고 CPU의 작동 클럭을 전환합니다. IKS는 Governor의 정보로 DVFS가 일정한 포인트에 도달했을 때 CPU 코어를 스위칭합니다.

 

그 때문에 OS쪽은 DVFS로 CPU의 클럭을 전환한다고 판단하지만 실제로는 IKS가 일정한 DVFS 포인트를 경계로 해서 아래는 Cortex-A7, 위는 Cortex-A15라는 식으로 나누는 것입니다. 또 Cortex-A7과 Cortex-A15는 클럭 범위가 달라 Cortex-A7의 최고 클럭에서 Cortex-A15의 최저 클럭으로 전환되기에 IKS에서는 가상 OPP(Operating Performance Point)을 설정해서 Cortex-A7과 Cortex-A15 각각의 실제 DVFS 포인트에 맵핑하고 있습니다. OS에서 보이는 것은 가상 OPP입니다.

 

21.jpg

 

22.jpg

 

CPU 사용률을 모니터링해서 Cortex-A15로 전환

 

23.jpg

 

Cortex-A7/A15의 전환하는 OPP

 

Linaro의 IKS를 통해 비대칭형 AMP 구성 big.LITTLE 아키텍처가 이뤄졌습니다. 다음은 big.LITTLE MP 모델의 실현입니다. MP 모델에서는 태스크의 CPU 부하에 따라 모든 코어에 적절한 작업 할당이 가능하다고 ARM은 설명합니다. 하지만 이는 다양한 어려움이 있습니다.

 

24.jpg

 

big.LITTLE MP의 상태

 

25.jpg

 

big.LITTLE의 소프트웨어 생태계

 

26.jpg

 

앞으로의 개선점

기글하드웨어(http://gigglehd.com/zbxe)에 올라온 모든 뉴스와 정보 글은 다른 곳으로 퍼가실 때 작성자의 허락을 받아야 합니다. 번역한 뉴스와 정보 글을 작성자 동의 없이 무단 전재와 무단 수정하는 행위를 금지합니다.