Interrupt

프로그램은 다른 프로그램들과 같이 실행된다. 따라서 번갈아가면서 실행되는데 이 말은 프로그램은 실행이 되다가 중간중간 어디선가 실행하다 멈추게 된다. 하지만 프로그램 안에는 당연히 멈추는 명령이 없다. OS도 마찬가지로 OS 프로그램 안에도 멈추라는 명령은 없다.

이 멈추는 작업은 하드웨어 가 한다. 따라서 하드웨어가 중간중간 프로그램을 멈추게 한다. 그럼 이제 프로그램이 멈출 때마다 OS가 나타난다.

A라고 하는 프로그램이 실행이 되다가 멈추고 OS가 나타나서 작업을 하고 그 다음 다시 B가 실행이 되가가 멈추고 OS가 나타난다.

그래서 이때 중간중간 멈추게 하는 작업이 인터럽트(Interrupt) 이다.

Context Switching

프로그램은 하드디스크에 있다가 메모리에 올라와서 이제 한 줄씩 CPU에서 실행이 된다. CPU에서는 한 문장씩 실행을 하게되는데 예를 들어 5번째 줄에서 멈췄다고 해보자. 그러면 나중에 다시 이 프로그램이 실행될 때는 6번째 줄부터 실행을 해야 한다.

그래서 프로그램은 중단을 할 때 중단한 지점에 필요한 모든 정보들을 다 저장을 해야된다.

A에서 B로 프로그램이 바뀌었다라는 말은 사실은 A가 멈추고 A를 다시 실행하기 위해서 필요한 정보들을 저장하고 그 다음에 B는 저장되어 있는 정보를 Restore해서 작업을 한다 라는 뜻이다.

이런 작업을 컨텍스트 스위칭(Context Switching) 이라 한다.

컴퓨터 시스템의 기본적인 요소

• 프로세서 = CPU
  • 논리 연산, and/or, shift 연산을 할 수 있는 Execution Unit
  • 연산을 위한 많은 저장 공간 레지스터들
• 메인 메모리
  • OS 프로그램 뿐만 아니라 여러가지 애플리케이션 프로그램들
  • Valatile = 휘발성 → 프로그램이 메인 메모리에 들어있을 수는 없다.
    • 즉, 프로그램은 일단 하드 디스크에 들어있고 실행을 시작하면 그 때 메인 메모리로 올라온다. 전원을 키면 OS도 메인 메모리로 올라온다.
• I/O 모듈
  • 터미널 : 마우스, 키보드 등등
  • communications equipment : 다른 사이트로 데이터를 보내거나 가져옴
  • secondary memory devices
    • 하드 디스크 : 프로세서나 메모리 입장에서는 IO작업을 해야하는 IO 모듈이다.
• 시스템 버스
  • 위의 3가지를 연결
  • 데이터가 이동하는 통로

하드 디스크에 있는 프로그램이 실행을 시작하게 되면 시스템 버스를 타고 메모리로 이동하여 메모리 어딘가에 자리를 잡게 된다. 그 다음에 CPU를 차지해서 실행을 하게 된다.

• IR: 실행하고 있는 명령이 저장된 곳
• General Register (범용 레지스터): 연산 데이터 같은 것을 저장
• MAR : Memory Address Register(몇 번째의 데이터를 가지고 오거나 쓸지)
• MBR : Memory Buffer Register(CPU와 main memory 사이를 오가는 data의 통로 역할)
• PC : 다음에 실행 예정인 명령의 주소

모든 레지스터들이 메모리와 직접 연결되어 있지 않다. 시스템 버스와 직접 연결되어 있는 부분은 MAR과 MBR이다.

만약 내가 100번째에 있는 데이터를 가져온다 ⇒ MAR ← 100 = 100번지의 데이터가 필요하다.

그런다음 memory read 명령을 준다면 100번지의 데이터가 MBR로 들어간다.

I/O AR , I/O BR 은 I/O 모듈과 CPU 사이에 데이터가 왔다갔다할 때 사용

I/O 모듈안에 버퍼가 있는 이유 : 속도 차이

