2편, [REF][TWEAKS] Kernel Governors, Modules, I/O Schedulers, CPU Tweaks, AIO App Configs

요즘 커널이나 거버너에 대해 궁금에 

궁금을 물어 시간이 날 때마다 번역중이다.

현재는 컴퓨터쪽에 종사를 하고 있지는 않으나

 최대한 원문에 왜곡됨이 없이 하는 중인데

쉽지도 않을 뿐더러간혹 틀린 부분도 있을 것이다.

그저 참고용으로만 사용되어지기를 빌면서...

(원문이 너무 길어 모바일에 맞게 수정은 못했다.

넓은 아량으로 이해를...)

 

원문 XDA developers 
[REF][TWEAKS] Kernel Governors, Modules, I/O Schedulers, CPU Tweaks, AIO App Configs (Click)

 

1) Ondemand:
Default governor in almost all stock kernels. 
거의 대부분 저장되어있는 커널들의 기본 거버너다. 

One main goal of the ondemand governor is to switch to max frequency as soon as 
there is a CPU activity detected to ensure the responsiveness of the system. 
Ondemand 거버너의 한 가지 주요 목표는 시스템의 응답을 보장하기 위해 CPU 활동이 감지되자마자 최대 주파수로 전환하는 것이다.

(You can change this behavior using smooth scaling parameters, refer Siyah tweaks at the end of 3rd post.)  
(smooth 스케일링 매개 변수를 이용해서 변경 가능하다. 3번째 포스트 끝에 Siyah tewaks를 참조하시오.)

Effectively, it uses the CPU busy time as the answer to "how critical is performance right now" question.
효과적으로, 그것은 CPU 비지타임을 "성능이 당장 얼마나 중요한가" 라는 질문에 대한 답변으로 이용한다.

So Ondemand jumps to maximum frequency when CPU is busy and decreases the frequency gradually 
when CPU is less loaded/apporaching idle. 
그래서 ondemand는 CPU가 바쁠 때 최대 주파수가 늘어나고, CPU가 부하가 적거나 
아이들이 되어 갈 때 점차적으로 주파수를 감소시킨다.

Even though many of us consider this a reliable governor, it falls short on battery saving 
and performance on default settings. 
우리들 중 많은 사람이 안정적인 거버너를 고려한다고해도 배터리 절약하기엔 부족하고 기본 설정에서의 성능이 떨어지게된다.

One potential reason for ondemand governor being not very power efficient is 
that the governor decide the next target frequency by instant requirement during sampling interval. 
ondemand 거버너가 절전효율에 별로인 하나의 잠재적 이유는 거버너가 샘플링 인터벌(추출간격)중 즉각적 요청에 의해 
다음 목표 주파수를 결정하기 때문이다.

The instant requirement can response quickly to workload change, but it does not usually reflect 
workload real CPU usage requirement in a small longer time and it possibly causes frequently change 
between highest and lowest frequency.
그 즉각적 요청은 작업량 변화에 신속하게 대응 할 수 있지만, 대개 다소 긴 시간에서는 실제 CPU사용에 필요한 
작업량을 반영하지 않을뿐더러 최고와 최저 주파수 사이에서의 변화가 빈번히 발생한다.

 

2) Ondemandx:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be 
a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. 
일시중지 / 대기 프로파일을 가진 기본적 ondemand이다. 이 거버너는 는 배터리 친화적 ondemand이다. 
화면 off시 최대 주파수는 500 MHz로 제한된다.

Even though ondemand is the default governor in many kernel and is considered safe/stable, 
the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching 
which are very low latency frequency transitions. 
ondemand가 많은 커널에서 기본 거버너이고 안전하고 안정적인 것으로 간주된다하더라도, ondemand/ondemandX 에 
대한 지원은 매우 낮은 지연 주파수 전환인 빠른 주파수 스위칭을 수행하는 CPU의 능력에 따라 달라진다.

I have read somewhere that the performance of ondemand/ondemandx were 
significantly varying for different i/o schedulers. 
난 ondemand/ondemandx의 성능은 다른 I/O 스케줄러에 따라 상당히 다양하다고 어디선가에서 읽었다.

This is not true for most of the other governors. 
이것은 대부분 다른 거버너들에도 사실이 아니다. 

