본문으로 건너뛰기
Embedded Performance Engineering · 27/57

Power vs Performance 트레이드오프 — DVFS·Race-to-Idle·Big.LITTLE

· Hawk · 6분 읽기
power dvfs cpufreq big-little race-to-idle

#한 줄 요약

P=V2⋅f⋅CP = V^2 \cdot f \cdot C — voltage, frequency, capacitive load가 모두 전력에 영향을 줍니다.

#CMOS Dynamic Power 공식

Pdynamic=α⋅C⋅V2⋅fP_{\text{dynamic}} = \alpha \cdot C \cdot V^2 \cdot f

여기서 α\alpha는 switching activity (0~1), CC는 capacitance, VV는 voltage, ff는 frequency입니다.

Pstatic=leakage(V⋅온도에 비례)P_{\text{static}} = \text{leakage} \quad (V \cdot \text{온도에 비례})

V를 10% 줄이면 power가 19% 절약됩니다. f를 절반으로 줄이고 V를 약간 더 낮추면 power를 4배까지도 절약할 수 있습니다.

#DVFS Curve

Frequency (MHz):  100   400   800  1200  1600  1800
Voltage (V):      0.8   0.9   1.0  1.05  1.10  1.15
Power (W):        0.3   1.3   3.5   5.5   8.5  11.0


이상적 비례: 100 → 1800 = 18x f
실 power:   0.3 → 11.0 = 37x P  (V²·f 함께 ↑)

고주파로 갈수록 효율이 떨어집니다. Sweet spot은 보통 중간 영역에 있고, f·P 비율이 가장 좋아집니다.

#Race-to-Idle

Workload — 100 ms 작업.

옵션시나리오에너지
A200 MHz 동안 100 ms 실행100 ms × 1 W = 100 mJ
B1 GHz 동안 20 ms 실행 + 80 ms idle (0.1 W)20 × 5 + 80 × 0.1 = 108 mJ

거의 같음 — 그러나 부하 짧을수록 race-to-idle 유리 (idle power가 dynamic보다 압도적 작을 때).

ARM big.LITTLE 구조에서는 high 코어로 100 ms 처리하고 idle로 들어가는 쪽이, low 코어를 1 s 동안 계속 돌리는 쪽보다 효율적입니다.

#Linux Governor

#performance — 항상 최대 freq

Terminal window
echo performance > /sys/.../scaling_governor

real-time이나 low-latency network처럼 latency가 critical한 경우에 적합합니다. 그 대신 battery는 빠르게 소모됩니다.

#powersave — 항상 최소 freq

Terminal window
echo powersave > ...

throughput은 신경 쓰지 않고 수명을 최우선으로 하는 IoT 센서 같은 경우에 어울립니다.

#ondemand — Load 기반 (deprecated)

CPU usage가 95%를 넘으면 ramp up 합니다. 응답은 약간 느립니다.

#schedutil — 가장 흔함 (modern)

Terminal window
echo schedutil > ...

Scheduler가 task별 util을 추정해 즉시 frequency를 조정하기 때문에, ondemand보다 예측이 빠릅니다.

#conservative

ondemand보다 더 천천히 ramp up 하면서 배터리 절약을 우선시합니다.

#Embedded — Heterogeneous CPU

#big.LITTLE (ARM)

Snapdragon 845:

  • Big: 4 × Cortex-A75 @ 2.8 GHz (peak)
  • Little: 4 × Cortex-A55 @ 1.8 GHz (efficient)

전환 모드:

  • CPU Migration — 한 core만 active
  • CPU Cluster Switching — big or little cluster 통째
  • Global Task Scheduling (GTS) — task가 적절한 core에 dispatch

#DynamIQ (ARM v8.2+)

big·little을 한 cluster에 묶고 공유 L3 cache를 둔다. 이로 인해 migration overhead 감소, task를 더 미세하게 core 할당 가능.

Cortex-A76 + A55가 DynamIQ cluster의 대표 구성이며, 모바일 표준으로 자리잡았습니다.

#CPU Hotplug

Terminal window
# 코어 끔
echo 0 > /sys/devices/system/cpu/cpu3/online


# 켬
echo 1 > /sys/devices/system/cpu/cpu3/online

전체 코어를 power off하므로 더 큰 절약 효과가 있고, 그만큼 wakeup latency도 늘어납니다.

자동차에서는 정차 시 코어 절반을 hotplug off 하는 식으로 쓰입니다.

#Idle State (C-state)

Linux CPUIdle:

C0 — running
C1 — halt (대기)
C2 — deep sleep (clock off)
C3 — deeper (cache flush)
...
Terminal window
cat /sys/devices/system/cpu/cpu0/cpuidle/state*/name
# WFI, MWAIT(C1), MWAIT(C2), ...

깊은 state로 갈수록 전력은 더 절약되지만 wakeup latency가 길어집니다. RTOS는 보통 깊은 state를 회피합니다.

