7. affinity, CPU power와 interrupt latency 상한을 검증한다

CHAPTER 07

7. affinity, CPU power와 interrupt latency 상한을 검증한다

route 변경, CPU hotplug, idle state, redistributor sleep과 wake, priority masking 구간을 latency histogram과 함께 수집합니다. 평균이 아니라 가장 긴 지연의 원인을 실행 context까지 찾습니다.

affinity migration

old target quiesce, route write와 new target 활성화 사이에 loss/duplicate가 없어야 합니다.

idle wake

CPU 저전력 상태에서 redistributor와 CPU interface가 interrupt wake를 보존해야 합니다.

mask latency

local_irq_disable, priority mask, hard IRQ nesting과 handler critical section이 latency 상한에 기여합니다.

storm control

장치 mask와 GIC disable, source clear 순서를 구분해 다른 CPU로 storm이 이동하지 않게 합니다.

레지스터·번호·소유권 대조

항목	소유자	값의 의미	정상 증거	오류 해석
IROUTER	GICD	현재 target affinity	online CPU와 일치	offline target
GICR_WAKER	GICR	CPU redistributor sleep	idle/hotplug 상태와 일치	wake handshake
ICC_PMR/RPR	CPU interface	mask와 running priority	지연 시점 해석 가능	priority inversion
DAIF	CPU	IRQ mask 상태	critical section과 trace 일치	긴 local IRQ disable
irq affinity/count	Linux	target CPU와 delivery count	migration 후 새 CPU만 증가	stale route

오류가 발생한 단계 확인

증상	직전 통과	우선 확인	반증 시험	판정
affinity 이동 중 1개 손실	평상시 정상	route update/active state	고정 rate sequence로 반복	migration race
deep idle에서만 지연	idle off 정상	WAKER/CPU wake latency	idle state별 histogram	power 경계
특정 CPU만 긴 tail	route 정상	DAIF/PMR/softirq load	CPU별 irqsoff trace	local masking
storm이 CPU를 바꾸며 지속	route 변경 동작	device level source clear	device mask 후 GIC 상태 비교	장치 원인
hotplug 후 IRQ 사라짐	CPU online 성공	route migration/GICR restore	offline 전후 ledger	hotplug lifecycle

그림 1. 「7. affinity, CPU power와 interrupt latency 상한을 검증한다」의 실행 순서왼쪽부터 신호나 데이터를 처리하는 순서를 나타냅니다. 각 단계에서 확인할 항목을 함께 표시했습니다.

01 source event

02 route target

03 CPU power/wake

04 priority+mask

05 exception entry

06 handler

07 EOI

08 latency record

실제 검증 절차

순서	실행	남길 증거	판정 목적
1	hardware timestamp가 가능한 source로 고정 주기 interrupt를 만듭니다.	발생/entry timestamp	지연 측정
2	affinity, idle state, load를 직교 행렬로 반복합니다.	조건별 max/p99	민감 축 확인
3	최장 지연 구간의 DAIF/PMR/WAKER와 irqsoff trace를 맞춥니다.	원인 구간	상한 설명
4	CPU hotplug 중 sequence count를 검증합니다.	loss/duplicate 0	migration 완료

주의측정용 printk는 interrupt latency를 크게 바꿉니다. trace buffer와 hardware timestamp를 사용하고 출력은 시험 후에 합니다.

UART 손실의 원인이 다른 드라이버에 있을 수 있습니다

DAVE Embedded Systems의 Axel Lite 사례에서는 SD 카드 감지를 폴링하던 드라이버가 인터럽트를 끈 상태로 1 ms 지연을 실행해 UART RX FIFO overrun을 일으켰습니다. UART에서 손실이 보인다고 UART 드라이버가 원인이라고 단정할 수 없습니다. 1 ms는 그 보드·드라이버의 사례이며 Linux 전체의 지연 상한이 아닙니다. irqsoff 추적기는 관측 중 가장 긴 IRQ 비활성 구간과 그 경로를 저장합니다. 장치의 overrun 기록, 해당 CPU의 IRQ-off 구간, 드라이버 경로를 같은 시간축에서 대조해야 합니다.

English note

In DAVE Embedded Systems’ Axel Lite case, an SD-controller driver delayed for 1 ms with interrupts disabled while polling card detection, causing a UART RX FIFO overrun. A UART symptom does not establish a UART-driver cause. That interval belongs to this board and driver, not a Linux-wide latency bound. The irqsoff tracer retains the longest observed interrupts-disabled interval and its trace. Align device overrun evidence, the affected CPU’s IRQ-off interval and the driver path in time.

DAVE Axel Lite 사례 Linux 6.18 irqsoff

공개적으로 다시 확인할 수 있는 자료

공개되지 않은 제조사 레지스터나 제품별 오프셋은 추측하지 않았습니다. 아래의 제조사 자료, 아키텍처 문서, Linux v6.18.37 원본으로 확인할 수 있는 내용만 다뤘습니다.

7. affinity, CPU power와 interrupt latency 상한을 검증한다