Utilization clamping

1. 소개

util clamp 또는 uclamp라고도 부르는 utilization clamping은 사용자 공간이 task의 성능 요구사항을 관리하는 데 관여할 수 있게 하는 scheduler 기능이다. Linux v5.3에서 처음 도입되었고 cgroup 지원은 v5.4에 병합되었다.

uclamp는 scheduler가 task의 성능 요구와 제한을 이해하도록 돕는 hint 방식이다. scheduler는 이 정보를 바탕으로 더 나은 결정을 내릴 수 있고, schedutil cpufreq governor를 사용할 때는 CPU frequency 선택에도 util clamp가 영향을 준다.

scheduler와 schedutil은 모두 PELT의 util_avg signal에 의해 구동된다. util clamp는 이 signal을 특정 지점으로 제한하는 방식으로 목적을 달성한다. utilization을 제한함으로써 system이 일정한 성능 지점에서 동작하도록 만드는 것이 이름의 유래다.

사용자 공간 관점에서는 util clamp를 utilization 수치라기보다 성능 제약에 대한 요청 또는 hint로 보는 편이 알맞다. 두 tunable이 이 범위를 정한다.

• UCLAMP_MIN은 하한을 정한다.
• UCLAMP_MAX는 상한을 정한다.

두 경계는 task가 system의 지정된 성능 범위 안에서 동작하도록 한다. UCLAMP_MIN은 task boost를, UCLAMP_MAX는 task cap을 뜻한다.

어떤 task가 원하는 사용자 경험을 제공하려면 최소한 어느 성능 지점에서 동작해야 한다고 scheduler에 알릴 수 있다. 반대로 특정 task가 너무 많은 자원을 쓰지 못하게 하여 정해진 성능 지점을 넘지 않도록 요청할 수도 있다. 사용자 공간에는 uclamp 값을 utilization보다 performance point로 추상화하는 편이 이해하기 쉽다.

예를 들어 game은 화면에서 관찰한 FPS와 util clamp 사이에 feedback loop를 만들 수 있다. frame이 떨어질 때 display pipeline task가 요구하는 최소 성능 지점을 동적으로 높일 수 있고, 수백 ms 뒤 계산량이 큰 장면이 시작될 것을 안다면 미리 이 task들을 높은 성능으로 준비시킬 수도 있다.

device 성능 편차가 큰 mobile hardware에서는 이런 동적 feedback loop가 각 system 능력에 맞는 사용자 경험을 만드는 데 큰 유연성을 준다.

정적 설정도 가능하다. 정확한 사용법은 system, application, 원하는 결과에 따라 달라진다.

Android에서는 task를 background, foreground, top-app 등으로 분류한다. background task가 사용할 수 있는 성능 지점에 상한을 두면 현재 사용자가 조작하는 top-app group처럼 중요한 task를 위해 자원을 남길 수 있고, background task의 전력 소비도 제한할 수 있다.

Arm big.LITTLE 같은 heterogeneous system에서는 이 제약의 효과가 더 분명하다. background task가 little core에 머물도록 유도하면 다음 두 결과를 얻는다.

• big core를 비워 두어 사용자가 현재 상호작용하는 가장 중요한 top-app task를 즉시 실행할 수 있다.
• CPU를 많이 쓰는 background task라도 전력 소모가 큰 core에서 실행되어 battery를 낭비하는 일을 줄인다.

사용자 공간은 이런 uclamp 성능 요청 또는 hint를 통해 system resource가 가능한 한 효율적으로 사용되도록 만들고, 그 위에서 최선의 사용자 경험을 제공할 수 있다.

또 다른 용도는 scheduler utilization signal 계산 방식에 내재된 ramp-up latency를 극복하는 것이다.

최대 성능으로 실행되어야 하는 busy task라도 scheduler가 그 요구를 util_avg에서 파악하기까지 약 200 ms가 걸릴 수 있다. PELT half-life는 32 ms다. mobile game에서는 높은 frequency 선택이 늦어져 frame deadline을 놓칠 수 있다. UCLAMP_MIN=1024로 설정하면 이런 task는 실행을 시작할 때부터 가장 높은 성능 수준을 요청한다.

