Power vs Performance 트레이드오프 — DVFS·Race-to-Idle·Big.LITTLE
#한 줄 요약
— voltage, frequency, capacitive load가 모두 전력에 영향을 줍니다.
#CMOS Dynamic Power 공식
여기서 는 switching activity (0~1), 는 capacitance, 는 voltage, 는 frequency입니다.
V를 10% 줄이면 power가 19% 절약됩니다. f를 절반으로 줄이고 V를 약간 더 낮추면 power를 4배까지도 절약할 수 있습니다.
#DVFS Curve
Frequency (MHz): 100 400 800 1200 1600 1800Voltage (V): 0.8 0.9 1.0 1.05 1.10 1.15Power (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 작업.
| 옵션 | 시나리오 | 에너지 |
|---|---|---|
| A | 200 MHz 동안 100 ms 실행 | 100 ms × 1 W = 100 mJ |
| B | 1 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
echo performance > /sys/.../scaling_governorreal-time이나 low-latency network처럼 latency가 critical한 경우에 적합합니다. 그 대신 battery는 빠르게 소모됩니다.
#powersave — 항상 최소 freq
echo powersave > ...throughput은 신경 쓰지 않고 수명을 최우선으로 하는 IoT 센서 같은 경우에 어울립니다.
#ondemand — Load 기반 (deprecated)
CPU usage가 95%를 넘으면 ramp up 합니다. 응답은 약간 느립니다.
#schedutil — 가장 흔함 (modern)
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
# 코어 끔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 — runningC1 — halt (대기)C2 — deep sleep (clock off)C3 — deeper (cache flush)...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 secesp_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
sudo powertop화면에는 다음과 같은 정보가 표시됩니다.
- Per-process power
- C-state residency (C2 이상 residency가 80% 이상이면 좋습니다)
- Wakeup/sec (낮을수록 좋습니다)
- Tunable 추천
#Wakeup Source 최소화
Linux:
sudo cat /proc/interrupts# IRQ 횟수 — 많은 행이 *background wake* 소스# Wake-on-LAN 끔ethtool -s eth0 wol dSystem wake가 적을수록 깊은 sleep을 더 길게 유지할 수 있습니다.
#자동차·항공 — Power Budget
| 시스템 | Power 범위 |
|---|---|
| Avionics 일반 ECU | 5–15 W |
| 중앙 컴퓨터 (high-perf) | 30–80 W |
| LV 비행 컴퓨터 | 5–20 W (열 방출 어려움) |
DVFS·hotplug는 제한적 — 결정성 우선. 보통 고정 frequency + core 사용량 통제.
위성과 우주선은 방열이 어렵기 때문에 fixed slow CPU를 그대로 쓰는 경우가 많습니다.
#자주 하는 실수
⚠️ 항상 max frequency
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는 에 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
- 1Embedded Performance Engineering — 임베디드 성능 엔지니어링 시리즈 소개
- 2임베디드 성능 분석 방법론 — Measure → Analyze → Optimize 사이클
- 3성능 지표 정의 — Latency·Throughput·Utilization 분석
- 4성능 측정의 기본 — Wall-Clock·CPU Cycle·Instruction Count
- 5성능 데이터 통계적 분석 — Percentile·Histogram·평균의 함정
- 6실시간 성능 분석 — WCET·Jitter·Deadline Miss 측정
- 7임베디드 벤치마킹 기초 — 재현성·Warmup·노이즈 제거
- 8성능 모델링 — Amdahl·Gustafson·Roofline Model 적용
- 9프로파일링 기법 개요 — Sampling vs Instrumentation·PGO·LTO
- 10CPU 파이프라인 분석 — 5-stage·Cortex-M·Cortex-A 비교
- 11Pipeline Stall 분석 — Data·Structural·Control Hazard·Forwarding
- 12Branch Prediction 분석 — Static·2-bit·BTB·BHT·Mispredict 비용
- 13Speculative Execution 분석 — OoO·Reorder Buffer·Register Renaming
- 14CPU Cache 기초 — L1·L2·L3·Set Associative·Replacement Policy
- 15Cache Miss 3C Model 분석 — Compulsory·Capacity·Conflict
- 16Cache Line 최적화 — Alignment·Prefetch·False Sharing 처리
- 17메모리 대역폭 분석 — STREAM·Roofline·Bus Saturation 측정
- 18SIMD·NEON 활용 — 128-bit Vector·Auto-Vectorization·SVE/SVE2
- 19PMU·HPM 하드웨어 카운터 분석 — 정밀 성능 진단
- 20임베디드 Bus Architecture — AHB·AXI·CHI 진화와 5-Channel
- 21Bus Contention 진단 — Arbitration·QoS·Starvation 측정
- 22DMA 성능 최적화 — Burst·Scatter-Gather·Chain·Cache 일관성
- 23DMA vs CPU Copy 성능 비교 — Break-even·Setup Overhead 실측
- 24Interrupt Latency 분석 — 진입·종료·Tail-Chaining·Late Arrival
- 25Interrupt Storm 처리 — NAPI·Rate-Limit·Polling 전환
- 26MMIO 접근 성능 — Cache Policy·Write-Combining·Volatile·Barrier
- 27Peripheral Clock 분석 — PLL·Divider·Gating·DVFS
- 28Power vs Performance 트레이드오프 — DVFS·Race-to-Idle·Big.LITTLE
- 29Thermal Throttling 분석 — Junction Temp·Trip Point·냉각
- 30CXL Interconnect 분석 — AI 시대 메모리 대역폭 확장
- 31Concurrency 기초 — Concurrency vs Parallelism·Race·Memory Model
- 32False Sharing 진단 — Cache Line Ping-Pong·Padding·측정
- 33Lock Contention 분석 — Wait·Hold·Convoy·측정 기법
- 34Spinlock 성능 분석 — Spin-Wait vs Context Switch·Ticket·MCS
- 35Mutex 성능 분석 — Futex·Adaptive·Priority Inheritance
- 36Reader-Writer Lock 성능 — Reader/Writer Priority·RCU·Seqlock
- 37Lock-Free 자료구조 성능 — CAS·ABA·Hazard Pointer·Epoch Reclamation
- 38Memory Ordering 분석 — Acquire·Release·Seq-Cst·ARM Relaxed Model
- 39Cache Coherency 프로토콜 — MESI·MOESI·Snoop·Directory
- 40SMP 성능 분석 — Per-Core·Affinity·Load Balance·Scalability
- 41Linux perf 기초 — stat·record·report 활용
- 42Linux perf 고급 — Raw Event·Tracepoint·perf script
- 43ftrace 활용 — function·function_graph·latency tracer
- 44eBPF·bpftrace 동적 트레이싱 — 커널 무수정 관측
- 45Flamegraph 분석 — On-CPU·Off-CPU·Differential
- 46ARM DS·Lauterbach 분석 — Hardware Trace 전문 도구
- 47Bare-metal 프로파일링 — GPIO·DWT·SysTick·ITM 활용
- 48NVIDIA Nsight Systems — GPU·NPU 포함 시스템 분석
- 49모던 프로파일러 비교 — Tracy·Hotspot·uftrace·Coz
- 50연속 프로파일링 — Parca·Pixie·Pyroscope·Tetragon
- 51실전 사례 — ISR Latency 100µs Deadline Miss 추적
- 52실전 사례 — Matrix Multiply가 예상의 10배 느린 이유
- 53실전 사례 — 8-core가 4-core를 넘으면 throughput이 떨어지는 이유
- 54실전 사례 — 카메라 1080p 60fps가 30fps로 떨어지는 이유
- 55CXL.mem 지연·대역폭 실측 — Direct·Switch·Pooled 토폴로지 비교
- 56CXL 성능 프로파일링 도구 — cxl-cli·DAMON·perf-mem 활용
- 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.
실전 사례 — CXL.mem 추가로 LLM inference KV cache 처리량 회복
70B 모델 KV cache가 HBM 한계를 넘어 throughput이 무너졌을 때, CXL.mem 256 GB pool 추가로 회복한 실전 케이스.
CXL 성능 프로파일링 도구 — cxl-cli·DAMON·perf-mem 활용
CXL.mem 환경 성능 도구 — cxl-cli 토폴로지·DAMON page activity·perf-mem로 보는 CXL 트래픽·numastat 통계.