CPU는 굉장히 빠르게 쓰려고 하는 데이터를 만들어놨지만 실제로 화면에 뜰 때까지는 오랜 시간이 필요하다. 흔히 CPU 같은 경우 나노 세컨드 단위로 작업을 하는데 IO 작업은 몇 초가 걸린다.

그래서 CPU는 IO 버퍼에 빠르게 보내고 자신은 다른 일을 한다. 그러면 IO 모듈은 버퍼에 있는 내용을 자기 속도에 맞춰서 화면에 띄운다.

인터럽트의 이해를 위해 두 가지를 알아야 한다.

1. 하드웨어가 인터럽트를 왜 거는지
2. 인터럽트에 걸렸을 때 어떠한 정보를 어떻게 저장해야 하는지

그러려면 먼저 프로그램이 어떻게 실행이 되는지 알아야 한다. 인터럽트는 아무때나 걸릴 수 있다. 그러나 인터럽트 처리는 아무 때나 하지 않는다. 왜냐하면 프로그램이 명령 하나를 실행하는 과정 중간에는 인터럽트 처리를 하지 않는다.

명령을 실행할 때는 두 가지 스텝으로 나누어진다.

1. Fetch Stage: 메모리에서 다음에 실행할 명령을 가져오는 단계. 명령을 가져오기만 한다.
2. Execution Stage: 명령을 실행하는 단계. 가져온 명령을 분석하고 이게 무슨 명령인지 확인한다.

Control and Status Registers

• Program Status Word (PSW) : 프로그램 실행과 관련된 그러한 역할을 하는 레지스터

시스템 안에서 프로그램을 실행 시킬 때 제일 중요한 레지스터이다. 이 레지스터를 제외한 대부분 레지스터들은 데이터를 저장하는 레지스터다. 왔다 갔다하는 데이터 또는 계산한 결과값 이런 것들을 저장하는 레지스터를 General Register(범용 레지스터)라고 부른다.

Execution Stage는 Fetch Stage에 비해 굉장히 길다. 데이터가 필요한 경우 데이터도 여러 개 가져와야 하고, 실행도 해야하기 때문에 Execution Stage가 다 끝날 때까지 IR에는 실행하고 있는 명령이 계속 들어 있다.

이 때 PSW는 프로그램을 실행시키는 데 필요한 여러가지 정보를 가지고 있는 레지스터이다. PSW는 굉장히 많은 프로그램 실행과 관련된 정보들이 모여있는 집합체라고 생각하면 된다.

• Condition Codes → 2비트
  • 양수, 음수, Overflow 유무 → 4가지 상태를 나타낸다.
• Interrupt enable/disalbe → 1비트
  • 하드웨어가 무슨 일이 발생해서 인터럽트를 걸지만 하드웨어는 이 프로그램이 어떻게 실행되는지 모른다. 단순히 자기가 필요할 때 아무 때나 인터럽트를 건다. 하지만 이 스테이지가 완전히 끝날 때까지는 절대로 프로그램을 멈출 수 없기 때문에 Execution Stage가 완전히 끝나고 다음 명령을 실행하기 전에 OS가 인터럽트 처리를 한다.
  • 명령을 처리하는 동안 인터럽트가 걸렸는지, 안 걸렸는지 표시한다.
• Supervisor/user mode
  • Superviser mode면 OS 프로그램, user mode면 그냥 유저 프로그램
  • 애플리케이션 프로그램은 자신이 사용할 수 있는 메모리 범위에서만 사용해야 한다. OS만 아무곳이나 데이터 업데이트를 할 수 있어야 한다.

Example of Program Execution

300번지에 있는 명령을 가져오려면 PC에 300번지가 들어있다고 해서 300번지 명령을 가져올 수는 없다. 먼저 PC의 값을 MAR로 옮긴다. 데이터든 명령어든 가져오거나 보내려면 MAR과 MBR을 사용해야 한다. 그래서 PC 값을 MAR로 가는 순간 PC값은 +1이 되어서 다음 명령을 가리키게 된다.

그 다음 메모리 Read 신호를 주게 되면 MAR에 저장된 번지의 명령(300번지의 명령)이 MBR로 이동하게 된다. MBR에는 메모리에서 CPU로 들어오는 모든 Instruction이나 데이터가 임시 저장되는 곳이다.

