[리눅스 커널] PM - Linux Kernel Power Management Overview

글의 참고

- http://www.wowotech.net/pm_subsystem/pm_architecture.html

- https://slowbootkernelhacks.blogspot.com/2014/03/linux-power-management_2252.html?m=0 

- https://www.kernel.org/doc/html/next/power/runtime_pm.html

- https://by1994.github.io/linux-power/

- https://software-dl.ti.com/processor-sdk-linux/esd/docs/06_03_00_106/AM335X/linux/Foundational_Components/Kernel/Kernel_Drivers/Power_Management.html

- sitara_boot_camp_am335x_pm_sw_training.pdf

- https://scholarship.rice.edu/bitstream/handle/1911/87791/XU-DOCUMENT-2014.pdf;jsessionid=FE892DD3CD1E6B0086E9A17B787C53C0?sequence=1 

- https://www.zhihu.com/column/c_1589903721982472192

---

글의 전제

- 내가 글을 쓰다가 궁금한 점은 파란색 볼드체로 표현했다. 나도 모르기 때문에 나중에 알아봐야 할 내용이라는 뜻이다.

- 밑줄로 작성된 글은 좀 더 긴 설명이 필요해서 친 것이다. 그러므로, 밑 줄 처친 글이 이해가 안간다면 링크를 따라서 관련 내용을 공부하자.

---

글의 내용

- Overview

" 리눅스 커널의 파워 매니지먼트는 크게 2가지로 나눠 볼 수 있다.

1. Static Power Management : `system wide` 하게 적용되는 방법이다. 즉, 시스템에 존재하는 모든 디바이스에게 한 시점에 동시에 적용되는 파워 매니지먼트 방식이다. 가장 강력하지만, 하나의 디바이스라도 절전 모드 상태 진입에 동의하지 않을 경우, 시스템 전체가 절전 모드 되지 못한다. 즉, 유연하지 못하다는 것이 단점이다[참고1]. 

2. Dynamic Power Management : `Dynamic` 이라는 말은 `Activity` 를 기준으로 2가지 전략이 나눠진다.
 2.1 Activity PM : 디바이스가 동작중인 상태에서 상태를 바꿔서 전력 소비를 줄인다. Off 가 아니다. 여러 개의 상태에서     전력   소비가 더 많은 상태로 바꾸는 것이다.
 2.2 Idle PM : 디바이스가 `할 일이 없으면` 개별적으로 IDLE 모드로 들어간다. `systme suspend` 와는 다르게 각각의 디바이스가 개별적으로 suspend 될 수 있다.

1. Activity PM - 디바이스가 동작중인 상태에서 상태를 바꿔서 전력 소비를 줄인다. Off 가 아니다. 여러 개의 상태에서 전력 소비가 더 많은 상태로 바꾸는 것이다. 2. Idle PM - 디바이스가 `할 일이 없으면` 개별적으로 IDLE 모드로 들어간다. `systme suspend` 와는 다르게 각각의 디바이   스가 개별적으로 suspend 될 수 있다.

 

 

" 아래 그림은 리눅스 커널에 존재하는 `Statis PM`, `Activity PM`, `Idle PM` 이 각각 커널의 어떤 컴포넌트와 연결되는지를 보여준다(아래에는 `Thermal` 관련 컴포넌트가 생략되어 있다. `Thermal` 은 Power 와는 직접적인 관련이 없기 때문에, 생략한 것이 아닌가 추측해본다). `Idle PM` 에서는 다시 `CPU` 와 `Device` 가 서로 다른 파워 컨트롤 방식을 사용한다.

 

http://events17.linuxfoundation.org/sites/events/files/slides/Intro_Kernel_PM.pdf

 

 

 

- System PM

1. Suspend / Resume - 전체 시스템을 한 번에 절전 상태 (Suspend To RAM) 로 변경하는 방법.

2. wakeup sources - system suspend 진입을 막는 subsystem(android 의 wake lock 과 동일한 메커니즘)

3. autosleep - 시스템에 active wakeup sources 가 없으면, system suspend 로 진입하는 테크닉 

 

 

 

- Active PM

1. CPUfreq - 동적 전압 스케일링 (Dynamic Voltage and Frequency Scaling; DVFS) 를 위한 프레임워크다. governor 가 정기적으로 모니터링을 하면서 cpu load 에 따라 일이 별로 없을 때는 전력 소비를 절약하기 위해 CPU 를 낮은 클락 주파수 & 전압으로 동작하게 하고, 일이 많을 때는 성능을 위해 높은 클락 주파수 & 전압으로 동작하게 할 수 있습니다. governor 의 종류에 따라 다른 방식으로 동작할 수도 있습니다.

2. Operating Performance Point(OPP) - SoC에 존재하는 모든 컴포넌트들이 항상 풀-파워로 동작해야 하는 것은 아니다. 그래서, SoC 안에 비슷한 클락 및 전원을 사용하는 친구들을 하나의 그룹을 묶고, 사용 시나리오에 따라 클락과 전원을 다르게 공급해주는 방식이 `OPP` 라고 한다[참고1]

3. Regulator : 전압 (voltage)을 공급하는 PMIC 를 제어하기 위한 프레임워크다. 전압값을 변경하거나 켜고 끄는 등의 동작을 할 수 있다. CPUfreq 등 다른 드라이버들과 함께 사용된다.

