인터럽트 후반부 처리 기법 선택 방법

인터럽트가 자주 발생할 때 인터럽트 후반부 처리 기법으로 Soft IRQ나 태스크릿을 적용하는 것이 좋다. IRQ 스레드 방식과 워크큐 방식은 그리 적합하지 않다. IRQ 스레드는 실시간(RT : Real Time) 프로세스로 구동된다. 인터럽트가 많이 발생하면 IRQ 스레드를 깨워야 하고 IRQ 스레드는 실시간 프로세스로 구동된다. 하지만 IRQ 스레드가 실행되는 동안 다른 일반 프로세스들이 선점 스케줄링을 할 수 없다. 따라서 IRQ 스레드 처리 함수의 실행 시간이 조금이라도 길어지면 다른 프로세스들이 실행을 못하고 대기한다. 그 결과, 시스템 반응 속도가 느려질 수 있다. 만약 인터럽트 발생 빈도가 높을 때 IRQ 스레드 방식을 적용해야 한다면 IRQ 스레드 처리 함수의 실행 시간도 되도록 짧은 편이 좋다. 예를 들면, IRQ 스레드 처리 함수에서는 printk() 함수와 같이 커널 로그를 출력하는 코드도 되도록 작성하지 말아야 한다. printk() 함수는 시스템 관점에서 비용이 많이 든다. IRQ 스레드 기법 대신 워크큐 기법을 적용해 인터럽트 후반부를 처리하면 어떨까? 인터럽트 발생빈도가 높을 때는 워크큐 기법은 적용하지 않는 것이 좋다. 워크큐 기법은 실행 시간 측면에서 다음과 같은 단점이 있기 때문이다.

- 워크를 워크큐에 큐잉하고 워크를 깨우는 시간이 오래 걸린다.

- 워크큐를 실행하는 워커 스레드는 일반 프로세스로 프로세스의 우선순위는 높지 않다.

인터럽트 발생 횟수만큼 워크 핸들러가 실행되지 못할 수 있다. 그래서 인터럽트가 발생 빈도가 낮고 빠른 시간에 인터럽트 후반부를 처리하지 않아도 될 경우 워크큐 기법을 적용하는 것도 좋다. 하지만 인터럽트가 자주 발생하는 디바이스는 Soft IRQ나 태스크릿 방식을 적용하는 것이 바람직하다.

여러 인터럽트 후반부 기법 중 하나를 결정하는 것은 정답이 없기 때문에 어려운 과제이다. 이런 상황에서 필요한 것이 최적화다. 인터럽트 후반부 단계에서 인터럽트 처리를 최적화하도록 설계를 하려면 먼저 커널이 인터럽트를 처리하는 세부 동작 방식과 인터럽트 후반부 기법들의 세부 구현 방식을 잘 알고 있어야 한다.

 

1. IRQ 스레드(threaded IRQ)

IRQ란?

IRQ 스레드는 IRQ와 스레드(thread)의 합성어이다. 먼저 IRQ는 Interrupt Request의 약자로 하드웨어에서 발생한 인터럽트를 처리한다는 의미이다. 조금 더 구체적으로 설명하자면 인터럽트가 발생한 후 인터럽트 핸들러까지 처리되는 흐름을 의미한다. 스레드는 커널 공간에서만 실행하는 '커널 스레드'와 같은 의미이다. 그렇다면 IRQ 스레드란? 인터럽트 핸들러에서는 바로 처리하지 않아도 되는 일을 수행하는 프로세스이다. 즉, 인터럽트 후반부 처리를 위한 인터럽트 처리 전용 프로세스이다. 이를 가리켜 리눅스 커널 커뮤니티에서는 irq_thread 혹은 threaded IRQ 방식이라고도 부른다. 용어는 달라도 같은 의미이다. 이처럼 IRQ 스레드 기법은 인터럽트 후반부 처리를 IRQ 스레드에서 수행하는 방식을 의미한다.

 

IRQ 스레드 확인

라즈베리 파이에서 IRQ 스레드 확인

라즈베리 파이에서는 IRQ 스레드 목록을 터미널을 열고 ps -ely 명령어를 입력하면 프로세스 목록을 확인할 수 있다. 가장 오른쪽 irq/86-mmc1이 있으면 이 프로세스가 IRQ 스레드이다. 커널 내부 함수에서 'irq/인터럽트 번호-인터럽트 이름' 과 같은 규칙에 따라 IRQ 스레드의 이름을 짓는다. irq/86-mmc1 프로세스는 'mmc1이라는 이름의 86번 인터럽트를 처리하는 IRQ 스레드'로 해석하면 된다. 라즈비안에서는 1개의 IRQ 스레드만 볼 수 있다.