최종적으로 MBR에 들어있는 명령을 IR로 옮기게 된다. 이렇게 Fetch Stage가 끝나게 된다.

그러면 이제 명령을 가져온 다음 Execution Stage에 무엇을 할 것인지 명령을 분석한다.

프로그램 상에서 메모리로 데이터를 가져오고 프로그램이 중단될 수도 있고, 덧셈을 하자마자 프로그램이 중단될 수도 있고, 두번째 줄 실행하자 중단될 수도 있다. 이런식으로 프로그램이 어디서 중단이 될지 알 수 없다.

Fetch Stage

1. MAR ← PC, PC++
2. memory read, MBR ← (MAR에 저장된 번지의 명령)
3. IR ← MBR

Interrupts

인터럽트는 정상적인 프로그램의 실행을 중단시키는 이벤트이다.

인터럽트가 발생하는 이유

• 프로그램 인터럽트
• 타이머 인터럽트
• IO 인터럽트
• 하드웨어 failure 인터럽트

프로그램 인터럽트

Instruction을 하나씩 실행하다가 어떤 명령어 실행했더니 어떠한 문제가 발생해서 프로그램을 중단시켜야 되는 상황 → 프로그램 인터럽트

• OverFlow
• Division by 0
• Illegal machine instruction
  • 데이터를 Instruction인줄 알고 읽은 경우
  • 하드디스크에서 메모리로 올라오는 과정에서 오류
• 정해진 범위를 벗어나는 범위를 읽거나 쓰려고 하는 경우

위의 4가지 상황 모두 하드웨어 인터럽트 이다. 인터럽트를 발생시키는 주체는 프로그램이 아니라 하드웨어다.

프로그램 인터럽트라고 이름이 붙은 이유는 프로그램을 실행하다가 Instruction을 실행하는 과정에서 Instruction 때문에 문제가 발생했다는 뜻이다.

즉, 원인은 프로그램이지만 잘못됐다는 것을 찾아내는 것은 Instruction을 실행하는 과정에서 관여하고 있는 하드웨어들이다.

타이머 인터럽트

한 프로그램에 계속 CPU를 주고 실행을 하게 할 수는 없다. 시스템 안에는 보통 수십개에서 수백개의 프로그램이 동시에 실행되고 있기 때문에 한 프로그램당 시간을 정해줘야 한다.

할당된 시간이 지나면 타이머가 인터럽트를 발생시킨다.

I/O 인터럽트

I/O 컨트롤러에 의해서 발생한다. → 하드웨어 인터럽트

I/O 인터럽트는 작업을 하기 위해서 발생하는 것이 아니라, I/O 작업이 끝났다는 걸 알려줄 때 발생하는 인터럽트이다.

하드웨어 failure 인터럽트

시스템상의 파워가 잘못됐다거나, 메모리를 읽기/쓰기 하는 과정에서 오류가 나는 등 프로그램 자체가 아니라 시스템에 있는 하드웨어에 문제가 발생했을 때 발생시키는 인터럽트이다.

I/O 인터럽트를 사용하는 이유

I/O 인터럽트를 사용하는 이유는 I/O 디바이스는 CPU보다 굉장히 느리다. IO 작업을 하는 동안 CPU가 그냥 멈춰서 기다릴 수가 없다.

입출력은 프로그램이 하는게 아니라 OS만 입출력을 할 수가 있다. READ, WRITE는 자가 입출력문이 아니라, OS한테 입출력을 해달라고 요청하는 문장이다.

WRITE는 직접 입력을 자기가 하는 문장이 아니라 입출력 처리를 할 수 있도록 IO 프로그램을 호출하는 문장으로 OS가 이 IO 프로그램을 실행 시켜서 진짜 입출력을 하게 된다.

왼편의 4번은 데이터를 CPU가 가져다가 명령을 분석하고, 그 다음 데이터를 IO 버퍼에 보내는 IO 작업을 하기 위해서 필요한 전처리를 하는 부분이다.

그 다음 IO 커맨드라고 되어있는 부분이 IO 디바이스가 출력을 시작하는 부분이다. 사실 이 IO 작업은 오른편 그림처럼 굉장히 길다. 그래서 이 작업을 실행하는 동안에는 사실 CPU가 그냥 놀게 된다.

