← Interrupt 상세 목차DUJINLABS.COM

Hardware · Interrupt detailed manual 07 · Linux v6.18.37

7. affinity, NMI, storm과 latency 상한을 분리해 측정한다

maskable IRQ의 IF/TPR/vector route와 NMI의 별도 entry를 구분하고, affinity migration, CPU idle/hotplug, interrupt storm에서 가장 긴 entry 지연을 추적합니다.

상세 표
2
검증 행
14
절차
4 checkpoints
기준
x86 APIC · IOAPIC · MSI · Linux v6.18.37

CHAPTER 07

7. affinity, NMI, storm과 latency 상한을 분리해 측정한다

maskable IRQ의 IF/TPR/vector route와 NMI의 별도 entry를 구분하고, affinity migration, CPU idle/hotplug, interrupt storm에서 가장 긴 entry 지연을 추적합니다.

IF

maskable interrupt는 RFLAGS.IF와 local_irq_disable 구간에 지연될 수 있습니다.

NMI

일반 APIC priority/maskable IRQ와 다른 entry 및 nesting 규칙을 가집니다.

affinity

IOAPIC RTE, MSI message 또는 IRTE와 vector allocation이 함께 바뀝니다.

storm

장치 source를 먼저 제어하지 않으면 route만 바꿔 다른 CPU를 소진합니다.

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

항목소유자값의 의미정상 증거오류 해석
RFLAGS.IFCPUmaskable IRQ 허용지연 구간 trace와 일치긴 irq-off
TPR/PPR/IRRLAPICpriority와 pendingentry 지연 원인 설명priority mask
RTE/MSI/IRTE targetrouting현재 affinity CPU/vectorLinux mask와 일치stale target
NMI reason/stateplatform/CPUNMI source의도된 watchdog/MCE 등원인 미식별
irq count/latencyLinux/traceCPU별 delivery와 시간migration 후 일관loss/tail

실패 경계 판정

증상직전 통과우선 확인반증 시험판정
affinity 이동 중 losssteady state 정상vector/route updatesequence count와 migration trace이동 race
특정 CPU만 tail 큼route 정상irqoff/SMI/NMI/idleirqsoff와 hardware timestamp 비교CPU local 지연
IRQ stormhandler count 증가device level/source cleardevice mask 후 LAPIC/IOAPIC 상태장치 원인
NMI watchdog false positiveCPU 응답 일부SMI/irqoff/lockup 구분NMI backtrace와 tracing clock비마스크 지연
hotplug 후 wrong CPUCPU online/offline 성공route/vector cleanupold/new vector countlifecycle
그림 1. 7. affinity, NMI, storm과 latency 상한을 분리해 측정한다의 실행 순서왼쪽에서 오른쪽으로 실제 소유권과 관찰 지점이 이동합니다.
01 source timestamp
02 route/vector
03 IRR
04 IF/priority/idle
05 IDT 또는 NMI entry
06 handler
07 EOI
08 latency histogram

실제 검증 절차

순서실행남길 증거판정 목적
1하드웨어 source timestamp와 entry trace를 맞춥니다.발생→entry delta실제 latency
2affinity/idle/load/hotplug 조건을 직교 반복합니다.조건별 max/p99민감 축
3최장 지연에 IF/TPR/SMI/NMI 흔적을 붙입니다.지연 원인상한 설명
4storm에서 장치 mask→source clear→route 복구 순서를 시험합니다.복구 후 count 안정운영 절차

주의NMI context에서 일반 lock, printk와 handler를 그대로 사용하면 deadlock이나 측정 왜곡이 생길 수 있습니다.

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

공개되지 않은 vendor register나 integration별 offset을 추측해서 채우지 않았습니다. 아래 제조사 자료, architecture 문서와 Linux v6.18.37 원본에서 다시 확인할 수 있는 범위만 사용했습니다.