#ESP32 Light Sleep — 임베디드 사례

esp_sleep_enable_timer_wakeup(1000000);   // 1 sec
esp_sleep_enable_ext0_wakeup(GPIO_PIN, 1);
esp_light_sleep_start();   // 30 µA, 1 ms wakeup

배터리 IoT 기기는 99% sleep과 1% active 패턴으로 동작합니다.

#Thermal Throttling

CPU가 85°C를 초과하면 frequency가 자동으로 내려가거나 코어가 꺼진다. 짧은 burst 후 throttle이 걸려 평균 성능이 떨어진다.

해결:

  • 방열판
  • 부하 분산 (다른 core, 다른 코어)
  • 짧은 burst + 충분한 idle (race-to-idle 효과)

스마트폰 게이밍이나 노트북에서 흔히 나타나는 문제입니다.

#측정 — powertop

Terminal window
sudo powertop

화면에는 다음과 같은 정보가 표시됩니다.

  • Per-process power
  • C-state residency (C2 이상 residency가 80% 이상이면 좋습니다)
  • Wakeup/sec (낮을수록 좋습니다)
  • Tunable 추천

#Wakeup Source 최소화

Linux:

Terminal window
sudo cat /proc/interrupts
# IRQ 횟수 — 많은 행이 *background wake* 소스
Terminal window
# Wake-on-LAN 끔
ethtool -s eth0 wol d

System wake가 적을수록 깊은 sleep을 더 길게 유지할 수 있습니다.

#자동차·항공 — Power Budget

시스템Power 범위
Avionics 일반 ECU5–15 W
중앙 컴퓨터 (high-perf)30–80 W
LV 비행 컴퓨터5–20 W (열 방출 어려움)

DVFS·hotplug는 제한적 — 결정성 우선. 보통 고정 frequency + core 사용량 통제.

위성과 우주선은 방열이 어렵기 때문에 fixed slow CPU를 그대로 쓰는 경우가 많습니다.

#자주 하는 실수

⚠️ 항상 max frequency

Terminal window
governor=performance
# → 배터리 노트북 2시간, 그렇지 않으면 6시간

⚠️ ondemand·schedutil 차이 무시

ondemand는 반응이 느리고, modern Linux의 기본은 schedutil입니다.

⚠️ Wakeup source 무시

매 1 ms wakeup이 들어오면 깊은 C-state로 못 들어가고 항상 C1에 머문다. Background task의 wake 빈도를 점검해야 합니다.

⚠️ Thermal 무시한 benchmark

loop_benchmark();   // ← 10초 후부터 thermal throttle

충분히 cool-down한 다음 측정해야 합니다.

#정리

  • Power는 V2⋅fV^2 \cdot f에 leakage가 더해진 값입니다.
  • Race-to-Idle은 burst high freq로 빠르게 처리하고 깊은 sleep으로 들어가는 전략입니다.
  • Linux에서는 schedutil governor와 CPUIdle C-state를 함께 씁니다.
  • ARM big.LITTLE / DynamIQ는 heterogeneous 구조로 전력 효율을 끌어올립니다.
  • CPU hotplug + light sleep은 IoT와 자동차에서 절전의 핵심입니다.
  • 측정에는 powertop, turbostat, /sys/.../cpufreq를 사용합니다.

다음 편은 Thermal을 다룹니다.

#관련 항목