왼편의 그림은 인터럽트가 없는, 즉 CPU가 그냥 기다리는 상황을 가정한 그림이다.

5번 작업은 IO 디바이스가 정상적으로 출력을 완료해도 경우에 따라서 오류가 발생할 수 있는데 이때 어떤 장치에서 어떠한 오류가 났는지 결과를 확인하는 부분이다.

그래서 왼편은 다음과 같은 작업 순서를 가진다.

1 → 4 → 5 → 2 → 4 → 5 → 3

이렇게 하면 CPU가 노는 부분이 많아진다. 그래서 오른쪽 그림처럼 IO 커맨드 작업을 하는 동안 CPU는 기다리지 않고 원래 유저 프로그램으로 돌아가서 2번 문장을 실행한다. 실행 중 IO 작업이 다 끝나면 그 때 제대로 끝났는지 또는 오류가 발생했는지 확인한다.

프로그램을 다시 실행하다가 IO 작업의 종료를 확인할 수 있는 방법은 인터럽트 뿐이다.

그래서 CPU한테 인터럽트를 걸어서 인터럽트를 발생시켜 5번 코드를 실행시켜달라고 하는 것이다.

Interrupt Handler

발생한 인터럽트를 처리하기위한 프로그램을 Interrupt Handler라고 하고 이 프로그램은 OS의 일부이다. 인터럽트 처리 루틴이 다 다르기 때문에 핸들러는 제일 먼저 왜 인터럽트가 발생했는지 확인한다.

Long I/O wait

여기서 2번 작업을 다 끝났는데 아직 I/O 작업이 끝나지 않은 상황이다. 이때는 어쩔 수 없이 기다린다. 기다리다가 인터럽트가 발생해서 5번을 실행하고 다시 WRITE를 해야 하는 상황이기 때문에 4번을 하고 그 다음 3번 작업을 실행하러 가는 것이다.

실제로는 IO 작업을 시키고 아예 다른 프로그램을 실행을 시킨다. 그래서 1번, 4번하고 2번을 하지도 않고 그냥 프로그램을 바꾼다. 그런데 인터럽트는 어느 타이밍에 걸릴지 알 수가 없다.

A 프로그램에서 IO 작업을 하고, B 프로그램을 실행을 시켰다. 이 때 A로부터 요청했던 IO 작업이 끝났다는 인터럽트가 B를 실행하고 있는 도중에 걸린다. 그러면 OS가 Interrupt 핸들링을 하고 다시 B를 실행시킨다.

A 실행 -> A IO 작업 -> B 실행 -> A 인터럽트 -> A 인터럽트 핸들링 -> A 핸들링 종료 -> B 실행

만약 Fetch, Execution 사이클을 실행하는 동안에 인터럽트가 걸린다면 PSW의 interrupt enable/disable 비트에 표시를 해준다.

그리고 Execution Stage가 끝나면 인터럽트가 발생했는지 확인한다. 발생하지 않았다면 Fetch Stage로 가고 발생했다면 Intterupt Stage로 간다.

Interrupt Stage에서는 인터럽트를 확인하고 종류에 따라 처리를 하게된다. Interrupt Stage에서는 인터럽트 핸들러를 실행시키지 않는다. 실행을 시작시키는 것이다. 그 다음 한줄한줄 fetch-execute를 통해 실행시킨다.

인터럽트 스테이지가 끝나면 실행중이던 프로그램이 다시 시작되는 게 아니라, 인터럽트 핸들러 프로그램의 fetch 스테이지가 시작된다.

유저 프로그램이 실행되고 있다가 인터럽트가 발생해 인터럽트 핸들러를 실행한다. 인터럽트 핸들러가 다 실행된 다음 두번째 명령을 실행하려 하는데 문제사항이 있다.

인터럽트 핸들러도 프로그램이므로 메모리 안에 들어있다. 예를 들어 100번지부터 200번지까지 들어있다면 PC는 201번지라고 되어있을 것이다. 그러면 두번째줄을 실행할 수 없다. 왜냐하면 두번째 줄은 301번지부터 실행해야 하기 때문에 프로그램 카운터의 내용이 다 사라져 버린 것이다.