I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
난 개인적으로 ondemand / ondemandx가 SIO I/O 스케줄러와 가장 잘 맞는다고 느낀다.

 

3) Conservative:
A slower Ondemand which scales up slowly to save battery. 
배터리 절약을 위해 천천히 클럭수를 높히는 느린 Ondemand이다. 

The conservative governor is based on the ondemand governor. 
Conservative 거버너는 ondemand 거버너를 기반으로 했다.

It functions like the Ondemand governor by dynamically adjusting frequencies based on 
processor utilization. 
그것은 ondemand 거버너와 비슷하게 프로세서 사용률을 기반으로 역동적으로 조정한 주파수에 의해 작동한다.  

However, the conservative governor increases and decreases CPU speed more gradually. 
하지만 conservative 거버너는 CPU 속도를 더 점진적으로 증가 또는 감소시킨다.

Simply put, this governor increases the frequency step by step on CPU load and jumps 
to lowest frequency on CPU idle. 
간단히 말하자면 이 거버너는 CPU 부하에 따라 단계적으로 주파수를 증가시키고 
CPU 아이들시 최저 주파수로 넘어간다.

Conservative governor aims to dynamically adjust the CPU frequency to current utilization, 
without jumping to max frequency.
Conservative 거버너의 목표는 최대 주파수로 뛰어넘지 않고 역동적으로 CPU 주파수를 현 사용률로 조정하는 것이다.

The sampling_down_factor value acts as a negative multiplier of sampling_rate 
to reduce the frequency that the scheduler samples the CPU utilization. 
sampling_down_factor value는 스케줄러가 CPU 사용률을 샘플링하는데 있어 
주파수를 줄이기 위한 sampling_rate의 부정적인 역할을 한다.

For example, if sampling_rate equal to 20,000 and sampling_down_factor is 2, 
the governor samples the CPU utilization every 40,000 microseconds.
예로, sampling_rate이 20,000이고 sampling_down_factor가 2라면, 
거버너는 CPU 사용률을 매 40,000 마이크로초마다 샘플링한다.

 

4) Interactive:
Can be considered a faster ondemand. So more snappier, less battery. 
빠른 ondemand로 볼 수 있다. 그래서 더 빠르고, 적은 배터리를 소모한다.

Interactive is designed for latency-sensitive, interactive workloads. 
Interactive는 민감한 지연시간, 효율적 부하 분산을 위해 설계되었다.

Instead of sampling at every interval like ondemand, 
it determines how to scale up when CPU comes out of idle. 
ondemand과 같이 매 주기마다 샘플링하는 것 대신에 CPU가 아이들상태에서 나올때 어떤 방식으로 클럭을 높힐지를 결정한다.

The governor has the following advantages: 
이 거버너는 다음의 장점이 있다:

1) More consistent ramping, because existing governors do their CPU load sampling in a workqueue
context, but interactive governor does this in a timer context,
which gives more consistent CPU load sampling. 
1) 기존의 거버너들은 workqueue context로 그들의 CPU 부하 샘플링을 하는데 비해서
더 일관된증가를 위해 interactive 거버너는 이것들을 일관된 CPU 부하 샘플링을 하는 timer context로 한다.

2) Higher priority for CPU frequency increase, thus giving the remaining tasks the CPU performance
benefit, unlike existing governors which schedule ramp-up work to occur 
after your performance starved tasks have completed. 

2) CPU 성능 benefit에 남은 작업 할당함으로서 성능을 요하는 작업이 끝난 후에 schedule ramp-up work가 작동하는 
기존 거버너들과는 달리 CPU 주파수 증가를 위한 더 높은 우선 순위을 둔다. 

Interactive It's an intelligent Ondemand because of stability optimizations. Why??
Interactive. 그건 안정성 최적화 덕분에 지능형 Ondemand이다. 왜??

Sampling the CPU load every X ms (like Ondemand) can lead to under-powering the CPU for X ms, 
leading to dropped frames, stuttering UI, etc.
CPU 부하를 X ms마다 (Ondemand처럼) 샘플링하는 것은 CPU를 X ms 동안 전력부족, 프레임을 떨어뜨리고, 
UI에 버벅임, 등등으로 이를 수 있다.

Instead of sampling the CPU at a specified rate, the interactive governor will check 
whether to scale the CPU frequency up soon after coming out of idle. 
특정 rate에서 CPU를 샘플링하는 대신에 interactive 거버너는 아이들 상태에서 나오자마자 CPU클럭을 높힐지 말지를 체크한다.