효과적으로 사용하면 눈에 보이는 사용자 경험과 성능 개선을 넘어 system 전체의 performance per watt도 높일 수 있다.

사용자 공간은 thermal subsystem과도 feedback loop를 구성하여 thermal throttling이 시작될 정도로 device가 뜨거워지지 않게 조절할 수 있다.

SCHED_NORMAL/SCHED_OTHER와 SCHED_FIFO/SCHED_RR는 모두 uclamp 요청과 hint를 적용한다.

SCHED_FIFO/SCHED_RR에서는 RT task를 항상 최대 frequency에 묶지 않고 원하는 성능 지점에서 실행할 수 있다. battery로 동작하는 범용 system에서 특히 유용하다.

설계상 RT task에는 task별 PELT signal이 없다. 예측하기 어려운 DVFS ramp-up delay에 대응하려면 RT task는 일정한 frequency에서 실행되어야 한다.

schedutil을 사용하면 RT task가 깨어날 때 frequency를 바꾸기 위한 delay가 한 번은 항상 생긴다. uclamp를 사용해도 이 비용은 달라지지 않는다. uclamp가 바꾸는 것은 schedutil이 모든 RT task에 무조건 MAX를 요청하는 대신 어떤 frequency를 요청할지 선택하는 부분이다. 기본값은 3.4절, RT 기본값 변경은 3.4.1절에서 다룬다.

2. 설계

util clamp는 system의 모든 task가 갖는 속성이다. task utilization signal의 경계를 정하고 scheduler 내부의 일부 결정에 bias를 주는 방식으로 동작한다.

실제 task utilization signal 자체를 변경하지는 않는다. 어느 시점에 PELT signal을 검사해도 원래 값은 그대로다. clamp는 task가 깨어나 scheduler가 실행할 CPU를 고르는 순간처럼, 그 값이 필요한 의사결정 지점에서만 적용된다.

task가 실행될 최소·최대 성능 지점을 요청하려면 frequency 선택과 task placement 양쪽에 영향을 줄 수 있어야 한다. 두 결정 모두 CPU runqueue, 줄여서 rq 수준의 utilization 값과 관계가 있으며 이것이 uclamp 설계의 핵심 과제다.

task가 rq에서 깨어나면 그 rq의 utilization signal은 enqueue된 모든 task의 uclamp 설정에 영향을 받는다. 예를 들어 한 task가 UTIL_MIN=512를 요청했다면 rq signal은 그 요청과 rq에 있는 다른 모든 task 요청을 함께 만족시켜야 한다.

rq에 붙은 모든 task의 util clamp 값을 집계하려면 enqueue와 dequeue마다 상태를 관리해야 한다. 이 위치는 scheduler hot path이므로 느려지면 많은 workload에 큰 영향을 주고 기능 자체의 실용성을 떨어뜨린다.

이를 해결하기 위해 전체 utilization 범위를 struct uclamp_bucket 여러 개로 나눈다. 그러면 rq의 모든 task를 검색하지 않고 가장 높은 non-empty bucket의 일부 task만 살펴보면 된다.

task enqueue 시 대응 bucket counter를 증가시키고 dequeue 시 감소시킨다. 이 방식으로 rq 수준의 effective uclamp 값을 더 적은 비용으로 추적한다.

task가 enqueue·dequeue될 때마다 rq의 현재 effective uclamp 값을 갱신한다. 자세한 동작은 2.1절에서 설명한다.

이후 rq의 effective uclamp가 필요한 경로는 의사결정을 내리는 정확한 시점에 이미 집계된 값을 읽기만 하면 된다.

현재 task placement에서는 Energy Aware Scheduling과 Capacity Aware Scheduling, 즉 EAS/CAS만 uclamp를 사용한다. 따라서 placement 영향은 heterogeneous system에 적용된다.

task가 깨어나면 scheduler는 각 rq의 현재 effective uclamp와 이 task를 그 rq에 enqueue했을 때의 예상 값을 비교하고, 가장 energy-efficient한 조합이 되는 rq를 선호한다.

