본문 바로가기
스마트폰/삼성 SAMSUNG

갤럭시S4의 big.LITTLE 소프트웨어 모델.

by gamma0burst 2013. 5. 26.
반응형

빅리틀 모델에 대해서는 이전에도 다뤘지만 부족한 부분이 있다고 생각되어서 이에 대해 얘기해볼까 합니다.
그리고 엑시노스5410에 적용된 빅리틀 모델이 그 중 어느 것인지 생각해보겠습니다.

갤럭시S4에는 엑시노스5410(엑시노스5 옥타0)이 들어가는데, 고부하에서 최대 1.6GHz의 Cortex-A15가 동작하고 저부하에서 최대 1.2GHz의 Cortex-A7가 동작합니다.
둘이 동시에 동작하지 않으니 최대동작코어수는 4코어이고, 최대성능은 Cortex-A15 쿼드코어와 같지만, 평균소비전력은 Cortex-A15 쿼드코어보다 훨씬 낮습니다.

빅리틀이 적용된 것인데 빅리틀 모델은 하드웨어 못지않게 소프트웨어쪽의 개발이 어렵습니다.
(소프트웨어가 더 어렵다는 얘기도 있을 정도이니...)
여기서 주목해야하는 것이 Linaro 입니다.
ARM기반의 리눅스 핵심 기술을 개발하는 비영리 엔지니어링 조직입니다.
ARM기반 하드웨어의 종류와 수가 폭발적으로 증가하면서 이를 위한 소프트웨어 지원, 개발량도 폭발적으로 증가했습니다.
이 문제를 해결하기위해 다수의 업체가 가입된 공동개발조직을 구성한 것입니다.

즉, ARM기반 하드웨어를 위한 소프트웨어의 개발현황을 파악하기위해서는 Linaro의 개발진행상황을 파악해야 합니다.


(Linaro 멤버)

본론으로 돌아가서 빅리틀의 모델은 크게 3가지입니다.
클러스터 마이그레이션, CPU 마이그레이션, 멀티프로세싱(MP)

