운영체제 - 인터럽트

 

이전 포스트 운영체제 구조에서 대략적인 구조를 봤습니다.

이번 포스트는 인터럽트에 대해 조금 더 보겠습니다.

 

 

인터럽트

• 하드웨어는 인터럽트를 CPU에게 계속 보내고 트리거를 시킨다.
• 이때 보내는 통로는 System bus이다.
  • System bus = 주요 컴포넌트들과 소통하는 메인 통로이다.
• 인터럽트는 많은 목적으로 사용하며 운영체제와 하드웨어와의 상호작용 중요 부분이다.
• CPU는 인터럽트를 받으면 하던 일을 즉시 멈추고 실행을 fixed location에 전송한다.
  • fixed location : interrupt service routine이 위치한 시작 주소
• Interrupt service rountine이 실행되고 끝이나면, CPU는 중단된 계산을 다시 시작한다.
• 물론 인터럽트들은 컴퓨터 아키텍쳐에 중요한 부분이고 각 컴퓨터 디자인은 자신의 인터럽트 머신이 있습니다.
• 각각의 함수들은 비슷하다. 
• 인터럽트는 적절한 interrupt service routine에 제어를 보낸다
• 이 전송을 관리하는 간단한 방법은 일반적인 루틴을 호출하여 인터럽트 정보를 검사하는 것이다.
• 매번 interrupt-specific handler를 부르는데, interrupt는 자주 빈벅하게 발생하는 만큼 빠른 시간에 처리되어야 한다.
• 따라서 필요한 속도를 제공하기 위해 포인터 테이블을 대신 제공한다.
• 인터럽트 루틴이 불리면 테이블을 통해 즉시 접근 가능하다.
•  포인터 테이블은 interrupt vector로 불리우고 낮은 메모리 주소에 저장이 된다.
• 한편으로 인터럽트 아키텍쳐는 인터럽트가 요청되기 전의 상태 정보를 저장해야한다.

 

인터럽트 실행

CPU hardware는 interrupt-request line이라는 선이 있고,  CPU는 매 명렁어를 실행 후 감지합니다.

이 interrupt-request line은 interrupt number를 읽어오고 해당 interrupt servie routine으로 점프하게 된다.

• 인터럽트 handler는 변경될 모든 상태를 저장하고, 인터럽트의 원인을 확인하고, 필요한 처리를 수행하고, 상태 복원하기 위해 return_from_interrupt 명령에서 반환을 실행하여 CPU를 인터럽트 이전의 실행 상태로 되돌립니다.

 

Interrupt-request line

대부분의 CPU들은 2개의 Interrupt request line이 있습니다.

• nonmaskable interrupt : 복구할 수 없는 메모리 오류와 같은 이벤트를 위해 예약되어 있다.
• maskable : 중요 명령어를 처리할때 중단되지 않도록 CPU에 의해 인터럽트를 중단할 수 있다.
  • device controller가 서비스를 요청하는데 사용된다.
• interrrupt vector의 목적 : 단일 인터럽트 핸들러를 interrupt 벡터 내부에서 찾아보아 필요로하는 인터럽트 서비스가 있는지 확인하는데에 있다.
• 컴퓨터는 interrupt vector의 주소 요소보다 더 많은 장치를 가지고 있다. 따라서 더 많은 interrupt handler들이 있다.
• 이 문제를 해결하기 위한 것이 interrupt chaining이다.
• 인터럽트가 발생하면 서비스를 제공할 수 있는 핸들러가 발견될 때까지 해당 목록의 핸들러를 하나씩 호출
  • 인터럽트 테이블의 overhead와 단일 interrupt handler에 대한 디스패치의 비효율성 사이의 절충안이다.

 

Interrupt priority levels

• CPU가 모든 인터럽트를 마스킹하지 않고 우선 순위 인터럽트의 처리를 연기할 수 있게 하여 높은 우선 순위 인터럽트가 낮은 순위 인터럽트보다 먼저 실행을 하게 한다.

 

Trap vs Hardware Interrupt vs System Call

 

Trap

소프트웨어에서 발생하는 인터럽트의 한 종류