schedutil도 frequency를 갱신할 때 현재 enqueue된 task 집합의 영향을 받은 rq effective uclamp를 읽고, 모든 요청 제약을 만족하는 frequency를 선택한다.

EAS를 사실상 비활성화하는 overutilization 상태를 정하는 경로도 uclamp를 사용한다. 이런 경로는 위 두 주요 사용례를 지원하는 내부 관리에 가깝고 구현 세부에 따라 달라질 수 있어 이 문서에서는 자세히 다루지 않는다.

2.1. Bucket

enqueue·dequeue 때 rq effective uclamp를 결정하는 검색 범위를 줄이기 위해 전체 utilization 범위를 N개 bucket으로 나눈다. N은 compile time의 CONFIG_UCLAMP_BUCKETS_COUNT로 정하며 기본값은 5다.

rq에는 uclamp_id tunable인 UCLAMP_MIN과 UCLAMP_MAX 각각에 대한 bucket 집합이 있다.

각 bucket 범위는 1024/N이다. 기본값 5에서는 반올림한 DELTA가 205이고 다음 범위를 사용한다.

DELTA = round_closest(1024/5) = 204.8 = 205

Bucket 0: [0:204]
Bucket 1: [205:409]
Bucket 2: [410:614]
Bucket 3: [615:819]
Bucket 4: [820:1024]

다음 tunable을 가진 task p가 rq에 enqueue된다고 하자.

p->uclamp[UCLAMP_MIN] = 300
p->uclamp[UCLAMP_MAX] = 1024

UCLAMP_MIN에서는 bucket 1 counter를, UCLAMP_MAX에서는 bucket 4 counter를 증가시킨다. 이 rq에 각 범위의 task가 존재한다는 사실이 bucket에 반영된다.

rq는 uclamp_id마다 현재 effective uclamp 값을 별도로 추적한다.

task p를 enqueue할 때 rq 값은 다음 논리로 바뀐다.

// bucket 갱신 논리가 이 위치에서 실행된다
rq->uclamp[UCLAMP_MIN] = max(rq->uclamp[UCLAMP_MIN],
                              p->uclamp[UCLAMP_MIN])
// UCLAMP_MAX에도 같은 과정을 적용한다

task p를 dequeue할 때는 다음과 같이 남은 non-empty bucket 중 가장 높은 값을 찾는다.

// bucket 갱신 논리가 이 위치에서 실행된다
rq->uclamp[UCLAMP_MIN] = search_top_bucket_for_highest_value()
// UCLAMP_MAX에도 같은 과정을 적용한다

모든 bucket이 비면 rq uclamp 값은 system 기본값으로 돌아간다. 기본값은 3.4절에서 설명한다.

2.2-2.4. Max 집계, 계층 집계, 값의 범위

util clamp는 가장 높은 성능 지점을 요구하는 task의 요청을 만족하도록 조정된다.

여러 task가 같은 rq에 있으면 다른 task가 높은 성능을 필요로 하지 않거나 그 지점에 도달하지 못하도록 제한되었더라도, 가장 높은 성능을 요구하는 task가 필요한 성능을 얻을 수 있어야 한다.

예를 들어 같은 rq에 다음 두 task가 있다고 하자.

p0->uclamp[UCLAMP_MIN] = 300
p0->uclamp[UCLAMP_MAX] = 900

p1->uclamp[UCLAMP_MIN] = 500
p1->uclamp[UCLAMP_MAX] = 500

p0와 p1이 모두 같은 rq에 enqueue되면 UCLAMP_MIN과 UCLAMP_MAX 모두 각 요청의 max로 집계된다.

rq->uclamp[UCLAMP_MIN] = max(300, 500) = 500
rq->uclamp[UCLAMP_MAX] = max(900, 500) = 900

5.1절에서 보듯 이 max aggregation은 특히 사용자 공간이 UCLAMP_MAX로 전력을 아끼려 할 때 나타나는 한계의 원인이다.

util clamp는 모든 task의 속성이지만 실제 적용되는 effective 값은 task 자신이나 middleware가 대신 요청한 값만으로 정해지지 않는다.