When the CPU comes out of idle, a timer is configured to fire within 1-2 ticks.
CPU가 아이들 상태에서 나올 때 타이머는 짧은 시간에 시작된다.

If the CPU is very busy between exiting idle and when the timer fires, 
then we assume the CPU is underpowered and ramp to max frequency.
만약 CPU가 아이들 상태에서 타이머가 시작될 때 사용량이 매우 높다면 CPU를 전력부족으로 가정하고 최대 주파수로 늘린다.

 

5) Interactivex:
This is an Interactive governor with a wake profile. More battery friendly than interactive.
이것은 wake프로파일이 있는 Interactive 거버너다. interative보다 더 배터리 친화적이다.

 

6) Lulzactive:
This new find from Tegrak is based on Interactive & Smartass governors and is one of the favorites. 
Tegrak이 개발한 interactive & Smartass 거버너 기반의 선호되는 것 중에 하나다.

Old Version: When workload is greater than or equal to 60%, the governor scales up CPU to
next higher step. 
전 버전 : 60%나 그 이상 부하가 걸리면, 거버너는 CPU는 다음 높은 단계로 클럭을 높힌다.

When workload is less than 60%, governor scales down CPU to next lower step. When screen is off,
frequency is locked to global scaling minimum frequency.
60% 이하로 걸리면, 거버너는 다음 낮은 단계로 CPU 클럭을 낮춘다. 스크린이 꺼지면,
주파수는 전역 스케일링 최저 주파수로 맞춰진다.

New Version: Three more user configurable parameters: inc_cpu_load, pump_up_step, pump_down_step.
신 버전: 사용자가 설정할 수 있는 매개변수들이 3개 더 있다 : inc_cpu_load, pump_up_step, pump_down_step.  

Unlike older version, this one gives more control for the user. 
전 버전과는 달리 이번 것은 사용자들이 더 조절 가능하게 해준다.

We can set the threshold at which governor decides to scale up/down. 
우리는 거버너가 클럭을 높힐지 낮출지를 결정할 threshold값을 정할 수 있다. 

We can also set number of frequency steps to be skipped while polling up and down.
또한 우리는 polling up/down시 건너 뛸 주파수 단계의 수를 정할 수 있다.

When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. 
부하가 inc_cpu_load 수치와 같거나 커질때 거버너는 pump_up_step 수치를 늘린다.

When workload is less than inc_cpu_load, governor scales CPU down pump_down_step steps down.
 부하가 inc_cpu_load 수치보다 낮을 때, 거버너는 pump_up_step 
수치를 낮춘다. 

Example:
Consider
inc_cpu_load=70
pump_up_step=2
pump_down_step=1
If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800. 
If current frequency =1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.

 

7) Smartass:
Result of Erasmux rewriting the complete code of interactive governor. 
Erasmux가 다시 쓴 interative 거버너의 최종 코드의 결과물이다.

Main goal is to optimize battery life without comprising performance. 
주 목표는 성능은 제외한 배터리 수명의 최적화다.

Still, not as battery friendly as smartassV2 since screen-on minimum frequency is 
greater than frequencies used during screen-off. 
아직도 스크린이 켜져있을 때의 최저 주파수가 스크린이 꺼진 동안 사용된 주파수 보다 크기 때문에 
smartassV2만큼 배터리 친화적이지 않다.

Smartass would jump up to highest frequency too often as well.
Smartass는 또한 최대 주파수로 너무 자주 튈 수 있다.

 

8) SmartassV2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people.
Erasmux의 smartass 거버너의 버전 2이다. 많은 사람들이 애용하는 또 다른 거버너이다.

The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after.
이 거버너는 이상적인 주파수가 목표이고, 이 주파수에 더 적극적이었다가 후에는 덜 적극적으로 바뀐다.

It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq.
이것은 화면이 켜져있을 때와 꺼졌을 때 namely awake_ideal_freq와 sleep_ideal_freq로 다른 이상적인 주파수를 사용하게 된다.

This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to ake_ideal_freq (500 mhz for GS2 by default) when screen is on.
이 거버너는 화면이 꺼져있을 때 CPU 클럭을 매우 빠르게(sleep_ideal_freq를 사용 후 바로) 낮추고 켜져있을 때는  
순식간에 awake_ideal_freq (GS2의 기본값인 500 mhz)로 높힌다. 

