인터럽트 스톰

Interrupt storm

운영 체제에서 인터럽트 스톰은 프로세서가 프로세서 시간의 대부분을 소비하는 과도한 수의 인터럽트를 수신하는 이벤트다.인터럽트 스톰은 일반적으로 인터럽트 속도 제한을 지원하지 않는 하드웨어 장치에 의해 발생한다.

배경

인터럽트 프로세싱은 일반적으로 시간 공유 운영 체제에서 예방할 수 없는 작업이기 때문에 인터럽트 스톰은 사용자 입력에 대한 느린 응답을 야기하거나 심지어 시스템을 완전히 정지시키는 것처럼 보일 것이다.이 상태는 흔히 라이브 록으로 알려져 있다.그런 상태에서는, 시스템은 다른 작업을 완료하는 대신 대부분의 자원을 처리 방해물을 처리하는 데 쓰고 있다.최종 사용자에게는 출력이 없는 경우가 많기 때문에 아무것도 처리하지 않는 것으로 보인다.인터럽트 스톰은 둘 다 유사한 증상(사용자 입력에 대한 응답이 없거나 느리거나 출력이 거의 또는 전혀 없음)을 가지고 있기 때문에 스레싱으로 오인되기도 한다.

일반적인 원인은 잘못 구성되거나 결함 있는 하드웨어, 장치 드라이버 결함, 운영 체제의 결함 또는 하나 이상의 구성 요소에서의 전이성 등이다.후자의 상태는 프로토타입이나 아마추어로 제작된 하드웨어 이외에는 거의 발생하지 않는다.

대부분의 현대적인 하드웨어와 운영체제는 인터럽트 스톰의 영향을 완화하는 방법을 가지고 있다.예를 들어, 대부분의 이더넷 컨트롤러는 인터럽트 "속도 제한"을 구현하여 컨트롤러가 생성하는 각 인터럽트 사이에 프로그래밍 가능한 시간을 기다리게 한다.장치 내에 없을 경우, 유사한 기능이 장치 드라이버 및/또는 운영 체제 자체에 기록된다.

가장 일반적인 원인은 기기가 다른 기기 "뒤에" APIC(Advanced Programmable Interrupt Controller)에 인터럽트를 신호할 때 이다.대부분의 컴퓨터 주변기기는 APIC를 통해 인터럽트 수가 장치 수보다 항상 더 적기 때문에(일반적으로 현대 PC의 경우 15개) 인터럽트를 발생시킨다.그런 다음 OS는 해당 인터럽트에 등록된 각 드라이버를 조회하여 인터럽트가 하드웨어에서 발생했는지 여부를 물어봐야 한다.결함이 있는 드라이버는 항상 "예"라고 주장하여 OS가 해당 인터럽트에 등록된 다른 드라이버를 쿼리하지 않도록 할 수 있다(한 번에 하나의 인터럽트만 처리할 수 있음).따라서 원래 인터럽트를 요청한 기기는 인터럽트를 서비스하지 않으므로 새로운 인터럽트가 생성되거나 삭제되지 않으며 프로세서가 연속적인 인터럽트 신호로 인해 늪에 빠진다.어떤 운영 체제는 그러한 고장으로 인한 인터럽트 스톰 하에서 잠길 수 있다.커널 디버거는 대개 결함이 있는 드라이버를 언로드하여 스톰을 깨뜨릴 수 있으며, 사용자 입력이 여전히 가능한 경우 운전자가 결함 있는 드라이버를 "밑으로" 제거하도록 한다.

드라이버는 제3자에 의해 구현되는 경우가 가장 많기 때문에 대부분의 운영 체제에도 일정한 간격으로 또는 라운드 로빈 방식으로 보류 중인 인터럽트를 쿼리하는 폴링 모드가 있다.이 모드는 OS가 결함 상태나 과도한 인터럽트 생성을 감지할 경우 드라이버별, 인터럽트별로 전역적으로 설정할 수 있다.폴링 모드는 인터럽트의 수나 인터럽트에 의해 야기된 리소스 사용이 특정 임계값을 통과할 때 동적으로 활성화될 수 있다.이러한 임계값을 더 이상 초과하지 않을 경우 OS는 인터럽트 모드에서 폴링 모드로 인터럽트 드라이버, 인터럽트 또는 인터럽트 처리를 전체적으로 변경할 수 있다.하드웨어의 인터럽트 속도 제한은 일반적으로 폴링 모드 사용을 부정하지만 프로세서가 속도를 유지할 만큼 빠르게 컨텍스트를 전환할 수 없는 경우 집중적인 I/O 동안 정상 작동 중에 발생할 수 있다.

역사

아마도 1969년 아폴로 11호의 달 하강 중에 첫 인터럽트 폭풍이 일어났을 것이다.[1]

고려 사항.

인터럽트 속도 제한은 최적의 결과를 위해 신중하게 구성되어야 한다.예를 들어 인터럽트 속도가 제한되는 이더넷 컨트롤러는 각 인터럽트 사이에 있는 네트워크로부터 수신하는 패킷을 버퍼링한다.속도가 너무 낮게 설정되면 컨트롤러의 버퍼 오버플로가 발생하고 패킷이 손실된다.이 속도는 인터럽트 간 버퍼 충전이 가능한 속도와 인터럽트와 시스템에 대한 버퍼 전송 사이의 인터럽트 지연 시간을 고려해야 한다.

인터럽트 완화

이 문제에 대한 하드웨어 기반 접근법과 소프트웨어 기반 접근법이 있다.예를 들어, FreeBSD는 인터럽트 스톰을 감지하고, 문제가 있는 인터럽트를 일정 시간 동안 차단하여 대응한다.[citation needed]

NAPI가 사용하는 시스템은 하드웨어 기반 접근방식의 예로서 시스템(운전자)은 인터럽트 활성화 상태에서 시작하고, 인터럽트 핸들러는 인터럽트를 비활성화하여 스레드/태스크가 이벤트를 처리하게 한 다음, 태스크가 장치를 폴링하여 일부 이벤트를 처리하고 인터럽트를 활성화한다.

하드웨어 지원을 사용하는 또 다른 흥미로운 접근방식은 이벤트 대기열 상태가 "비어 있음"에서 "비어 있지 않음"으로 변경될 때 장치가 인터럽트를 생성하는 방식이다.그런 다음 RX FIFO 꼬리에 무료 DMA 설명자가 없으면 장치는 이벤트를 삭제한다.그런 다음 이벤트가 꼬리에 추가되고 FIFO 입력이 점유로 표시된다.만약 그 시점에서 진입점(테일-1)이 자유롭다면, 인터럽트가 생성되고(레벨 인터럽트) 꼬리 포인터가 증가될 것이다.하드웨어에서 인터럽트를 승인해야 하는 경우, CPU(인터럽트 핸들러)는 그렇게 하고, 헤드에서 유효한 DMA 설명자를 처리한 후 인터럽트에서 돌아온다.

참고 항목

참조

  1. ^ Murray, Charles (1989). Apollo: The Race to the Moon. Simon and Schuster. pp. 345–355.