Interrupt에 대해 다시 한번 정리해보자면 디바이스가 CPU에게 무엇인가 알려주고 싶을 때 발생한다. 라고 할 수 있겠다.
예를 들어 CPU의 I/O request뿐만 아니라 배터리 controller의 배터리가 다 떨어졌다, 프린터 controller의 종이가 떨어졌다 등등이 되겠다.
CPU가 신호를 device controller에게 보내고 신호(인터럽트)가 돌아오기만을 기다리는 방식을 Synchronous I/O라고 한다.
위에서 보았듯이 인터럽트는 I/O request에 대한 응답뿐이 아니다. 따라서 언제 도착할지 알 수 없다. 그래서 나온 방법이 지난 번에도 보았듯이 CPU는 다른 프로세스를 돌리다가 신호(인터럽트)가 돌아오면 처리하고 이 방식을 Asynchronous I/O라고 한다.
이 경우 여러 프로세스가 여러 디바이스로 여러 I/O request를 보낼 수도 있다. 단, 도착은 동시에는 할 수 없다. (bus때문이다.)
그림을 통해 비교해보자.
그림의 왼쪽이 Synchronous I/O 방식이다. CPU에서의 작업시간이 매우 적음을 알 수 있다.
오른쪽은 Asynchronous I/O 방식이다. CPU를 쉬지 않고 돌릴 수 있다.
자 그렇다면 동작 과정을 한 번 정리해보자.
1. CPU는 A프로세스를 돌리고 있다가 인터럽트가 도착했다.
2. OS는 A프로세스의 값들을 저장한다. push(stk_ptr, PC) (context switch라 하며 밑에서 다루겠다.)
3. 인터럽트를 확인한다. 이 때 2가지 방식이 있다.
3.1) polling : 어떤 device가 신호를 보낸 건지 모든 device에게 물어본다.
3.2) vectored interrupt
- 모든 인터럽트가 번호를 가진다.(IRQ n)
- 각 디바이스가 원하는 서비스 인터럽트를 고유한 신호로 보낸다. 1
- CPU는 interrupt vector를 확인해 어떤 서비스를 원하는지 확인한다. interrupt vector에는 실행할 서비스 routine의 주소값이 있다.
4. 여기선 vecotred interrupt 방식을 사용한다. interrupt vector를 통해 ISR(Interrupt Service Routine)의 주소값을 확인했으니 실행해주어야 한다. PC = xxx로 설정해주면 된다.
5. ISR이 끝났다면 다시 A프로세스로 돌아간다. PC=pop(stk_ptr)
그럼 위 과정에서 ISR을 실행하고 있던 도중에 또 다른 interrupt가 왔다면 ??
예상되는 방법으로는 다음과 같이 있을 것이다.
1. 연기한다.(즉, 끝나고 한다.)
2. 무시한다.
3. 뒤에 도착한 interrupt를 먼저 처리한다.
당연한 말이겠지만 2번일리는 없다. 우선 순위에 따라서 1번과 3번이 실행된다.
위 그림과 같이 높은 우선 순위의 interrupt가 들어오면 기존 걸 쫓아낸다. (a, b)
쫓겨난 프로세스는 쫓아낸 프로세스가 종료되면 회복한다.
물론 우선순위가 같다면 1번 방식대로 즉, FIFO로 실행한다. (c, d)
위 상황에서 b로 인해 a가 쫓겨날 때 CPU에 있던 a의 정보들을 메인 메모리에 저장해주어야 한다. 또 b가 끝난 후 다시 a를 실행할 때 저장해둔 정보들을 받아와야 한다. 이러한 과정을 context switch(문맥 교환)이라 한다. 아까의 동작 과정 2에 해당하는 과정이다.
1. CPU는 데이터를 Device controller에서 메모리로 직접 운반하기에는 너무 중요한 자원이다.
2. 또 메인 메모리는 명령어를 실행할 때 많이 쓰인다. 패치 - 디코드 - 데이터 패치 - 실행 - 저장 중 패치, 데이터패치, 저장에서 사용된다.
3. 메인 메모리는 일반적으로 한 번에 하나의 word만 전송한다. 즉, 만약 다른 디바이스가 메인 메모리를 사용하면 CPU의 작업이 원할하지 못하다.
위와 같은 이유로 DMA(Direct Memory Access)가 CPU의 개입 없이 device controller의 버퍼와 메인 메모리 사이에서 모든 데이터를 직접 옮긴다.
이런 방식의 경우 모든 전송이 끝난 후에 DMA controller의 interrupt 한 번이면 전송이 끝났음을 알 수 있다.
그런데 만약 DMA가 전송을 위해 bus를 독점한다면 CPU의 작업이 멈춰버린다. 그래서 DMA는 CPU가 메인 메모리를 사용하지 않는 순간 즉, 디코드와 실행 과정에서 DMA가 데이터를 옮긴다.
이러한 DMA를 사용하기 위해 Device와 Memory가 같은 주소 공간을 공유해야하는데 이를 Memory Mapped I/O라 한다.
DST(Device Status Table)이 있는데 각 device들의 상태가 담긴 테이블이며 OS가 관리한다.
지금까지의 내용들을 간단한 예시를 통해 정리해보겠다.
우선 Read 명령이며 device의 버퍼는 512 bytes라 가정한다.
1. User 프로세스 U_A 실행 중 IO 명령이 발생했다. (Read 명령)
2. CPU는 OS 프로세스 O_A를 device controller에게 보낸다.
3. CPU는 OS_B로 DST를 조정한다.
4. 이 때 DST를 조정 중 U_B를 실행한다 가정해보자.
5. Device Controller는 디코딩 및 할 일들을 식별한다.(Read 명령)
6. Device Controller는 버퍼로 512 bytes를 이동한다.(읽어온다.)
7. Device Controller는 CPU에게 interrupt를 보낸다.
8. CPU는 US_B를 일단 멈춘다.
9. CPU는 OS_C로 interrupt를 식별한다.
10. CPU는 OS_D로 ISR을 실행한다.
11. ISR이 끝난 후 DMA를 실행(호출)한다.
12. CPU가 OS_E를 통해 U_B를 다시 실행한다.
13. DMA는 CPU와 독립적으로 실행된다.
14. 512 bytes가 버퍼에서 메인 메모리로 모두 옮겨졌다.
15. DMA는 CPU에게 interrupt를 보낸다.
16. CPU는 US_B를 일단 멈춘다.
17. CPU는 OS_F로 DST를 조정한다.
18. CPU는 OS_G로 U_B를 다시 실행한다.
19. U_B가 실행된다.
여기서 context switch는 1~2 / 3~4 / 8~9 / 12 / 16~17 / 18~19 에서 일어난다.
나름 이해하고 글 썼다고 생각하는데 틀린 부분이 있을지도 모르겠다..
- CPU는 어떤 device가 보낸 건지 알 수 있다. [본문으로]
'운영체제' 카테고리의 다른 글
| OS Structure, Hardware Protection (0) | 2020.07.07 |
|---|---|
| 메모리 (0) | 2020.07.06 |
| OS의 가동 및 interrupt (0) | 2020.04.06 |
| CPU 명령 실행 과정 (0) | 2020.03.29 |
| 컴퓨터 시스템의 구성 요소 (1) | 2020.03.24 |