Embedded Performance Engineering · 28 of 57

  1. 1 Embedded Performance Engineering — 임베디드 성능 엔지니어링 시리즈 소개
  2. 2 임베디드 성능 분석 방법론 — Measure → Analyze → Optimize 사이클
  3. 3 성능 지표 정의 — Latency·Throughput·Utilization 분석
  4. 4 성능 측정의 기본 — Wall-Clock·CPU Cycle·Instruction Count
  5. 5 성능 데이터 통계적 분석 — Percentile·Histogram·평균의 함정
  6. 6 실시간 성능 분석 — WCET·Jitter·Deadline Miss 측정
  7. 7 임베디드 벤치마킹 기초 — 재현성·Warmup·노이즈 제거
  8. 8 성능 모델링 — Amdahl·Gustafson·Roofline Model 적용
  9. 9 프로파일링 기법 개요 — Sampling vs Instrumentation·PGO·LTO
  10. 10 CPU 파이프라인 분석 — 5-stage·Cortex-M·Cortex-A 비교
  11. 11 Pipeline Stall 분석 — Data·Structural·Control Hazard·Forwarding
  12. 12 Branch Prediction 분석 — Static·2-bit·BTB·BHT·Mispredict 비용
  13. 13 Speculative Execution 분석 — OoO·Reorder Buffer·Register Renaming
  14. 14 CPU Cache 기초 — L1·L2·L3·Set Associative·Replacement Policy
  15. 15 Cache Miss 3C Model 분석 — Compulsory·Capacity·Conflict
  16. 16 Cache Line 최적화 — Alignment·Prefetch·False Sharing 처리
  17. 17 메모리 대역폭 분석 — STREAM·Roofline·Bus Saturation 측정
  18. 18 SIMD·NEON 활용 — 128-bit Vector·Auto-Vectorization·SVE/SVE2
  19. 19 PMU·HPM 하드웨어 카운터 분석 — 정밀 성능 진단
  20. 20 임베디드 Bus Architecture — AHB·AXI·CHI 진화와 5-Channel
  21. 21 Bus Contention 진단 — Arbitration·QoS·Starvation 측정
  22. 22 DMA 성능 최적화 — Burst·Scatter-Gather·Chain·Cache 일관성
  23. 23 DMA vs CPU Copy 성능 비교 — Break-even·Setup Overhead 실측
  24. 24 Interrupt Latency 분석 — 진입·종료·Tail-Chaining·Late Arrival
  25. 25 Interrupt Storm 처리 — NAPI·Rate-Limit·Polling 전환
  26. 26 MMIO 접근 성능 — Cache Policy·Write-Combining·Volatile·Barrier
  27. 27 Peripheral Clock 분석 — PLL·Divider·Gating·DVFS
  28. 28 Power vs Performance 트레이드오프 — DVFS·Race-to-Idle·Big.LITTLE
  29. 29 Thermal Throttling 분석 — Junction Temp·Trip Point·냉각
  30. 30 CXL Interconnect 분석 — AI 시대 메모리 대역폭 확장
  31. 31 Concurrency 기초 — Concurrency vs Parallelism·Race·Memory Model
  32. 32 False Sharing 진단 — Cache Line Ping-Pong·Padding·측정
  33. 33 Lock Contention 분석 — Wait·Hold·Convoy·측정 기법
  34. 34 Spinlock 성능 분석 — Spin-Wait vs Context Switch·Ticket·MCS
  35. 35 Mutex 성능 분석 — Futex·Adaptive·Priority Inheritance
  36. 36 Reader-Writer Lock 성능 — Reader/Writer Priority·RCU·Seqlock
  37. 37 Lock-Free 자료구조 성능 — CAS·ABA·Hazard Pointer·Epoch Reclamation
  38. 38 Memory Ordering 분석 — Acquire·Release·Seq-Cst·ARM Relaxed Model
  39. 39 Cache Coherency 프로토콜 — MESI·MOESI·Snoop·Directory
  40. 40 SMP 성능 분석 — Per-Core·Affinity·Load Balance·Scalability
  41. 41 Linux perf 기초 — stat·record·report 활용
  42. 42 Linux perf 고급 — Raw Event·Tracepoint·perf script
  43. 43 ftrace 활용 — function·function_graph·latency tracer
  44. 44 eBPF·bpftrace 동적 트레이싱 — 커널 무수정 관측
  45. 45 Flamegraph 분석 — On-CPU·Off-CPU·Differential
  46. 46 ARM DS·Lauterbach 분석 — Hardware Trace 전문 도구
  47. 47 Bare-metal 프로파일링 — GPIO·DWT·SysTick·ITM 활용
  48. 48 NVIDIA Nsight Systems — GPU·NPU 포함 시스템 분석
  49. 49 모던 프로파일러 비교 — Tracy·Hotspot·uftrace·Coz
  50. 50 연속 프로파일링 — Parca·Pixie·Pyroscope·Tetragon
  51. 51 실전 사례 — ISR Latency 100µs Deadline Miss 추적
  52. 52 실전 사례 — Matrix Multiply가 예상의 10배 느린 이유
  53. 53 실전 사례 — 8-core가 4-core를 넘으면 throughput이 떨어지는 이유
  54. 54 실전 사례 — 카메라 1080p 60fps가 30fps로 떨어지는 이유
  55. 55 CXL.mem 지연·대역폭 실측 — Direct·Switch·Pooled 토폴로지 비교
  56. 56 CXL 성능 프로파일링 도구 — cxl-cli·DAMON·perf-mem 활용
  57. 57 실전 사례 — CXL.mem 추가로 LLM inference KV cache 처리량 회복

관련 글

Peripheral Clock 분석 — PLL·Divider·Gating·DVFS

PLL/divider/gating으로 peripheral clock. STM32 RCC, Linux CCF. Power vs Performance.

· clock

같은 시리즈에서 이어 읽기

실전 사례 — CXL.mem 추가로 LLM inference KV cache 처리량 회복

70B 모델 KV cache가 HBM 한계를 넘어 throughput이 무너졌을 때, CXL.mem 256 GB pool 추가로 회복한 실전 케이스.

· cxl

같은 시리즈에서 이어 읽기

CXL 성능 프로파일링 도구 — cxl-cli·DAMON·perf-mem 활용

CXL.mem 환경 성능 도구 — cxl-cli 토폴로지·DAMON page activity·perf-mem로 보는 CXL 트래픽·numastat 통계.

· cxl

같은 시리즈에서 이어 읽기

이 글을 참조하는 글 (3)