• task가 속한 cgroup CPU controller의 uclamp 설정이 먼저 task 요청을 제한한다.
• 그 결과는 다시 system-wide uclamp 설정의 제한을 받는다.

구체적인 interface는 3절에서 설명한다. task 요청은 cgroup과 system-wide 설정이 만든 경계를 지켜야 실제 effective 값이 된다.

요청이 현재 제약을 벗어나더라도 system은 값을 설정하는 작업 자체는 받아들인다. 이후 task가 다른 cgroup으로 이동하거나 system administrator가 전역 설정을 바꾸면 새 제약 안에 들어오는 범위에서 그 요청이 만족될 수 있다.

즉 task가 uclamp 값을 바꿀 때 계층 집계 때문에 error가 반환되는 방식이 아니라, 현재 cgroup과 system 설정에 따라 system이 그 요청을 그대로 충족하지 못할 수 있는 방식이다.

uclamp 성능 요청 범위는 0부터 1024까지이며 양 끝을 포함한다. cgroup interface에서는 0부터 100까지의 percentage를 사용하고, 다른 cgroup interface와 마찬가지로 100 대신 max를 쓸 수 있다.

3.1-3.2. Task와 cgroup interface

sched_setattr() system call에는 두 field가 추가되었다.

• sched_util_min은 task가 실행될 때 system이 제공해야 할 최소 performance point, 즉 성능 하한을 요청한다.
• sched_util_max는 task가 실행될 때 system이 넘지 않아야 할 최대 performance point, 즉 성능 상한을 요청한다.

다음은 utilization을 40%에서 80% 사이로 제한하는 예다.

attr->sched_util_min = 40% * 1024;
attr->sched_util_max = 80% * 1024;

task p가 실행될 때 scheduler는 가능한 한 40% 성능 수준에서 시작하도록 해야 한다. task가 충분히 오래 실행되어 실제 utilization이 80%를 넘으면 scheduler 의사결정에 쓰는 utilization 또는 성능 수준을 상한에 맞춘다.

특수값 -1은 uclamp 설정을 system 기본값으로 reset한다.

-1로 기본값을 상속하도록 reset하는 것과 현재 system 기본값 숫자를 직접 설정하는 것은 다르다. RT task의 기본값은 system interface로 바뀔 수 있기 때문에 이 차이가 중요하다. 향후 SCHED_NORMAL/SCHED_OTHER에도 비슷한 knob가 생길 수 있다.

CPU cgroup controller에는 cpu.uclamp.min과 cpu.uclamp.max 두 값이 있다.

cpu.uclamp.min은 cgroup v2 문서 3-3절의 protection이다. task의 uclamp_min이 cpu.uclamp.min보다 낮으면 task는 cgroup의 cpu.uclamp.min을 상속한다. cgroup hierarchy에서 effective cpu.uclamp.min은 child와 parent 중 큰 값이다.

cpu.uclamp.max는 cgroup v2 문서 3-2절의 limit다. task의 uclamp_max가 cpu.uclamp.max보다 높으면 task는 cgroup의 cpu.uclamp.max를 상속한다. hierarchy에서 effective cpu.uclamp.max는 child와 parent 중 작은 값이다.

다음 task와 cgroup 설정을 예로 든다.

p0->uclamp[UCLAMP_MIN] = // system default;
p0->uclamp[UCLAMP_MAX] = // system default;

p1->uclamp[UCLAMP_MIN] = 40% * 1024;
p1->uclamp[UCLAMP_MAX] = 50% * 1024;

cgroup0->cpu.uclamp.min = 20% * 1024;
cgroup0->cpu.uclamp.max = 60% * 1024;

cgroup1->cpu.uclamp.min = 60% * 1024;
cgroup1->cpu.uclamp.max = 100% * 1024;

p0와 p1을 cgroup0에 붙이면 값은 다음과 같다.

p0->uclamp[UCLAMP_MIN] = cgroup0->cpu.uclamp.min = 20% * 1024;
p0->uclamp[UCLAMP_MAX] = cgroup0->cpu.uclamp.max = 60% * 1024;