There's no upper limit for frequency while screen is off (unlike Smartass).
Smartass와는 달리 화면이 꺼져있는 동안에는 더 높은 주파수 제한은 없다.

So the entire frequency range is available for the governor to use during screen-on and screen-off state.
그래서 화면이 켜져있거나 꺼져있는 상태에서 사용되어지는 거버너를 위한 전체적인 주파수 범위가 있다.

The motto of this governor is a balance between performance and battery.
이 거버너의 모토는 성능과 배터리 사이의 밸런스이다.

 

9) Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand.
Faux의 Intelligent Ondemand라고도 알려진 Intellidemand는 ondemand를 기반의 기존까지는 좀 다른 거버너이다.

Unlike what some users believe, this governor is not the replacement for OC Daemon
(Having different governors for sleep and awake).
어떤 사용자들이 믿고있는 것과는 다르게 이 거버너는 OC Daemon의 대체가 아니다.
(sleep과 awake가 다르다.)

The original intellidemand behaves differently according to GPU usage.
itellidemand의 원본은 GPU사용량에 따라 다르게 작동한다.

When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand.
GPU사용이 많을 때는(게임, 맵, 벤치마킹, 등) intellidemand는 ondemand처럼 작동한다.

When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on 
frequencies available in your device/kernel for saving battery. This is called browsing mode.
GPU사용량이 적어지고(또는 적당히 사용되어지면) intellidemand는 배터리를 절약하기 위해 기기와 커널의 이용가능한
주파수에 따라 최대 주파수를 제한한다. 이것을 browsing 모드라 부른다.

We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on
idling time of CPU.
우리는 interactive 거버너의 traces를 확인할 수 있다. Frequency 스케일업 디시전은 CPU의 아이들 타임에 기초해서 한다.

Lower idling time (<20%) causes CPU to scale-up from current frequency.
Lower idling time (<20%) 은 현재 주파수로부터 CPU의 클럭을 높히게 한다.

Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in
conservative, among the popular governors )
최대 주파수의 steps=5%일 때 클럭을 낮춤이 발생한다. (이 매개변수는 인기 거버너들 중 conservative에서만 조정가능하다.)

To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency
when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy;
to deliver performance for gaming and such.
정리하면, 이것은 GPU가 아이들일때 최대 주파수를 제한하기 위한 browsing mode로 들어가는 intelligent ondemand이고,
게임 같은 것을위해 성능을 끌어올리기 위해 GPU 사용이 많을 때 ondemand처럼 작동한다. (browsing mode를 종료).

Intellidemand does not jump to highest frequency when screen is off.
intellidemand는 화면이 꺼졌을 때 최고 주파수로 뛰어넘지 않는다.

 

10) Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state
to specify the minimum time CPU stays on a frequency before scaling up/down.
Ezekeel의 거버너는 기본적으로 클럭을 높히고 낮추기 전에 CPU가 어떤 주파수에 머무를 최소 시간을 구체화하기 위해
추가된 매개변수인 min_time_state를 포함한 ondemand이다.

The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. 
그 개념은 여기서 ondemand에 의한 빠른 주파수 변환으로 야기될 모든 불안정 요소들을 제거하기 위함이다.

Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state
on a step overriding sampling interval.
Lazy 거버너는 ondemand보다 더 자주 poll을 하지만 오버라이딩 샘플링 간격 단계에서 min_time_state을 완료 후에만 
주파수를 변경한다. 

Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to
always select the maximum frequency while the screen is off.
Lazy는 또한  screenoff_maxfreq  매개변수가 활성화되었을 때 거버너가 화면이 꺼져있는동안 항상 최대 주파수를
선택하게 한다.

11) Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly.
Lagfree는 ondemand와 비슷하다. 가장 다른점은 더 배터리 친화적으로 최적화 되어있다는 것이다.

Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often.
너무 자주 100%까지 뛰어오르는 ondemand는 달리 주파수가 적절하게 감소/증가된다.

Lagfree does not skip any frequency step while scaling up or down.
Lagfree는 클럭을 높히고 낮추는 동안 어떤 주파수 단계도 건너뛰지 않는다.

Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that
since it has to raise cpu through each higher frequency step from current.
만약 파워가 순간적으로 필요하다면, lagfree는 현재로부터 각 단계씩 높은 주파수로 cpu를 높히기 때문에
그걸 충족을 시킬 수 없다는 것을 기억해라.

