EAS(Energy-Aware Scheduler) 스케쥴러 정리

마쉬멜로 소스를 받으려는데 mr1이 있고 mr1-eas가 있어서 뭐로 받아야할지 궁금해서 찾아보다가 신기한걸 찾아서 정리해보았다

참고 링크

(http://www.linaro.org/blog/core-dump/energy-aware-scheduling-eas-project/)

깊은 지식 없이 바로 찾아서 정리했기 때문에 틀린 내용이 많을 수 있다

scheduler - OS에서 돌아가는 여러 프로세스들의 실행 우선 순위를 결정 배분

cpu를 어느 순간의 시간동안 어떤 프로그램이 돌게 할지 정하며 시스템 목적에 따라 여러가지 정책이 있다

예시#1 - cpu연산이 별로 필요 없는 카톡(순위 낮음), cpu연산이 무지막지 필요한 게임(순위 높음)

예시#2 - cpu연산은 조금하고 외부 장치 i/o를 많이 하는 프로그램(순위 낮음), 

            cpu연산이 주되고 외부 장치 i/o는 드문 프로그램(순위 높음)

          -> i/o 시간은 cpu가 연산하는 비해 상대적으로 엄청나게 느리기 때문에 i/o를 기다리는 동안

 스케쥴러는 다른 프로세스에게 cpu 사용을 넘기도록 한다(task scheduling)

governor - 유휴 상태(cpuidle)나 활성화 상태(cpufreq)에 진입하도록 결정하는 정책이다

cpu frequency, voltage를 scaling하며 이를 통해 퍼포먼스와 베터리 소모량을 조절할 수 있다

예를 들어서 cpufreq의 여러 governor중에 Interactive governor를 설명하면

latency를 중요시 하는 디자인으로 설계 되었으며 cpu에 걸리는 부하에 따라 적당히 cpu 클럭 속도를 조절하도록 되어있다

cpu에 걸리는 부하는 짧은 시간동안 얼마나 사용하는지 샘플링을 하는데 이 비율(샘플링 레이트) 역시 중요하다

스케쥴러는 작업량이나 i/o 대기, 우선 순위 등에 따라 적당히 cpufreq와 cpuidle subsystem으로 프로세스들이 공평하게 cpu를 쓸 수 있도록 한다(위의 그림 참고)

즉 스케쥴러는 cpu에 균등하게 부하가 걸리도록 노력을 하지만 전력 소모에 대한 고려는 하지 않아 문제가 된다

위 그림을 참고로 스케쥴러 하부의 cpufreq, cpuidle subsystem은 각각 cpu 속도를 늦추거나 idle하게 만드는 식으로 각자 전력을 아끼기 위해 노력한다

CPUIdle

the menu governor

CPUFreq

Interactive governor

CPUFreq?

CPU Driver로 cpu frequency, voltage scaling을 통해 실시간으로 clock 속도를 조절할 수 있음

별건 아니고 그냥 참고

문제는 이러한 스케쥴러의 코드는 모든 cpu코어가 동일한 구조와 전력소모, 성능을 가지고 있다는 가정 하에 즉 데스크탑 cpu 구조 기반으로 작성되어 있다는 점이다

요즘 휴대폰에서 많이 사용되는 cpu 구조인 ARM의 big.LITTLE 를 예로 들자

이 구조는 적은 연산이 필요할 경우 느리지만 적은 전력을 소모하는 코어(LITTLE)를 계산량이 많이 필요할 때는 고성능 big 코어를 사용한다

이들의 코어에 동일한 부하를 50%씩 준다고 가정하면 스케쥴러 입장에서는 균등히 부하를 나눠주므로 매우 일을 잘하고 있다고 생각하지만 실제로는 LITTLE코어와 big 코어의 전력 사용량이 다르므로 최적의 전력소모 상태는 아니라고 할 수 있다

PM(Power Management) subsystem은 가버너에 휴리스틱 알고리즘이 있어 성능에 영향없이 cpu가 전력을 절약할 수 있는 최적의 시간을 예측한다

이 휴리스틱 루틴은 현재의 cpu 활용정도를 측정하기 위해서 그들이 소유한 수단을 사용한다 그리고 시스템의 변화에 반응하기 위해 반드시 여러번 수행되어야 한다

게다가 스케쥴러는 SoC의 power topology에 대한 어떠한 배경 지식 없이 설계 되었기 때문에 task 스케쥴링을 통해 지속적으로 휴리스틱의 예측을 깨뜨린다

(뭔가 내용이 이상한데? 게다가??? 그러나가 아니라??)

번역하기 싫다

대충 핵심은 task들의 cpu 부하나 i/o wait같은 것들을 파악하기 위한 최고의 위치는 스케쥴러라는 것

A key observation here is that the scheduler is the best place to know about past, current and immediate-future utilisation of the CPU since it controls where to place various tasks. 

So we could, in theory, scale the frequency of the source and destination CPUs (decrease and increase them respectively) during a task migration from one CPU to another. 

Similarly, the scheduler could arrange for tasks to be scheduled on fewer CPUs, thereby allowing the remaining CPUs to be shut-off to save power. Developers could become more proactive in their ability to take advantage of smarter task scheduling to save energy.

키 이슈들

1. 스케쥴러는 SoC의 power topology의 어떠한 관념도 가지고 있지 않다

task를 어떤 core에서 돌릴껀지 현재의 스케쥴링에 사용되는 휴리스틱 기법보다 더 나은 기법을 사용하도록 만들어야 한다

(대충 이런 의미 일 것이라고 추정중 ㅈㅅ합니다 영어 못하는데 설쳐서)

2. 스케쥴러와 PM 프레임워크의 통합을 하는 동안 기존 리눅스 커널에 작성된 cpu는 동일하다는 가정이 담긴 코드들을 고치는 중이다 

그래서 big.LITTLE 시스템에서 더욱 포괄적으로 잘 동작하도록 만들었다(heterogeneous multi-processing) 

컴퓨터에 들어가는 x86 cpu는 멀티코어라도 모든 코어가 동일한 스펙이므로 상관 없지만

요즘 휴대폰에 들어가는 arm 계열 cpu는 big.LITTLE 구조로 빠른 동작 코어와 느린 코어가 하나의 cpu에 같이 들어있는 

즉 코어의 종류에 따라 전력 소모가 틀린 구조에 대한 고려가 없다 아마도 이런 이야기인거 같다

3. CPUIdle-scheduler 통합에 2가지 진행중인 작업이 있다

a. CPUIdle과 스케쥴러 안에서 idle task의 더욱 긴밀한 통합

(Tighter integration of the idle task in the scheduler with CPUIdle)

b. CPUIdle core의 간소화와 idle path의 추척 용이성 향상

menu governor 교체: performance multiplier 같은 다음 wakeup 이벤트를 예측하기 위해 메뉴 가버너를 사용하는 몇몇의 휴리스틱들은 

다른 시스템에서 그닥 잘 동작하지 않는 단지 x86 시스템들에서 계산된 매직넘버일 뿐이다

static inline int performance_multiplier(void)

{

int mult = 1; //default;

mult += 2 * get_loadavg();

mult += 10 * nr_iowait_cpu();

return mult;

}

이런식의 2 * 평균로드값, 10 * io wait cpu수 를 매직넘버라고 의미하는듯

왜 2인지 10인지 모르니까 ㅎㅎ

새로운 IO latency tracking framework 을 통해 다음 IO 이벤트에 대한 예측을 더 효율적으로 하여 기존 메뉴가버너 보다 낫게 하였고 task-specific에서 device-specific으로 latency가 추적 되도록 노력했다

(아무래도 모바일 플랫폼이 기존 x86 시스템 보다는 i/o 가 더 중요해서 그런 것 같다

 워낙 개별 모듈로 분리된 입력 장치들이 많고 각각 파트별 전력 소모, latency가 다르니 말이다)

4. CPUFreq 그리고 스케쥴러를 더 잘 통합하기 위해 cpu type에 따라 서로 다른 작업 부하를 주도록 고쳐야 했다

(big.LITTLE 같은)

예를 들어 500Mhz core의 20% 부하 = 100Mhz 는 1Ghz core의 10% 부하와 같다

이하 Scheduler-driven DVFS라든가 등등 내용 생략

*** DVFS(dynamic voltage and frequency switching ) 

전력인가량에 따라 클럭 속도를 바꿀 수 있는 그런거

cpu에 국한된게 아니라 ram, pci-e, vga 등의 제어도 가능하다고 한다

5. 그런거 없다

그래서 바꿨답디다

 

결과 

1. 전력 소모 감소 그리고 퍼포먼스 강화에 스케쥴러를 최적화 함

2. big.LITTLE 시스템에서도 정확하게 스케쥴링 된다

3. SMP 시스템에서 PM의 성능 향상이 있음

4. 온도 관리를 위한 메카니즘을 제공함

기타 참고 url

http://lwn.net/Articles/602479/

https://www.linaro.org/blog/core-dump/summary-energy-aware-scheduling-workshop-linux-kernel-summit-2014/

기타 참고 내용

drivers/cpufreq/arm_big_little_dt.c 

big.LITTLE CPUFreq Interface driver

bL platform driver로 아래의 bL_cpufreq_register를 호출한다

drivers/cpufreq/arm_big_little.c

cpufreq_register_driver()를 호출해서 cpufreq_driver structure를 CPUFreq core에 등록하도록 한다

1줄 요약

스케쥴러를 모바일 환경에 맞게 개선함