p1->uclamp[UCLAMP_MIN] = 40% * 1024; // 그대로 유지
p1->uclamp[UCLAMP_MAX] = 50% * 1024; // 그대로 유지

p0와 p1을 cgroup1에 붙이면 값은 다음처럼 바뀐다.

p0->uclamp[UCLAMP_MIN] = cgroup1->cpu.uclamp.min = 60% * 1024;
p0->uclamp[UCLAMP_MAX] = cgroup1->cpu.uclamp.max = 100% * 1024;

p1->uclamp[UCLAMP_MIN] = cgroup1->cpu.uclamp.min = 60% * 1024;
p1->uclamp[UCLAMP_MAX] = 50% * 1024; // 그대로 유지

cgroup interface는 cpu.uclamp.max를 cpu.uclamp.min보다 낮게 설정하는 것을 허용한다. 다른 uclamp interface에서는 이 관계를 허용하지 않는다.

3.3-3.4. System interface와 기본값

3.3.1 sched_util_clamp_min

sched_util_clamp_min은 허용할 UCLAMP_MIN 범위의 system-wide limit다. 기본값 1024에서는 task가 사용할 수 있는 effective UCLAMP_MIN 범위가 [0:1024]다. 이를 512로 바꾸면 [0:512]가 되어 task가 얻을 수 있는 boost의 최대치를 제한한다.

task가 이 knob보다 큰 값을 요청해도 설정 작업은 성공하지만, knob 값이 p->uclamp[UCLAMP_MIN]보다 커질 때까지 요청은 그대로 만족되지 않는다.

sched_util_clamp_min은 sched_util_clamp_max보다 작거나 같아야 한다.

3.3.2 sched_util_clamp_max

sched_util_clamp_max는 허용할 UCLAMP_MAX 범위의 system-wide limit다. 기본값 1024에서는 task의 effective UCLAMP_MAX 범위가 [0:1024]다.

이를 512로 바꾸면 허용 범위는 [0:512]가 된다. 어떤 task도 512보다 높은 성능에서 실행할 수 없고 모든 rq에도 같은 제한이 적용되므로, system 전체 성능이 절반으로 cap된다.

이 knob는 system 전체의 최대 성능 지점을 제한할 때 유용하다. battery가 부족하거나 idle·screen-off 상태에서 전력 소모가 큰 성능 수준에 접근하지 못하게 하는 용도로 쓸 수 있다.

task가 knob보다 높은 값을 요청해도 설정은 성공하지만, 전역 knob가 p->uclamp[UCLAMP_MAX]보다 커질 때까지 요청은 충족되지 않는다.

sched_util_clamp_max는 sched_util_clamp_min보다 크거나 같아야 한다.

3.4 기본값

기본적으로 모든 SCHED_NORMAL/SCHED_OTHER task는 다음 값으로 초기화된다.

p_fair->uclamp[UCLAMP_MIN] = 0
p_fair->uclamp[UCLAMP_MAX] = 1024

SCHED_FIFO/SCHED_RR task의 기본값은 다음과 같다.

p_rt->uclamp[UCLAMP_MIN] = 1024
p_rt->uclamp[UCLAMP_MAX] = 1024

RT task는 기본적으로 system의 최대 성능 지점으로 boost된다. 이는 기존 RT task 동작을 유지하기 위한 값이다.

RT task의 기본 uclamp_min은 boot 또는 runtime에 sysctl로 바꿀 수 있다.

3.4.1 sched_util_clamp_min_rt_default

battery device에서 RT task를 항상 최대 성능으로 실행하는 것은 비싸고 반드시 필요하지도 않다. 이 sysctl은 system 요구사항을 만족할 만큼의 성능 보장은 유지하면서 항상 MAX에서 실행해 전력을 낭비하지 않도록 기본 boost 값을 조정한다.

application 개발자는 task별 util clamp interface로 성능과 전력을 직접 고려하는 것이 권장된다. 이상적으로 system designer는 이 knob를 0으로 두고 application이 자신의 성능 요구사항을 관리하게 해야 한다.

4. Util clamp 사용법