AC의 값 또한 사라질 것이다. 핸들러를 실행하면서 AC가 데이터를 가져오거나 하는 작업을 하면서 값이 바뀐다. 즉, CPU 안에 있는 어떤 레지스터도 안전하지 않다.

따라서 CPU 안에 있는 모든 레지스터 값을 다 저장해야 한다. 프로그램을 실행하면서 절대 건드리지 않을 메모리에다가 저장을 해야한다.

따라서 핸들러가 작업을 마치면 메모리 안에 저장했던 CPU 내용들을 그대로 다시 리스토어한다.

왼편에서 실행되는 작업들은 하드웨어이고, 오른편에서 실행되는 작업은 소프트웨어이다. 오른편의 작업은 인터럽트 핸들러라는 소프트웨어가 실행하는 작업이다. 왼편은 핸들러가 작업을 하기전에 하드웨어적으로 처리가 되어야 하는 부분이다.

하드웨어 작업

인터럽트 처리는 Fetch, Execution까지 완전히 끝낸 다음에 처리한다. 그 다음 CPU가 인터럽트 처리를 시작하고 인터럽트가 발생했다는 비트를 꺼둔다. 그래서 인터럽트 시그널을 프로세스가 인터럽트를 인식했다고 시그널을 보낸다.

그 다음 많은 레지스터 중 PSW와 PC 두 개의 레지스터만 컨트롤 스택에다가 먼저 저장한다. 이 작업은 하드웨어적으로 하는 작업이다. 컨트롤 스택은 메모리 안에 들어있는 이 CPU의 내용을 저장할 스택을 말한다.

그러고 나서 CPU가 인터럽트 종류에 따라서 적절한 핸들러의 시작 주소를 PC에다가 저장한다.

핸들러의 위치, 핸들러를 불러오는 것 까지 전부 하드웨어적으로 처리된다.

소프트웨어 작업

핸들러가 작업을 시작한다.

그 다음 CPU의 나머지 레지스터 내용들을 컨트롤 스택에 저장한다. 이 작업은 소프트웨어적으로 핸들러가 저장한다. 하드웨어적으로 할 때 다 한번에 하지 않고 왜 핸들러가 저장을 할까?

하드웨어적으로 한다는 것은 다 저장하도록 설계를 해야한다는 것이다. 그럼 하드웨어가 훨씬 복잡해지고 비용이 훨씬 증가한다. 따라서 하드웨어적으로 하는 작업은 정말 최소한만으로 한다.

새로운 프로그램을 불러올 때는 하드웨어적으로 처리를 하는게 당연하다. 왜냐면 핸들러는 어떤 인터럽트가 걸렸는지, 종류에 따라서 처리해야 하는 루틴이 메모리 어디에 있는지 전부 하드웨어적으로 저장해놨기 때문에 하드웨어에서 처리를 해야한다.

인터럽트 작업이 끝나고 process state information을 먼저 리스토어한 다음, PSW와 PC값을 리스토어한다. PSW와 PC를 마지막에 저장하는 이유는 PC와 PSW를 먼저 집어넣고 레지스터들을 다시 리스토어한다는 것은 불가능하다. PC값을 바꾸는 순간 유저 프로그램이 실행을 시작하기 때문에 핸들러는 더 이상 작업할 수 없게된다.

새로운 핸들러를 불러올 때에는 하드웨어적으로 처리하는 것이 당연하다. 핸들러는 어떤 인터럽트가 걸렸는지, 종류에 따른 처리 루틴이 메모리 어디에 있는지가 하드웨어적으로 저장을 해놨기 때문에 하드웨어적으로 처리된다.

그런데 PC랑 PSW를 왜 하드웨어적으로 처리할까?

핸들러 프로그램의 시작주소를 PC로 불러오는 것은 하드웨어적으로 처리한다. 핸들러 프로그램이 시작되기 전에 기존에 실행중이었던 프로그램의 현재 주소와 실행 정보를 저장해야 한다. 따라서, 같이 하드웨어적으로 처리해야 한다.

Changes in Memory and Registers

회색 : 메인 메모리

하늘색 : CPU

