한 CPU에 IRQ가 몰려 네트워크 지연이 튑니다. IRQ affinity를 바꾸면 어떤 실행 경로가 이동하고 무엇은 그대로 남나요?

IRQ affinity가 직접 바꾸는 것은 특정 hardware interrupt가 전달되고 실행될 수 있는 CPU 집합입니다. 예를 들어 CPU 0만 허용하던 NIC vector의 mask에 CPU 2와 3을 추가하면 그 IRQ의 상단 handler가 실행될 eligible CPU가 넓어집니다. affinity 문서가 보장하는 것은 이 집합과 최소 한 CPU가 남아야 한다는 제약이지, 후속 softirq·workqueue·RSS queue·NUMA 페이지가 자동으로 같은 CPU로 이동한다는 사실이 아닙니다.

설명용으로 변경 전 /proc/interrupts에서 한 vector가 1초 동안 CPU0에서 800,000회, CPU2와 CPU3에서 각각 1,000회 증가했다고 하겠습니다. 변경 후 CPU0 420,000, CPU2 190,000, CPU3 191,000이라면 1차로 IRQ count가 분산됐다고 말할 수 있습니다. 그러나 이것은 전체 경로의 성공이 아닙니다. softirq backlog, workqueue callback의 실제 CPU, packet buffer의 NUMA node, cross-node load, queue lock 대기, p99를 이어서 봐야 합니다. 이 숫자는 실행 결과가 아니라 확인할 산술 예시입니다.

mask를 넓히면 균등 분배가 자동으로 되지 않고, 장치 vector와 RSS queue 매핑이 한 CPU에 남을 수 있습니다. worker가 unbound면 scheduler가 다른 CPU에서 실행할 수 있고, scheduler affinity가 따로 고정되어 있으면 IRQ만 이동합니다. IRQ count가 줄었는데 p99가 악화되면 원격 메모리나 queue lock contention을 의심합니다. 따라서 변경 전후에 IRQ count, hard IRQ 시간, softirq 실행 CPU, worker latency, NUMA 위치를 함께 기록하고, affinity를 “전체 처리 경로 이동 버튼”이 아니라 상단 interrupt의 eligible set을 조정하는 제어점으로 설명하겠습니다.