util clamp는 사용자 공간이 보조하는 전력·성능 관리 개념을 제공한다. scheduler만으로는 최선의 결정을 내리는 데 필요한 application 의미를 알 수 없지만, 사용자 공간은 util clamp를 통해 task placement와 frequency 선택에 필요한 hint를 줄 수 있다.

application이 실행되는 system을 미리 가정하지 않고 feedback loop로 실행 결과를 관찰하며 값을 동적으로 조정할 때 가장 좋은 결과를 얻는다. 최종 목표는 더 좋은 사용자 경험과 더 나은 performance per watt다.

일부 system과 사용례에서는 정적 설정도 좋은 결과를 내지만 이식성이 문제가 된다. 100, 200, 1024라는 값으로 수행할 수 있는 일의 양은 system마다 다르므로 특정 target system이 없다면 정적 설정을 피하는 편이 좋다.

util clamp를 중심으로 완전한 관리 framework를 만들 수도 있고 application이 직접 interface를 사용할 수도 있다.

4.1 중요한 task와 DVFS latency에 민감한 task boost

GUI task는 wakeup 순간의 util_avg만 보면 frequency를 높일 만큼 busy하지 않을 수 있다. 하지만 사용자 경험을 위해 정해진 시간 안에 작업을 끝내야 하며, wakeup 때 필요한 frequency는 system 성능에 따라 달라진다. 느린 system에서는 높을 수 있고 충분히 빠른 system에서는 낮거나 0일 수도 있다.

task가 deadline을 놓칠 때마다 UCLAMP_MIN을 높이면 다음 wakeup에서는 더 높은 성능에서 시작한다. 각 system에서 deadline을 만족하는 가장 낮은 UCLAMP_MIN에 수렴하도록 조정해야 최적의 performance per watt를 얻는다.

heterogeneous system에서는 이 task를 더 빠른 CPU에 배치하는 것도 중요할 수 있다.

4.2 Background task cap

소개에서 설명한 Android 사례처럼 application은 성능이 중요하지 않지만 busy해져 불필요한 system resource를 쓸 수 있는 background task의 UCLAMP_MAX를 낮출 수 있다.

4.3 Powersave mode

system-wide sched_util_clamp_max로 모든 task가 일반적으로 energy efficiency가 낮은 고성능 지점에서 동작하지 못하게 제한할 수 있다.

같은 결과는 cpufreq governor의 maximum frequency를 낮춰도 얻을 수 있으므로 uclamp만의 고유 기능은 아니다. 더 편리한 대체 interface로 볼 수 있다.

4.4 Application별 성능 제한

middleware나 utility는 application을 실행할 때마다 UCLAMP_MIN/MAX를 설정하는 사용자 option을 제공할 수 있다. 최소 성능을 보장하거나, 성능 저하를 감수하는 대신 application이 system power를 지나치게 소비하지 못하도록 제한한다.

예를 들어 이동 중 laptop에서 kernel을 compile할 때 성능을 희생해 발열과 전력 소비를 낮추면서 browser 성능은 그대로 유지하도록 서로 다른 uclamp 제약을 적용할 수 있다.

5.1. Max aggregation 때문에 UCLAMP_MAX cap이 실패하는 경우

task p0의 실행 성능을 512로 cap했다고 하자.

p0->uclamp[UCLAMP_MAX] = 512

p0가 모든 performance point를 사용할 수 있는 p1과 rq를 공유한다.

p1->uclamp[UCLAMP_MAX] = 1024

max aggregation 때문에 rq에는 최대 performance point가 허용된다.

rq->uclamp[UCLAMP_MAX] = max(512, 1024) = 1024

p0와 p1의 UCLAMP_MIN이 모두 0이라면 rq frequency는 두 task의 실제 utilization에 따라 정해진다.

p1이 작은 task이고 p0가 CPU-intensive task라면 둘이 같은 rq에서 실행된다는 이유만으로 p1이 rq의 frequency cap을 풀어 버린다. p1은 모든 성능 지점을 사용할 권한은 있지만 실제로 높은 frequency가 필요하지 않을 수 있는데도 이 결과가 생긴다.