4. Clock : Clock 을 낮추거나 Clock 공급을 중단할 때 사용할 수 있는 framework 다.

5. Devfreq : `devfreq`는 `Generic Dynamic Voltage and Frequency Scaling (DVFS) Framework for Non-CPU Devices` 라고 공식 문서에 적혀있다. 즉, OPP 개념을 CPU가 아닌, Non-CPU Devices 들에게 적용시키는 방법이다. 그래서, 각 디바이스별로 자신만의 `governor`를 가질 수 있다[참고1 참고2].

6. EAS(`Energy Aware Scheduler`) : 리눅스에서 기본적으로 사용되는 `CFS(Completely Fair Scheduler`) 방식은 성능에 초점이 맞춰져있다. 즉, 시간 당 얼마만큼의 프로세스들이 수행될 수 있는가에 초점이 되어있다. 그런데, EAS는 성능이 아닌, 소비 전류를 줄이는 방식에 초점이 맞춰진 스케줄링 방식이다[참고1].

7. Thermal : `Thermal Framework`를 사용하면 온도가 너무 높은 경우 Cooling을 하거나 CPU 클락 주파수를 낮춰서 온도를 낮출 수 있다(일반적으로, 퍼포먼스가 증가하면 온도도 상승하며, 퍼포먼스가 감소하면 온도가 낮아진다).

 

 

 

- Idle PM

" CPUidle : CPU가 할일이 없을 경우, 하드웨어적으로 `power save` 모드로 들어가는 것을 의미한다. CPU 아키텍처마다 CPUidle은 여러 가지 상태를 가질 수 있다. 대표적으로 ACPI는 CPUidle 상태를 `C-STATE`라고 해서 여러 개의 상태를 정의하고 있다. `C-STATE`는 숫자가 작을 수록 `풀-파워` 동작을 의미한다. 즉, `C0`은 풀-파워 동작을 나타내고, 숫자가 커질수 록 `Deeper Sleep`을 의미한다[참고1 참고2].

" Tickless : CPUidle 상태에서 timer interrupt(tick)을 Off 시키는 방법이다. CPUidle 상황에서 정기적으로 발생하는 타이머 인터럽트는 쓸데없는 전력 소비만 늘리는 상황이된다. 리눅스 커널에서는 `CONFIG_NO_HZ`를 통해서 커널 빌드타임 시점에 `tickless kernel`로 생성이 가능하다[참고1 참고2].

" CPU hotplug - CPU hotplug 란 사용하지 않는 CPU 의 전원을 아예 꺼버리는 방법입니다. 예를 들어, `Suspend To RAM` 처럼 전체 시스템이 절전모드로 가는 경우, CPU 가 hotplug out 되어 꺼집니다. CPU가 hotplug out 되는 경우에는, CPU가 다시 켜지기 (hotplug-in) 전까지는 아예 스케줄링에서도 제외된다. 위의 CPUidle 은 스케줄링이 필요할 때 CPU가 저전력 모드에 있다가 다시 C0 상태로 돌아올 수 있다는 차이점이 있다[참고1 참고2].

" Runtime PM : 전체 시스템이 아닌 일부 디바이스 등의 전원을 켜거나 끄도록 관리할 수 있습니다.

" PM domain : 동일한 파워 도메인을 갖는 디바이스들을 하나의 그룹으로 묶어서 관리하는 방법. 예를 들어, A라는 파워 도메인에 속한 모든 디바이스가 할 일이 없으면, A 파워 레귤레이터를 Off 시킨다.

" PM QoS : CPUidle 상태로 진입하려고 할 때, 어떤 CPUidle 상태로 진입해야 하는지 결정해야 한다. 이 때, `PM QoS`를 통해 CPU는 적절한 IDLE 상태를 선택할 수 있게 된다. 왜냐면, `PM QoS`는 PM 관련 해서 여러 가지 제약 사항들이 관리하고 있기 때문이다. 예를 들어, CPU가 CPUidle 상태중에서도 가장 강력한 C10 상태로 진입하려고 할 때, `PM QoS`를 통해 C10 상태로 진입하려는게 적합한지를 판단하게 된다[참고1 참고2].

 

 

 

- Work in progress

" 2023.03 시점을 기준으로, 리눅스 커널 파워 매니지먼트에서 그나마 최신 전략은 2가지를 들 수 있다.

1. Generic Power Domain(`genpd`) : Runtime PM을 기반으로 하며, 파워 도메인이 같은 디바이스들을 묶어서 관리하는 방법

2. Energy Aware Scheduling : `CPUidle`과 `CPUfreq` 방식을 기반으로 한 프로세스 스케줄링 방식

 

 

" 기존의 CPU 와 I/O 디바이스들은 서로 다른 방식의 전원 관리 기법을 사용했다. 예를 들어, 디바이스들은 `Runtime PM`, `Devfreq` 등의 방식을 사용하고, CPU는 `CPUidle`, `CPUfreq` 방식을 사용했었다. 그러나, `genpd` 는 CPU 에 `Runtime PM` 방식을 적용할 수 있도록 인터페이스를 확장했다.