ARM big.LITTLE Processing의 목적과 유용성에 대하여.

지난 번에 빅리틀에 대해 한 번 다뤘습니다.
(ARM big.LITTLE Processing (빅리틀))
하지만 최근 커뮤니티에서의 반응을 보면 빅리틀의 유용성에 대해 제대로 인식하지 못하고 있다는 느낌을 받습니다.
아무래도 지난 포스팅이 빅리틀의 동작 방식에 촛점이 맞췄고,
왜 빅리틀이라는 기술이 나왔으며 왜 빅리틀이 유용한지에 대한 설명이 부족했기때문이지 않나 싶습니다.
(이렇게 말하면 마치 내 글이 대단한 영향력이라도 있는 것으로 생각하는 것처럼 보일까봐 좀 그렇지만...)
엑시노스5 옥타의 소비전력에 대한 논란도 그런 측면에서 비롯된 것이겠지요.
그래서 이번에는 빅리틀의 목적과 유용성에 대해 다뤄보겠습니다.

이 글은 2012년 7월 16~19일 간 그리스에서 열린 12회 SAMOS 에서 The homogeneity of architecture
in a heterogeneous world 라는 제목으로 발표된 자료를 바탕으로 작성되었습니다.
매끄러운 내용 전개를 위해 일부 슬라이드의 순서가 바뀐 부분이 있습니다.
(SAMOS는 Systems: Architectures, MOdeling and Simulation 의 약자로 임베디드 컴퓨터 관련 국제 컨퍼런스입니다.)

빅리틀의 동작 방식, 하드웨어 구성 등의 정보는 이전에 다루었기때문에 여기서는 다루지 않겠습니다.
궁금하시면 위 링크의 포스팅을 참고하세요.

빅리틀의 목적은 간단합니다.
작업 부하에 맞는 프로세서를 쓰자는겁니다.
그렇다면 왜 그럴 필요가 있을까요.
성능은 무조건 높은게 좋은거 아닌가요?

ARM 기반 코어의 성능 향상될수록 소비전력도 상승하기때문입니다.
ARM 기반 코어가 제 아무리 저전력이더라도 일하는만큼 먹어야한다는 반도체의 진리를 비켜갈 수는 없습니다.
(물론 모든 반도체가 먹는만큼 일하는건 아닙니다. 우리는 그동안 밥값도 못하는 제품을 많이 봐왔지요.)
거꾸로 생각해보면 빅리틀이라는 기술이 등장해야할 정도로 ARM 기반 코어의 성능과 소비전력이 상승한 것이지요.

높은 성능과 낮은 소비전력을 모두 잡기위해서 어떻게 해야할까요?
시작은 이런 의문에서 출발했을 것이라고 생각합니다.
그리고 그 의문에 대한 ARM의 대답이 빅리틀인거고요.
높은 성능을 요구하는 작업은 높은 성능을 가진 프로세서로 처리하여 높은 성능을 잡고,
낮은 성능을 요구하는 작업은 높은 전력효율을 가진 프로세서로 처리하여 낮은 소비전력을 달성한다는겁니다.

그리고 그에 걸맞는 아키텍처가 Cortex-A15 (이하 A15)와 Cortex-A7 (이하 A7)입니다.

왼쪽은 A15가 A7에 비해 성능이 얼마나 높은지를 보여주고,
오른쪽은 A7이 A15에 비해 전력효율이 얼마나 좋은지 보여줍니다.
(맨 위의 Dhrystone이 ARM 코어 성능 얘기 나올 때마다 언급되는 DMIPS 입니다.
DMIPS가 Dhrystone Million Instructions Per Second 의 약자)

하지만 빅리틀의 발상이 실제 사용환경에서 유효한지 검토가 필요하겠지요.
실사용에서 요구되는 성능이 예상보다 높으면 대부분 A15 로 돌아가게되고 그렇다면 A7의 역할이 축소되면서 전력효율을 잡겠다는 꿈은 물거품이 될테니까요.

그것을 확인하기위한 가정의 위의 사용패턴입니다.

음성통화 90분
이메일 60분
웹서핑 30분
동영상 감상 30분
게임 50분
음악 감상 + GPS 기록 90분
동영상 녹화 10분
수면 (알람 설정) 7시간
OS에 항상 돌아가는 백그라운드 프로세서 28개

딱 봐도 하드합니다.
저렇게 살면 바쁘겠네요.
순수하게 스마트폰쓰는 시간만 6시간입니다.
표본으로 이 정도 가정이면 충분하겠지요.

각종 작업시 CPU 사용률입니다.
300MHz 이상, 즉 노란색부터 위까지가 실제 로드(부하)가 걸리는 상태로 볼 수 있습니다.

보면 알 수 있듯이 대부분 심하게 로드가 걸리는 비율이 적습니다.
브라우저 벤치마크의 경우, 벤치마크앱답게 90% 이상이 최대 로드 상태입니다만 벤치마크니까 당연한거지요.
주목할 것은 게이밍 벤치마크입니다.
CPU 로드는 크지 않습니다. 게임이니 GPU 로드가 크겠지요.
게임이라고 무조건 CPU 사용률이 높고 CPU의 소비전력이 높아질 것이라고 생각하면 안 된다는겁니다.

CPU 사용률 분포와 스마트폰 사용 패턴 가정을 종합한 결과가 이겁니다.
90%에 가까운 작업이 500MHz 이하의 낮은 성능을 요구합니다.
(전체 사용시간이 아닌) CPU 가 동작하는 시간 중에서 12%만이 빅코어의 성능이 필요하고 나머지는 리틀코어의 성능으로 충분합니다.