• 예외 상황 처리에 사용한다.
  • 잘못된 메모리 주소 참조
  • 허용되지 않은 명령어 실행
  • 0으로 나누기 연산 수행 등의 오류

 

위와 같은 예외가 발생하면 운영체제는 해당 프로세스를 중단하고 예외 상황 처리를 위해 Trap 발생

 

 

사용

• 시스템 콜이나 디버깅 도구에서 사용
• 시스템 콜 : Trap을 사용하여 운영체제는 커널 모드로 전환, 해당 서비스를 처리
• 디버깅 도구 : 코드의 실행 중에 중단점을 설정하거나, 실행 상태를 확인하는 등의 기능 수행

 

Hardware Interrupt

하드웨어 장치에서 발생하는 이벤트

• 하드웨어에서 인터럽트를 보내 Interrupt request line에서 받아서 사용한다.
• 마우스 클릭, 키보드 입력 등

 

 

System call

일반 커널이 아닌 "운영체제 커널"이 제공하는 기능을 사용하기 위해 응용 프로그램이 커널에게 요청하는 인터페이스

• 응용 프로그램은 시스템 콜을 통해 커널 모드로 변경하여 운영체제가 제공하는 기능을 호출
• Ex. 파일 시스템 접근, 네트워크 사용, 프로세스 생성 및 제어

 

응용 프로그램이 시스템 콜을 사용하여 운영 체제에게 커널에서 제공하는 기능을 요청하고, 이러한 요청 기능을 운영체제가 제공한다.

커널 모드에서 시스템 콜을 처리하기 위해 운영 체제가 제공하는 라이브러리, 커널 함수, 드라이버 등에서 수행을 하며 만약 하드웨어에 요청이 필요한 경우 하드웨어 인터럽트를 사용하기 때문에, "하드웨어 인터럽트는 시스템 콜을 처리하기 위한 일련의 과정이므로 항상 발생하는 것은 아니다"

 

Ex 입력

응용 프로그램이 입력을 받으려면 "하드웨어 인터럽트"를 통해서도 가능하며 "System Call"을 통해서도 가능하다.

• System call만 사용하는 경우 polling 또는 waiting for input과 같은 방법을 사용하여 감지하고 응용 프로그램에게 입력을 제공하기 위해 시스템 콜을 호출

 

시스템 콜 vs 하드웨어 인터럽트

• 오버헤드
  • 하드웨어 인터럽트: 매번 인터럽트 핸들러를 호출, 인터럽트 처리에 따른 오버헤드가 발생하여 응용 프로그램의 처리 성능에 영향을 준다.
  • 시스템 콜: 인터럽트를 처리하지 않으므로 오버헤드가 상대적으로 적다.
• 비동기적 처리
  • 하드웨어 인터럽트: 입력 이벤트가 발생할 때마다 해당 이벤트를 처리하는 인터럽트 핸들러가 실행된다.
    
    • 비동기적인 처리로 응용 프로그램은 입력 이벤트가 발생할 때마다 핸들러에서 제공되는 콜백 함수 등을 사용하여 처리
  • 시스템 콜: 입력 이벤트가 발생할 때마다 응용 프로그램이 운영 체제에게 입력을 요청, 입력을 받을 때까지 응용 프로그램을 대기
    • 이는 동기적인 처리로 응용 프로그램은 입력을 받을 때까지 대기해야 한다.
• 처리 효율
  • 하드웨어 인터럽트: 빠른 입력처리를 위해 사용
    • Ex) 게임에서의 키 입력, or 빈번한 입력 이벤트
  • 시스템 콜 : 빈번한 이벤트에서는 적합하지 않는다.
    • Ex) python의 Input()

 

 

 

 

결론

• 인터럽트는 비동기 이벤트 처리하기 위해 현대 운영 체제 전반에 걸쳐 사용된다.
• 인터럽트는 중요한 일을 처리하기 위해 발생하는데, 중요한 일에도 순서가 있다. 따라서 최근 컴퓨터는 인터럽트 우선 순위 시스템을 사용한다.
• 또한 인터럽트는 시간에 민감한 처리를 위해 매우 많이 사용되기 때문에 좋은 시스템 성능을 위해 효율적인 인터럽트 처리가 필요하다