Google Pixel 스마트폰은 시중에서 가장 빠른 Android 휴대폰 중 하나입니다. EAS(Energy Aware Scheduling)는 휴대폰이 매우 부드러운 이유 중 하나입니다.
과거에 Linux가 Linus Torvalds의 머릿속에 있는 하나의 아이디어였을 때, CPU는 적은 전력으로 엄청난 양의 에너지를 필요로 하는 단일 코어 개체였습니다. 최초의 상용 프로세서인 Intel 4004는 단일 코어에서 740kHz의 클럭 속도로 실행되었습니다. 그 당시에는 로드 스케줄러가 필요 없었습니다. 로드 스케줄링은 수십 년 후에 출시된 IBM Power 4와 같은 듀얼 코어 "거대형"용으로 예약되었습니다. 이는 엄청난 1.1GHz ~ 1.9GHz에서 실행되었으며 이러한 코어를 올바르게 활용하려면 프로그램과 시스템이 필요했습니다. 이러한 기계에서 다중 코어를 사용하는 소프트웨어 알고리즘을 어떻게 얻었습니까? 이전에 당사 포럼에서 EAS(Energy Aware Scheduling)에 대해 들어보셨을 것입니다. 이는 Google Pixel 스마트폰이 그토록 뛰어난 성능을 발휘하는 이유 중 하나입니다. EAS의 장점은 무엇이며 어떻게 이 지점에 도달하게 되었습니까? 이를 설명하기 전에 Linux 로드 스케줄러에 대해 이야기해야 합니다.
Linux 로드 스케줄러의 진화
라운드 로빈 스케줄링
라운드 로빈 처리는 설명하고 이해하기에는 간단한 개념이지만, 단점을 파악하기에는 훨씬 더 간단한 개념입니다. 라운드 로빈은 시간 분할을 사용하여 각 프로세스에 시간을 할당합니다. 컴퓨터에서 4개의 프로세스가 실행되고 있다고 가정해 보겠습니다.
- 프로세스 A
- 프로세스 B
- 프로세스 C
- 프로세스 D
이제 라운드 로빈 스케줄러의 작업을 수행해 보겠습니다. 다음 단계로 넘어가기 전에 각 프로세스에 100밀리초(시간 분할)를 할당하겠습니다. 이는 프로세스 A가 처리를 수행하는 데 100밀리초가 소요된 다음 프로세스 B로 이동한다는 의미입니다. 애플리케이션 작업을 수행하는 데 250밀리초가 걸리는 경우 작업을 완료하기 위해 이 프로세스를 3번 거쳐야 합니다. 이제 프로세스 A와 프로세스 B가 코어 1에 할당되고 프로세스 C와 프로세스 D가 코어 2에 할당되도록 이를 여러 코어에 걸쳐 확장합니다. 이는 O(n) 스케줄링(라운드 로빈과 비슷하지만 에포크를 사용하고 동적 할당을 허용함)으로 대체되었습니다. 시간), O(1) 스케줄링(최소화된 오버헤드, 무제한 프로세스 지원), 마지막으로 Completely Fair Scheduler (CFS). CFS는 2007년 10월 Linux 커널 버전 2.6.23에 병합되었습니다. 그 이후로 정밀 검사가 이루어졌으며 여전히 Linux 시스템의 기본 스케줄러입니다.
완전히 공정한 스케줄러
Completely Fair Scheduler는 처음부터 Android에 존재했으며 규모가 크지 않은 경우에 사용됩니다. 작은 장치. 지능형 알고리즘을 사용하여 처리 순서, 할당된 시간 등을 결정합니다. 이는 "가중 공정 큐잉"이라고 불리는 잘 연구된 스케줄링 알고리즘의 실제 구현 예입니다. 이는 기본적으로 시스템 프로세스와 시스템에서 실행되는 기타 우선 순위가 높은 프로세스에 우선 순위를 제공하는 데 중점을 둡니다. 기계. 그것이 크게 실행된다면. 작은 장치에서는 모든 코어가 동일하게 인식됩니다. 저전력 코어는 집약적인 애플리케이션을 실행해야 하거나 더 나쁜 경우에는 그 반대가 발생할 수 있으므로 이는 좋지 않습니다. 예를 들어 음악을 듣기 위한 디코딩은 빅 코어에서 수행될 수 있으므로 불필요하게 전력 소비가 증가합니다. 이것이 바로 대규모를 위한 새로운 스케줄러가 필요한 이유입니다. LITTLE은 실제로 코어의 차이를 전력 효율적으로 인식하고 활용할 수 있는 제품입니다. 이것이 현재 대부분의 Android 휴대폰에서 실행되는 표준 로드 스케줄러인 HMP(이기종 다중 처리)가 등장하는 곳입니다.
이기종 다중 처리
이것은 모든 규모의 표준 로드 스케줄러입니다. Google Pixel 외에 최근 몇 년 동안 출시된 작은 장치입니다. HMP는 큰 것을 활용합니다. LITTLE 아키텍처는 우선 순위가 낮고 덜 집약적인 작업을 전력을 덜 소비하는 작은 코어에 위임합니다. HMP는 실수 없이 무엇이 큰 코어로 가야 하고, 무엇이 작은 코어로 가야 하는지 아는 점에서 "안전"합니다. 이는 작동하며 개발 측면에서 설정하는 데 EAS와 같은 것보다 훨씬 적은 노력이 필요합니다. 이에 대해서는 잠시 후에 설명하겠습니다. HMP는 전력 인식을 위한 CFS의 확장일 뿐입니다.
HMP는 추측을 하지 않으며 향후 프로세스를 예측하지도 않습니다. 이는 좋지만 장치가 EAS를 실행하는 장치만큼 유동적이지 못하고 약간 더 많은 배터리를 소모하는 이유이기도 합니다. 마지막으로 EAS(Energy Aware Scheduling)가 등장합니다. EAS는 더 많은 OEM이 채택함에 따라 ROM 및 커널 개발의 미래가 될 것이라고 굳게 믿습니다.
에너지 인식 스케줄링
EAS(Energy Aware Scheduling)는 포럼 사용자들이 이야기하는 차세대 기술입니다. OnePlus 3(또는 당연히 Google Pixel)를 사용한다면 포럼에서 이에 대해 들어본 적이 있을 것입니다. Qualcomm Snapdragon 845를 통해 주류로 출시되었으므로 이러한 장치 중 하나를 가지고 있다면 이미 EAS 지원 스마트폰을 보유하고 있는 것입니다. 다음과 같은 커널 형태의 EAS 렌더제니스 그리고 다음과 같은 ROM VertexOS 그리고 퓨어퓨전 OnePlus 3 포럼이 전성기에 돌풍을 일으키고 있었습니다. 물론 Google Pixel에는 EAS도 함께 제공됩니다. 향상된 배터리 수명과 더 나은 성능을 약속하는 가운데, 무엇이 문제일까요?
Energy Aware Scheduling은 CFS 또는 HMP와 같은 모든 장치에 보편적이지 않기 때문에 간단하지 않습니다. EAS를 사용하려면 에너지 모델을 기반으로 실행 중인 프로세서에 대한 이해가 필요합니다. 이러한 에너지 모델은 최적의 성능을 제공하기 위해 끊임없이 테스트하고 노력하는 엔지니어 팀에 의해 만들어집니다. Snapdragon 820과 821은 기본적으로 동일하므로 OnePlus 3의 맞춤형 커널은 Google Pixel 에너지 모델을 사용합니다. Snapdragon 845가 탑재된 장치는 EAS를 활용할 수 있으며 OnePlus 6은 어느 정도 이를 활용합니다. Google Pixel 기기만큼 조정되지는 않지만 작업을 완료합니다. 다음은 EAS를 갖춘 더 나은 프로세서를 갖춘 OnePlus 6에도 불구하고 Pixel 2 XL이 여전히 부드러움 면에서 이를 능가하는 방법에 대한 예입니다. 이 두 이미지는 모두 당사에서 가져온 것입니다. 속도 중심의 검토 원플러스 6의
그래프를 이해하는 데 어려움이 있는 경우 아래 이미지를 참고하세요. 녹색 선을 초과하는 것은 프레임이 떨어졌음을 나타내며 최악의 경우 눈에 띄는 끊김 현상이 나타납니다.
EAS의 OnePlus 6 구현은 동일한 SoC를 사용하는 Google Pixel에서 볼 수 있는 것처럼 완전한 구현으로 보이지 않기 때문에 흥미롭습니다. 스케줄러 조정 가능 항목도 그다지 의미가 없으므로 예상만큼 성능 효율적이지 않은 이유를 설명할 수 있습니다. 시스템은 대부분의 작업에서 저전력 코어를 우선시하므로 전력 소비가 매우 보수적입니다.
튜너블은 CPU 거버너에 전달되는 매개변수 집합으로, 거버너가 주파수 측면에서 특정 상황에 반응하는 방식을 변경합니다. 그런 다음 스케줄러는 다른 프로세서에서 작업을 배치할 위치를 결정합니다. OnePlus 6의 조정 가능 항목은 저전력 코어 작업의 우선 순위를 지정하도록 설정되어 있습니다. 또한 Google Pixel 2가 엄청난 양의 입력 부스트를 제공하여 8개 코어를 모두 항상 온라인 상태로 유지하는 것도 도움이 되지 않습니다. Google은 또한 인터럽트 밸런서 프레임 드랍을 제거하고 성능을 향상시키는 데 도움이 됩니다.
그렇다면 EAS는 어떻게 작동하나요? 특정 조건에서만 그렇게 효율적인 이유는 무엇입니까?
Energy Aware Scheduling에서는 에너지 모델을 사용해야 하며, 위에서 언급한 것처럼 이를 완벽하게 만들기 위해 많은 테스트와 작업이 필요합니다. EAS는 모두 독립적으로 작동하는 커널의 서로 다른 세 가지 핵심 부분을 통합하려고 시도하며, 에너지 모델은 이를 통합하는 데 도움이 됩니다.
- Linux 스케줄러(위에서 언급한 CFS)
- 리눅스 CPU유휴
- 리눅스 CPU 주파수
스케줄러 아래 3개 부분을 모두 통합하고 함께 계산하면 에너지 절약 가능성이 높아집니다. 함께 계산하면 최대한 효율적으로 작업할 수 있기 때문입니다. CPUIdle은 CPU가 유휴 모드로 전환되어야 하는 시점을 결정하려고 시도하는 반면, CPUFreq는 CPU를 증가 또는 감소시킬 시점을 결정하려고 시도합니다. 이 두 모듈 모두 에너지 절약을 주요 목표로 합니다. 뿐만 아니라 프로세스를 최상위 앱, 시스템 배경, 전경 및 배경의 네 가지 c그룹으로 분류합니다. 처리될 작업은 이러한 범주 중 하나에 배치된 다음 해당 범주에 CPU 성능이 부여되고 작업은 다른 CPU 코어에 위임됩니다. top-app은 완료 우선순위가 가장 높으며 그 다음은 전경, 배경, 시스템 배경 순입니다. 기술적으로 배경은 시스템 배경과 동일한 우선순위를 갖지만 시스템 배경은 일반적으로 더 많은 작은 코어에 액세스할 수도 있습니다. 실제로 Energy Aware Scheduling은 Linux 커널의 핵심 부분을 가져와 모두 하나의 프로세스로 통합합니다.
장치를 깨울 때 EAS는 가장 얕은 유휴 상태의 코어를 선택하여 장치를 깨우는 데 필요한 에너지를 최소화합니다. 이는 필요하지 않은 경우 대규모 클러스터를 깨우지 않으므로 장치 사용에 필요한 전력을 줄이는 데 도움이 됩니다. 로드 추적도 EAS의 매우 중요한 부분이며 두 가지 옵션이 있습니다. "엔티티별 로드 추적"(PELT)은 일반적으로 로드 추적에 사용되며, 이 정보는 빈도와 CPU 전체에 작업을 위임하는 방법을 결정하는 데 사용됩니다. "Window-Assisted Load Tracking"(WALT)도 사용할 수 있으며 Google Pixel에서 사용됩니다. VertexOS와 같은 포럼의 많은 EAS ROM은 WALT 사용을 선택합니다. 많은 ROM은 WALT 또는 PELT를 사용하여 두 가지 버전의 커널을 출시하므로 결정하는 것은 사용자의 몫입니다. WALT는 CPU 주파수의 최고치가 높은 반면 PELT는 보다 일관성을 유지하려고 노력합니다. 로드 추적기는 실제로 CPU 주파수에 영향을 미치지 않으며 단지 CPU 사용량을 시스템에 알려줍니다. CPU 사용량이 높을수록 더 높은 주파수가 필요하므로 PELT의 일관된 특성은 CPU 주파수가 천천히 증가하거나 감소한다는 것입니다. PELT는 더 높은 CPU 부하 보고 쪽으로 치우치는 경향이 있으므로 더 높은 배터리 비용으로 더 높은 성능을 제공할 수 있습니다. 그러나 두 로드 추적 방법 모두 지속적으로 패치되고 개선되고 있기 때문에 현 시점에서는 어느 로드 추적 시스템이 더 좋다고 말할 수는 없습니다.
어느 쪽이든 사용된 로드 추적 방법에 관계없이 효율성이 향상된다는 것은 분명합니다. 단순히 프로세서에서 작업을 처리하는 것이 아니라 작업을 분석하고 이를 실행하는 데 필요한 에너지 양을 추정합니다. 이러한 영리한 작업 배치는 작업이 훨씬 더 효율적인 방식으로 완료되는 동시에 시스템 전체를 더 빠르게 만든다는 것을 의미합니다. EAS는 최소한의 전력 사용으로 가능한 가장 부드러운 UI를 얻는 것입니다. 여기서는 schedtune과 같은 다른 외부 구성 요소가 작동합니다.
Schedtune은 완료할 작업을 보다 세밀하게 제어할 수 있는 두 개의 조정 가능 항목으로 각 cgroup에서 정의됩니다. 이는 여러 CPU에 대한 작업 분산을 제어할 뿐만 아니라 시간에 민감한 작업을 더 빨리 완료하기 위해 인식된 로드를 부풀려야 하는지 여부도 제어합니다. 이렇게 하면 사용자가 사용하는 포그라운드 애플리케이션과 서비스가 느려지거나 불필요한 성능 문제가 발생하지 않습니다.
에너지 인식 스케줄링(Energy Aware Scheduling)이 차세대 기술이기는 하지만 이미 존재하고 있으며 한동안 존재해 왔다고 주장할 수도 있습니다. Energy Aware Scheduling을 통해 점점 더 많은 장치가 주류를 이루면서 모바일 처리 효율성의 새로운 시대가 도래했습니다.
라운드 로빈, CFS, HMP 및 EAS의 장단점
내 그래픽 기술은 수준 이하이지만 각 스케줄러의 장단점이 무엇인지 요약하는 이미지를 함께 만들었습니다.
XDA 인정 기여자에게 특별한 감사의 말씀을 전하고 싶습니다. 모스타파 와엘 EAS의 다양한 측면에 대한 설명은 이 기사를 작성하는 데 큰 도움이 되었습니다. 또한 XDA 인정 개발자에게도 감사의 말씀을 전하고 싶습니다. 많은, XDA 인정 개발자 렌더깨짐 그리고 EAS에 대한 글을 써주신 Mostafa Wael. EAS 관련 부분에 관심이 있는 분들을 위해 Linaro에는 읽을 수 있는 EAS에 대한 많은 문서가 있습니다.