5.2. UCLAMP_MAX가 PELT util_avg를 왜곡하는 경우

PELT는 signal이 커지면 frequency도 올라 CPU에 일정한 idle 시간이 생긴다고 가정한다. UCLAMP_MAX가 frequency 상승을 막으면 어떤 상황에서는 idle 시간이 완전히 사라진다. task가 계속 busy loop에 머물면 util_avg는 1024까지 올라간다.

앞의 max aggregation 문제와 결합하면 심하게 cap된 task가 작은 non-capped task와 rq를 공유할 때 원하지 않는 frequency spike가 발생할 수 있다.

다음 값을 가진 task p0가 idle CPU에서 깨어난다고 하자.

p0->util_avg = 300
p0->uclamp[UCLAMP_MAX] = 0

rq->uclamp[UCLAMP_MAX] = 0

p0는 그 CPU가 지원하는 minimum frequency Fmin에서 실행된다. 이 작업을 가장 짧은 시간에 끝낼 때의 frequency가 Fmax이므로 Fmax/Fmin 비율이 결과에 중요하다.

Fmax/Fmin이 3이면 최대 환산 부하는 다음과 같다.

300 * (Fmax/Fmin) = 900

900은 1024보다 작으므로 CPU에는 여전히 idle 시간이 생긴다. 실제 util_avg가 정확히 900이 되는 것은 아니며 300과 900 사이에 있다. idle 시간이 남는 동안 p0->util_avg 갱신에는 작은 오차가 생기지만 Fmax/Fmin에 정확히 비례하지는 않는다.

p0->util_avg = 300 + small_error

Fmax/Fmin이 4이면 최대 환산 부하는 다음처럼 1024를 넘는다.

300 * (Fmax/Fmin) = 1200

p0->util_avg = 1024

CPU에 idle 시간이 사라지면 실제 util_avg가 1024에 도달한다. 이때 다음 값을 가진 p1이 같은 CPU에서 깨어난다고 하자.

p1->util_avg = 200
p1->uclamp[UCLAMP_MAX] = 1024

max aggregation에 따라 CPU의 effective UCLAMP_MAX는 1024가 된다. p0가 심하게 throttling된 채 계속 실행되었으므로 rq 상태는 다음과 같다.

p0->util_avg = 1024
p1->util_avg = 200

rq->util_avg = 1024
rq->uclamp[UCLAMP_MAX] = 1024

p0가 throttling되지 않았다면 p0 300과 p1 200을 합쳐 rq->util_avg=500 정도가 되어 CPU의 중간 성능 지점 부근에서 실행했을 것이다. 실제로는 누적된 1024와 풀린 UCLAMP_MAX 때문에 Fmax로 뛰어 frequency spike가 난다.

p0->util_avg = 300
p1->util_avg = 200

rq->util_avg = 500

5.3. Schedutil 응답 시간의 한계

schedutil에는 세 가지 한계가 있다.

• hardware가 frequency 변경 요청에 응답하는 데는 0이 아닌 시간이 들며, 일부 platform에서는 수 ms가 걸린다.
• fast-switch를 지원하지 않는 system은 worker deadline thread가 깨어나 frequency를 바꿔야 하므로 측정 가능한 overhead가 더해진다.
• schedutil의 rate_limit_us 구간 안에 들어온 새 요청은 버려진다.

작은 task가 시간 제약이 큰 작업을 수행하여 wakeup 직후 특정 performance point가 필요하더라도 이 한계 때문에 기대한 시간 안에 원하는 성능을 받지 못할 수 있다.

이 문제는 uclamp에서만 나타나는 것은 아니지만, uclamp를 사용하면 점진적인 frequency ramp-up·ramp-down 대신 task wakeup 순서와 각 uclamp 값에 따라 frequency 사이를 크게 뛰어다닐 수 있어 더 자주 드러날 수 있다.

문서는 이를 기반 system 능력의 한계로 본다.

schedutil rate_limit_us의 동작은 개선할 여지가 있지만 hardware 응답 시간과 non-fast-switch worker overhead는 해결하기 어렵다. 두 항목은 system의 hard limitation으로 간주한다.