Some users report that video playback using lagfree stutters a little.
어떤 사용자들은 lagfree에서 동영상 재생시 버벅임이 있다고 제보했다.

12) Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source.
Lionheart는 삼성 update3 소스를 기초로한 conservative기반 거버너이다.

Tweaks comes from 1) Knzo 2) Morfic. The original idea comes from Netarchy.
트윅은 1) Knzo 2)Morfic에서 나왔다. Netarchy에게서 원래 아이디어가 나왔다.

See here. The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
여기를 참고하라. 그 조정가능한 값들(threshold나 샘플링 레이트와 같은)이 바뀌어져서 스케일링은 아주 활발졌고, 배터리를 희생해
거버너가 더 성능을 낼 수 있게 했다. 

To 'experience' Lionheart using conservative, try these tweaks:
Lionheart가 conservative를 사용하는 것을 '경험'해보기 위해 이 트윅을 사용해봐라.
sampling_rate:10000 or 20000 or 50000, whichever you feel is safer. (transition latency of the CPU is
something below 10ms/10,000uS hence using 10,000 might not be safe).
up_threshold:60
down_threshold:30
freq_step:5
Lionheart goes well with deadline i/o scheduler. When it comes to smoothness (not considering battery drain),
a tuned conservative delivers more as compared to a tuned ondemand.
Lionheart는 deadline i/o scheduler와 잘 맞는다. smoothness(배터리 소모는 고려치 않음)에 있어서 tuned conservative는 
tuned ondemand보다 더 낫다.

13) LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile
based on Smartass governor.
LionhearX는 Lionheart를 기반이지만 tunables들과 Smartass 거버너를 기반으로한 suspend profile의  
특징들에 몇 가지 바뀐점이 있다.

14) Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery.
smartass V2와 비슷하다. 더 적극적으로 높혀서 더 성능적이고 적은 배터리 소모를 한다.

15) SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery
as compared to brazilianwax.

또 다른 smartassV2 기반 거버너이다. brazilianwax와 비교시 성능과 배터리사이에 좋은 밸런스를 이룬다.

16) Userspace:
Instead of automatically determining frequencies, lets user set frequencies. 
자동으로 주파수를 결정하는 대신 사용자가 설정할 수 있게 한다.

17) Powersave:
Locks max frequency to min frequency. Can not be used as a screen-on or even screen-off
(if scaling min frequency is too low).
최대 주파수부터 최소 주파수를 막는다. 화면을 켰을 때 또는 심지어 껐을 때도 (만약 scaling min frequency가 너무 낮다면)
사용할 수 없다.

18) Performance:
Sets min frequency as max frequency. Use this while benchmarking!
최소 주파수를 최대 주파수로 설정한다. 벤치마킹할 때 사용해라!

So, Governors can be categorized into 3/4 on a high level:
그래서, 거버너들은 하이레벨에서 3/4로 분류된다.

1.a) Ondemand Based: Ondemand 기반
  Works on "ramp-up on high load" principle. CPU busy-time is taken into consideration for scaling decisions. 
   "높은 부하가 걸릴 때 상승" 이란 원칙에서 작동한다. CPU 비지타임은 스케일링 결정을 위해 고려되어진다.
  Members: Ondemand, OndemandX, Intellidemand, Lazy, Lagfree.

  b) Conservative Based: Conservative 기반
  Members: Conservative, Lionheart, LionheartX

2. Interactive Based: Interactive 기반
Works on "make scaling decision when CPU comes out of idle-loop" principle. 
"CPU가 아이들 루프에서 빠져나올때 스케일링 디시젼을 한다"는 원칙에서 작동한다.
Members: Interactive, InteractiveX, Lulzactive, Smartass, SmartassV2, Brazilianwax, SavagedZen.

3. Weird Category: 다른 범주
Members: Userspace, Powersave, Performance

2012/05/08 - [Mobile, Android, Apps] - 1편, 거버너(Governor)는 무엇인가?

2012/05/15 - [Mobile, Android, Apps] - 3편, 그러면 성능과 배터리 효율에 Governor(거버너)는 어떤게 좋을까?