빅리틀 모델에 대한 설명 일부는 아래 링크의 내용을 참고했습니다.
사실 여부에 대해선는 뒤에서 다루겠습니다.
(
http://pc.watch.impress.co.jp/docs/column/kaigai/20130521_600181.html)


- 클러스터 마이그레이션
2011년 ARM이 빅리틀을 발표했을 때 가상화를 사용하여 CPU 코어를 전환한다고 설명했습니다.
CPU 코어를 가상화하고 하이퍼바이저(Hypervisor)가 CPU 코어 사이에서 전환작업을 소프트웨어적으로 처리한다는 것입니다.
당시에는 이를 태스크(작업) 마이그레이션(Task Migration use model)이라고 불렀습니다.
태스크 마이그레이션 모델에서는 A15 클러스터, A7 클러스터 중 한쪽만 동작합니다.
프로토타입 소프트웨어가 만들어졌으나 실제 제품에 제공되지 못했습니다.


- 멀티프로세싱 (HMP)
가장 이상적인 것은 OS가 고부하 작업을 빅코어에, 저부하 작업을 리틀코어에 분배하는 것이지만 여기에는 어려움이 많습니다.
그래서 2011년에는 이를 미래에 가능한 것으로 보았고 MP 모델(Multiprocessing use model)이라고 불렀습니다.
현재는 내부적으로 HMP(Heterogeneous Multi Processing)이라고 부릅니다.



MP모델을 구현하기위해서는 스케줄러를 손봐야하는데 이는 큰 작업입니다.
(리눅스 역사에서 스케줄러 변경이 2번정도였다니...)


- CPU 마이그레이션 (IKS)
2012년 ARM Techcon에서 현재 알려진 3개의 빅리틀 모델이 제시됩니다.
이 때 추가된 것이 CPU 마이그레이션(CPU Migration use model)입니다.
클러스터 마이그레이션과 MP모델의 중간 위치라고 생각하면 됩니다.

클러스터 마이그레이션과의 가장 큰 차이는 CPU 클러스터 단위가 아닌 CPU 코어 단위로 전환된다는 것입니다.
CPU 코어의 전환에 하이퍼바이저를 사용하지 않고, OS의 스케줄을 변경하지도 않습니다.
안드로이드의 리눅스 커널 계층에서 CPU 코어를 바꾸는 In-Kernel Switcher(IKS)를 사용합니다.

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

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

ARM은 클러스터 마이그레이션에서 스위칭 지연이 문제가 되지 않는다고 했지만 현실은 그렇지 않았다고,
MP 모델은 기간 내에 개발하는게 어려웠기때문에 가장 현실적인 답이 CPU 마이그레이션이었다는겁니다.


CPU 마이그레이션에서 하드웨어적으로 비대칭형인 AMP(Asymmetric Multi-Processor)이지만,
OS측에서 대칭형인 SMP(Symmetric Multi-Processor)로 보입니다.

그리고 리눅스 커널 스케줄러 자체는 그대로 둡니다.

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


(IKS)


(빅리틀 소프트웨어 모델)

IKS가 OS의 스케줄을 속여 SMP인척하면서 AMP를 활성화시키는 구조입니다.
IKS가 CPU 부하에 따라 CPU 코어를 전환해야하는데, 전환 포인트는 DVFS의 확장이라고 볼 수 있습니다.
(DVFS : Dynamic Voltage and Frequency Scaling, 부하에 따라 전압과 클럭이 변화.)
리눅스의 경우 CPUFreq Governor라는 하위 시스템이 CPU의 사용률을 모니터링하여 CPU의 작동 클럭을 변경합니다.
IKS는 Governor의 정보로 DVFS가 일정한 포인트에 도달했을 때 CPU 코어를 전환합니다.
OS쪽에서는 단순히 DVFS에 따라 CPU 클럭이 변화한 것으로 보이지만, 실제로는 IKS가 DVFS 포인트를 경계로 A7과 A15를 전환하고 있는겁니다.





A7의 최대클럭에서 A15의 최소클럭으로 전환되는데 이렇게되면 OS측에서 봤을 때 문제가 생깁니다.
OS측에서 봤을 때 연속적으로 클럭이 상승하는 것으로 보여야하는데, 높은 클럭으로 낮은 클럭으로 전환되는 것이 되어버리니까요.
이것을 해결하기위해 가상 OPP(Operating Performance Point)를 설정합니다.
OS측에 보여주기위한 가상의 클럭을 설정하는 것이지요.



위 클럭은 ARM의 테스트칩에서 나타난 예시입니다.
A7 코어는 350MHz~1GHz의 클럭을 갖고, A15 코어는 500MHz~1.2GHz의 클럭을 갖습니다.
이것을 연속적인 클럭 구간으로 OS측에 인식시키기위해 오른쪽과 같은 가상의 코어와 클럭으로 변환합니다.
A7의 클럭을 실제 클럭의 절반으로 표기해서 OS측에서 볼 때는 단일코어가 175MHz~1.2GHz의 클럭을 갖는 것으로 보이게 합니다.
이 클럭구조 상에서 코어 전환 포인트는 500MHz가 되는 것이고요.


실제 A7의 클럭은 파란 선이지만, 가장 OPP 상에서는 노란선의 클럭으로 인식됩니다.


코어 전환 포인트는 500MHz가 되는 것이고요.



이 경우는 A15의 클럭을 두 배로 표기했습니다.
OS측에서 볼 때 클럭이 두 배로 늘어났을뿐, 실제 동작하는 상황은 동일합니다.


빅리틀 모델에 대한 얘기는 이 정도로 하고 각 모델의 개발상황에 대해 살펴보겠습니다.



Linaro의 로드맵을 보면 2012년 상반기에 이미 IKS가 릴리즈됐습니다.
MP 모델은 릴리즈까지 멀었습니다.



클러스터 마이그레이션은 프로토타입 소프트웨어가 2011년에 나왔으나 더 이상의 작업계획이 없습니다.



현재는 IKS와 HMP만이 프로젝트 진행 중입니다.



CPU 마이그레이션은 2013년 상반기에 하드웨어, 소프트웨어 솔루션이 나옵니다.



MP 모델은 2013년 2분기 이후.



CPU 마이그레이션이 이미 강력한 솔루션이라고 발표.
MP 소프트웨어는 2013년에 궤도에 오를 것.


정리해보면 다음과 같습니다.
클러스터 마이그레이션 : 프로토타입이 나온 후 더 이상의 개발이 없었음.
CPU 마이그레이션 : 2013년 상반기에 충분히 나올 수 있는 상태.
MP 모델 : 상용화까지 시간이 더 필요함.

갤럭시S4 출시를 앞두고 많은 사람들이 CPU 마이그레이션을 생각했는데, 실제는 클러스터 마이그레이션이라는 얘기가 나왔습니다.
(
2013.05.15. IT관련 단신 모음.)

XDA에서 나온 정확한 얘기는 이겁니다.
- 소스에 있는 IKS 드라이버가 제대로 동작하지 않는다.
- Cortex-A7 클럭이 최대 600MHz이다.

후자의 경우, 앞서 CPU 마이그레이션의 가상 OPP를 생각하면 당연한 결과입니다.
실제로는 1.2GHz이지만 가상 OPP 상에서는 600MHz로 표시되는겁니다.
코어 전환 포인트가 600MHz이면 A15의 최소클럭이 600MHz 일지도 모르겠네요.

전자의 경우, 다양한 가능성이 있습니다.
실제로 클러스터 마이그레이션일 가능성.
공개한 소스에 문제가 있을 가능성.
등등

정말 클러스터 마이그레이션이라면 왜 그랬는지에 대한 추측이 가능합니다.
CPU 마이그레이션이 나오긴 했지만 상용화할 정도의 완성도가 아니기때문에 클러스터 마이그레이션을 선택했을지도 모르지요.

공개한 소스에 문제가 있다면 얘기는 복잡해집니다.
갤럭시S4가 어떤 빅리틀 모델(MP 제외)인지 확정할 수 없습니다.
삼성이 공개한 소스만 그런 것이고 실제 들어간 것은 CPU 마이그레이션이라는 식의 해석도 가능해지니까요.

Linaro의 인터뷰 내용을 보면 CPU 마이그레이션인게 맞는데,

사용코어, 클럭 모니터링 앱들을 보면 클러스터 마이그레이션이 맞는 것 같기도 합니다.
개인적으로 확신이 없네요.

낮게 잡아서 클러스터 마이그레이션이라면 향후 CPU 마이그레이션, 나아가 MP까지 지원이 가능하냐가 문제인데 그 부분을 살펴보지요.
우선 빅리틀의 하드웨어, 소프트웨어 모델을 보겠습니다.



빅리틀 모델과 관계없이 하드웨어 구조는 모두 동일하다고 볼 수 있습니다.
어떤 모델이든 방식만 다를뿐 A7, A15 사이에 코어 전환이 이루어지고,
이를 위해서는 데이터 공유를 위한 CCI-400과 인터럽트 컨트롤러인 GIC-400이 들어가야 합니다.

즉, 최소한 클러스터 마이그레이션을 지원하고 있는 엑시노스5410은 CPU 마이그레이션, MP까지 하드웨어적으로 지원 가능합니다.



빅리틀 모델에서 차이를 만드는 것은 결국 소프트웨어입니다.
그런데 이 부분은 결국 시간이 해결해줄 것이기때문에 이르든 늦든 구현될 것입니다.

갤럭시S4에 CPU 마이그레이션이나, MP가 적용될 것인가. 라는 문제에서 가장 중요한건 삼성의 지원의사입니다.
삼성이 지원의사가 있다면 늦더라도 펌업의 형태로 지원이 이루어지겠지만, 지원의사가 없다면 기술적으로 가능해도 지원이 이루어지지 않을겁니다.



테스트 자료에 따르면 CPU 마이그레이션이 A7에 근접하는 에너지 소비를 보이고, MP 모델이 A7의 두 배 수준입니다.
MP의 경우, 튜닝의 여지가 많기때문에 CPU 마이그레이션 수준으로 내려갈 가능성이 높다고 봅니다.

MP 모델의 경우, 8코어를 모두 사용하기때문에 소비전력, 발열에서 문제가 있지 않겠느냐는 의견도 있습니다만, 8코어를 모두 사용할 수 있다고해서 무조건 8코어가 다 돌아간다는 얘기는 아닙니다.
아무리 로드가 낮아도 최소 A7 4코어가 돌아가고 있어야하는 클러스터 마이그레이션에 비하면,
동작 코어수와 구성을 자유자재로 운용할 수 있는 MP쪽의 전력효율이 높을 수 밖에 없습니다.
물론 최대전력은 높겠지만, 게임에서도 A7 쿼드로 충분한 상황에서 벤치마크를 제외하고 모든 코어를 사용하는 상황이 일어날지 의문입니다.


- 요약
1. 갤럭시S4는 하드웨어적으로 모든 빅리틀 모델을 지원한다.
2. 현재 지원하지 않는 모델의 소프트웨어 개발도 시간문제.
3. 결국 관건은 삼성의 지원의사.




 

반응형

댓글