이런 결론을 통해 엑시노스5 옥타의 소비전력에 대한 논란의 문제점을 반박할 수 있습니다.

1. 최대 소비전력만으로 전체 사용시간을 판단하는건 잘못되었다.
90% 가까운 시간이 A7로 돌아갑니다.
2. 벤치마크 앱을 제외한 일반적인 앱에서 CPU에 최대 부하가 걸리는 일은 드물다.
빅코어가 활성화되더라도 사용률이 매우 높아지면서 최대 전력을 소비하는 경우는 드물다는겁니다.

빅리틀의 목적과 유용성은 어느 정도 설명이 되었으니 어떻게 진전이 있었는지 살펴보겠습니다.

전에도 언급했듯이 빅리틀 모델은 3가지입니다.

빅코어 클러스터(코어군)와 리틀코어 클러스터끼리 전환되는 클러스터 마이그레이션.
빅코어 하나와 리틀코어 하나끼리 전환되는 CPU 마이그레이션
빅코어, 리틀코어 모두 사용할 수 있는 멀티프로세싱.
 
그 중에서 우리가 만나게될 것은 CPU 마이그레이션이겠지요.

마이그레이션 알고리즘인데 저번에 설명했으니 패스.

실제 칩으로 안드로이드에서 CPU 마이그레이션을 시연한 결과입니다.

빅리틀이 SMP와 뭐가 다르냐.
(SMP는 Symmetric Multi-Processing 으로 기존의 일반적인 제품들을 생각하면 됩니다.)

SMP는 사용가능한 모든 코어에 일괄적으로 작업을 분배하여 최대 성능을 얻는게 목적이지만,
빅리틀은 작업의 요구성능에 맞는 코어에 작업을 분해하여 최대 전력효율을 얻는게 목적입니다.
목적이 다른만큼 방식도 달라진거지요.

최초의 에뮬레이션 결과입니다.
4코어 SMP에 비해 2+2 빅리틀의 처리 시간이 너무 길어집니다.

이러면 빅리틀이 유용하다고 말할 수가 없습니다.

용어가 복잡한데 내용은 별거 없습니다.
대부분의 프로세스가 실제 처리시간보다 처리 대기시간이 더 길고, 작업 우선순위에 따라 대기시간이
길어진다는 겁니다.

그래서 빅코어와 리틀코어를 사용하는 기준을 정합니다.
구체적으로 적혀있는데 간단히 정리하면, 가능하면 리틀코어를 사용하되, 고정 우선수위가 높거나 다양한
이유로 리틀코어에 무거운 작업은 빅코어로 처리한다는겁니다.

Vanilla 커널의 스케줄러에 의한 결과.
1~7 까지의 프로세스를 처리한 결과입니다.
1,2 는 idle 수준의 백그라운드 작업.
3,4 는 무거운 작업.
5,6,7 은 가벼운 작업.

이상적인 빅리틀이라면 3,4 에서 빅코어가 동작하고, 1,2,5,6,7 에서 리틀코어가 동작해야합니다.
하지만 왼쪽 아래 결과를 보면 3번 프로세스에서 빅코어가 아닌 리틀코어가 동작하고 있습니다.
그 결과 실행 시간이 길어졌지요. (세로가 시간축)
그리고 5,6번 프로세스가 빅코어가 동작하고 있고, 리틀코어가 동작해야 할 1,2번 프로세스에서 빅코어가
동작하고 있습니다.
총체적 난국.

오른쪽 아래 그래프는 각 코어별 idle 상태에서 동작상태로 전환된 횟수로 보이는데, 빅코어의 전환 횟수가 많습니다.
쓸데없이 빅코어를 자주 사용했다는거지요.

이는 왼쪽 위의 그래프를 통해서도 확인됩니다.
왼쪽 위는 각 코어별로 idle 상태에서 동작 상태로 전환될 때까지의 시간 분포로 보입니다.
빨간색(동작상태)과 아주 어두운 색(100ms 이상)의 비중이 높은게 좋습니다.
전환 시간이 짧으면 그만큼 쓸데없이 동작했다가 안 했다가 한다는거니까요.
빅코어의 전환 시간 중에서 짧은 시간의 비중이 높으니 문제가 있습니다.

빅리틀에 최적화된 스케줄러에 의한 결과입니다.

각 코어에 제대로 프로세스가 분배되었고, 빅코어의 전환 횟수도 크게 줄었습니다.
대신 리틀코어의 전환 횟수가 증가했지만 빅리틀에서 중요한건 빅코어의 제어이니 큰 문제는 없습니다.

그 결과 빅리틀로 4코어 SMP와 비슷한 수준으로 처리 시간이 단축되었습니다.

위에서 본 실물 제품에서 테스트한 결과입니다.
300MB 파일을 읽어와서 MD5 해시값을 계산하는 테스트입니다.

오른쪽의 프로세서 창을 보면 알 수 있듯이 A15 2코어, A7 3코어입니다.
(저번 포스팅에서 2코어, 3코어 구성이 오타아니냐는 분이 있었는데 오타 아닙니다.)

첫번째 작업(1st Run)은 MMC에서 파일을 읽어오는겁니다. (디스크 액새스 상태를 보면 알 수 있지요.)
부하가 낮은 작업이기때문에 A7만 동작합니다.

두번째 작업(2nd Run)은 해시값을 계산하는겁니다.
부하가 있으니 A15가 동작합니다.

빅리틀이 제대로 돌아간다는 얘기지요.