Control Stack : 프로그램이 중단됐을 때 프로그램이 중단되면 CPU 안에 있는 레지스터 값들이 저장되는 스택

• (a) 상황: n번째 명령을 실행하고 있을 때 인터럽트가 발생

1. 프로그램 카운터와 PSW값을 컨트롤 스택에 저장
2. Y값을 프로그램 카운터에 집어넣는다 ⇒ 핸들러 프로그램이 실행 → 나머지 레지스터 값들을 Control Stack에 저장

• (b) 상황 : 인터럽트 서비스가 끝남

1. CPU 상태를 유저 프로그램 중단 직전의 상태로 만들어야 한다 = Control Stack 중 PC와 PSW를 제외한 나머지 값들을 전부 CPU안에 있는 레지스터에 Restore 한다.
2. 스택 포인터가 다시 돌아온다.
3. 다음에 실행할 주소의 값을 PC로 가져온다.

Memory Hierarchy

CPU의 실행 속도는 나노 세컨드 단위로 실행하지만, 메모리에서 가져올 때는 마이크로 세컨드 단위로 가져온다. 따라서 나노 세컨드에 비해 속도가 느리다. ⇒ 중간 단계에 cache 메모리를 넣는다.

하드 디스크에 있던 프로그램의 일부를 메모리로 가져오고, 메모리에 있는 프로그램의 일부를 캐시로 가져온다. 그 다음 캐시에서 명령을 읽어서 레지스터로 가져와서 실행을 하게된다.

위로 올라갈수록 비용이 상당히 비싸진다. 따라서 레지스터, 캐시 메모리는 굉장히 비싸고 메모리는 비교적 싼 편이다. 결국, Hierarchy가 아래로 내려갈수록 싸다.

따라서 하드 디스크에 있는 명령을 한줄씩 읽어서 실행한다는 것은 있을 수 없다. 그래서 보통 프로그램들은 하드디스크에 있고 이 중에 필요한 부분을 보통 한 페이지 단위 메모리에 넣는다. 그 다음 메모리에 들어있는 코드를 보통 한 블록 단위로 캐시로 가져와서 실행한다.

캐시를 사용하여 프로그램 실행 속도를 높인다 = 메모리에 있는 것을 한번 캐시로 가져가면 캐시에 있는 명령어와 데이터를 반복해서 여러 번 실행

그래야만 메모리로 접근하는 횟수가 줄어든다.

Locality of reference

코드를 작성할 때 반복문이 제일 많다. 반복한다는 것은 어떤 명령 하나를 실행하면 한 바퀴 돌아 금방 다시 해당 코드를 실행하게 된다. 이 것을 타임 로컬리티(Time Locality) 라고 한다.

대용량의 데이터를 저장할 때에는 주로 배열에 저장하게 된다. 이 말은 배열에 있는 데이터 하나를 가져오면 그 다음 데이터에 대해 같은 작업을 반복하게 될 것이다. 따라서 가져다 놓은 데이터를 한동안 계속 쓰게되는데, 이를 공간적 로컬리티(Spatial Locality) 라 한다.

이와 같은 로컬리티가 Memory Hierarchy를 가능하게 해준다.

메인 메모리에는 동시에 실행시키는 여러 개의 프로그램이 다 올라와 있다. 하지만 CPU는 실제로 어느 순간에 하나만 실행한다. 따라서 지금 실행하고 있는 프로그램 하나만 캐시에 올려놓으면 된다. 이렇게 메모리의 속도를 높일 수 있는 것은 레퍼런스의 로컬리티(Locality of Reference) 가 적용되기 때문이다.

CPU는 항상 어느 순간에 한 프로그램만 실행한다. 따라서 실행하고 있는 프로그램만 캐시에 올려놓으면 된다. 따라서 지금 실행하고 있는 프로그램 코드만 캐시에 있으면 되므로 크기가 작아도 충분히 역할을 수행할 수 있다.

OS에게 Invisible → 캐시는 하드웨어적으로 컨트롤된다. 즉, 캐시 관리는 OS가 하지 않는다. 어떤 것을 가져올지, 어떤 것을 버릴지에 대한 결정은 하드웨어적으로 이루어진다.

