인터럽트 (Interrupt)

인터럽트 처리 과정

인터럽트가 도착하면 대략 다음 순서로 처리된다.

1. CPU는 현재 명령의 실행을 마친 뒤 인터럽트 발생을 확인한다.
2. 현재 실행 문맥의 복귀에 필요한 최소 정보(프로그램 카운터, 상태 레지스터 등)를 저장한다.
3. 인터럽트 번호로 인터럽트 벡터 테이블(interrupt vector table)을 조회해 해당 처리 루틴의 주소를 얻는다.
4. 인터럽트 서비스 루틴(ISR, Interrupt Service Routine)이 커널 모드에서 실행되어 장치를 처리한다.
5. 저장해 둔 문맥을 복원하고 중단됐던 지점 또는 스케줄러가 고른 다른 작업으로 복귀한다.

여러 장치가 동시에 인터럽트를 걸 수 있으므로 인터럽트 컨트롤러가 우선순위를 정해 전달하고, 더 급한 인터럽트가 처리 중인 인터럽트를 다시 중단시키는 중첩(nesting)도 허용된다. 짧은 임계 처리 구간에서는 인터럽트를 잠시 비활성화(masking)하기도 한다. 멀티코어 시스템에서는 어느 코어가 어떤 인터럽트를 받을지 분배하는 문제가 추가되며, 특정 장치의 인터럽트를 특정 코어에 고정하는 인터럽트 친화도(IRQ affinity) 설정으로 캐시 효율과 부하 균형을 조절한다.

인터럽트는 직접 메모리 접근(DMA, Direct Memory Access)과 짝을 이뤄 입출력 효율을 완성한다. DMA 컨트롤러는 CPU 개입 없이 장치와 메모리 사이에서 데이터를 직접 옮기고, 전송이 모두 끝났을 때 한 번만 인터럽트를 걸어 완료를 알린다. DMA가 없다면 CPU가 바이트마다 데이터를 나르거나 장치가 바이트마다 인터럽트를 걸어야 하므로, 대용량 전송에서 DMA와 완료 인터럽트의 조합은 CPU 부담을 극적으로 줄인다. 디스크와 네트워크 입출력이 모두 이 구조로 동작한다.

지연 처리: 상반부와 하반부

ISR이 오래 실행되면 그동안 다른 인터럽트 처리와 스케줄링이 지연되므로, 커널은 처리를 둘로 나눈다. 상반부(top half)는 인터럽트 문맥에서 장치 확인과 응답 같은 최소한의 급한 일만 하고, 나머지 무거운 작업은 하반부(bottom half)로 미뤄 나중에 일반적인 커널 문맥에서 처리한다. 리눅스의 softirq, tasklet, 워크큐(workqueue)가 하반부를 구현하는 장치들이다. 이 구조 덕분에 시스템은 인터럽트 폭주 속에서도 응답성을 유지한다. 상반부가 실행되는 인터럽트 문맥에서는 잠들 수 없다는 제약도 중요하다. 잠들려면 대신 실행할 프로세스 문맥이 필요한데 인터럽트는 특정 프로세스에 속하지 않기 때문이다. 그래서 메모리 할당 대기나 뮤텍스 획득처럼 잠들 수 있는 작업은 반드시 하반부로 미뤄야 하며, 이 규칙 위반은 커널 버그의 흔한 원인이다.

타이머 인터럽트와 멀티태스킹

선점형 스케줄링은 타이머 인터럽트 위에서 동작한다. 하드웨어 타이머가 주기적으로 인터럽트를 걸면 커널이 실행 중인 프로세스의 사용 시간을 확인하고, 할당량을 다 썼다면 문맥 교환을 일으켜 다른 프로세스에 CPU를 넘긴다. 인터럽트가 없다면 프로세스가 자발적으로 양보하기 전까지 CPU를 회수할 방법이 없으므로, 타이머 인터럽트는 사실상 선점형 멀티태스킹을 가능하게 하는 토대라고 할 수 있다.

면접에서 이렇게 물어본다

• 폴링과 인터럽트를 비교하고 각각 어떤 상황에서 유리한지 설명해 보라.
• 하드웨어 인터럽트와 예외, 트랩의 차이를 동기와 비동기 관점에서 설명해 보라.
• 인터럽트 발생부터 ISR 실행, 복귀까지의 과정을 순서대로 말해 보라.
• 인터럽트 처리를 상반부와 하반부로 나누는 이유는 무엇인가.
• 타이머 인터럽트가 없다면 선점형 스케줄링이 왜 불가능한지 설명해 보라.