3단계 캐시의 각 캐시는 같은 속도, 같은 용량이 아니다. 1단계에 있는 쪽이 3단계에 있는 캐시보다 훨씬 빠른 대신 용량은 적다.

캐시는 왜 하드웨어적으로 관리할까?

하드웨어적으로 처리해야 빠른 속도를 유지할 수 있다. 소프트웨어적으로 처리하면 결국 메모리에 접근하게 된다.

I/O Techniques

• Programmed IO
  • OS프로그램이 IO작업을 한다. IO작업을 실행하고 IO가 발생하는 동안 CPU는 멈춰있다.
• Interrupt-Driven IO
  • CPU는 기다리지 않고 유저 프로그램으로 돌아와서 유저 프로그램을 실
• Direct Memory Access(DMA)
  • 표준 입출력이 아니라 파일 입출력인 경우 굉장히 많은 양의 데이터를 CPU를 거쳐서 데이터를 왔다갔다 하기에는 시간이 굉장히 오래걸리고 비효율적이다. 따라서 메모리에 있는 데이터를 CPU를 거치지 않고 한꺼번에 IO 버퍼로 이동시킨다.
  • DMA 작업을 하기 위해서 IO 모듈안에 DMA 모듈이 별도로 있거나 시스템 버스에 DMA 모듈이 붙어있는 경우도 있다.

DMA

한 Block의 데이터가 CPU를 거치지 않고, 메모리와 I/O 장치 사이에서 직접 전달된다.

입출력 작업을 DMA 모듈이 스스로 실행을 시작할 수 없다. 모든 명령은 CPU가 가서 읽고 분석하고 무슨 명령인지 판단해서 실행하기 때문이다.

DMA로 한번에 얼만큼 읽거나 쓸지에 대한 판단은 CPU가 한다. 즉, CPU가 DMA 명령임을 분석하고 메모리 어디에 있는 데이터를 얼만큼 I/O 장치로 보낼지 관리해야 한다.

IO 작업이 끝나면 DMA 모듈이 IO 인터럽트를 걸어서 IO 작업을 마무리한다.

DMA 방식을 사용하게 되면 메인 메모리에서 바로 시스템 버스를 타고 IO 모듈안에 있는 버퍼로 이동한다. 그런데 시스템 버스는 두 사람이 동시에 사용할 수 없다. DMA 작업, IO 작업을 하고 있는 동안에도 CPU는 계속해서 명령을 한줄씩 읽고 분석하고 실행하고 작업을 한다. 그러면 메모리에서 CPU로 명령어나 데이터가 움직일 때는 당연히 DMA 모듈이 메모리로 데이터를 보낼 수 없다.

그래서 시스템 버스를 나눠서 사용해야 하고 CPU가 더 우선순위를 가지지만, DMA 작업이 실행이 되고 있을 때는 CPU 실행이 늦어질 수도 있다.

Symmetric Multiprocessors

SMP = 멀티 프로세서 시스템 : 여러 개의 프로세서를 가지고 있는 시스템

각각의 CPU는 캐시를 가지고 있다.

symmetric 이라는 말은 CPU가 여러 개 있어도 메모리는 1개다. 메모리 안에 OS가 들어 있으므로 모든 CPU들이 메모리에 들어있는 OS 코드를 실행할 수 있다. 따라서 다들 동등한 권한을 가지고 OS 코드를 실행할 수 있다.

symmetric 하지 않다는 것은 한 CPU만 마스터 프로세서라고 해서 OS를 실행시킬 권한을 한 사람에게만 줬다.

symmettric 멀티 프로세서를 사용하게 되면 가각의 프로세서들이 다 동등하게 OS를 실행시킬 수 있게 된다. CPU가 많고 동시에 어떤 작업을 할 때는 특정한 데이터나 특정한 리소스는 동시에 사용하지 못하도록 해야하고 한번에 한사람만 사용하게 하는 동기화 작업을 해주어야 한다.

그리고 CPU 10배가 속도의 10배를 만들지 않는다. 메모리는 1개이기 때문이다.

Multicore Computer

칩 1개안에 여러 개의 CPU가 들어있는 경우 → 멀티코어

작은 공간에 수십 개, 수백 개의 CPU를 장착한 컴퓨터 → 매니코어