1. 장치 컨트롤러와 장치 드라이버

실제 여러분이 사용하는 컴퓨터를 생각해 보세요. 컴퓨터에는 CPU와 메모리만 있지 않습니다.

• 스피커, 모니터, 키보드, 마우스 등과 같은 입출력장치와 외장 하드 디스크나,
• USB 메모리 등 보조기억장치가 컴퓨터에 주렁주렁 달려 있습니다.

이번 절에서는 장치 컨트롤러와 장치 드라이버라는 개념을 통해

• 다양한 외부 장치가 컴퓨터 내부와 어떻게 연결되고 소통하는지를 알아보겠습니다.
• cf. 이번 장에서 언급하는 입출력장치는 보조기억장치도 포함합니다.
  • 보조기억 장치가 컴퓨터 내부와 정보를 주고받는 방식은 입출력장치와 크게 다르지 않기 때문입니다

1.1 장치 컨트롤러

입출력장치는 앞서 학습한 CPU, 메모리보다 다루기가 더 까다롭습니다. 왜일까요? 여기에는 크게 두 가지 이유가 있습니다.

1. 입출력장치에는 종류가 너무 많다.

   • e.g. 키보드, 모니터, USB 메모리, CD-ROM, SSD, 마우스, 프린터, 스피커, 마이크 등
   • 장치가 이렇게 다양하면, 자연스레 장치마다 속도, 데이터 전송 형식 등도 다양하다.
   • 다양한 입출력장치와 정보를 주고받는 방식을 규격화하기 어렵다.
   • e.g. 이는 마치 CPU와 메모리는 한국어를 사용하는데,
     • 프린터는 영어, 스피커는 일본어, 모니터는 중국어를 사용하는 상황과 같습니다.

   

2. 일반적으로 CPU와 메모리의 데이터 전송률은 높지만, 입출력장치의 데이터 전송률은 낮습니다.

• 전송률(transfer rate) : 데이터를 얼마나 빨리 교환할 수 있는지를 나타내는 지표
  • CPU, 메모리처럼 전송률이 높은 장치는 1초에도 수 많은 데이터를 주고받을 수 있지만,
  • 키보드, 마우스같이 전송률이 낮은 장치는 데이터를 조금씩만 주고받을 수 있습니다.
• e.g. 1초에 1,000마디를 내뱉는 사람과 1초에 한 마디를 내뱉는 사람끼리 제대로 대화하기란 어렵겠죠?
  • 전송률의 차이는 CPU와 메모리, 입 출력장치 간의 통신을 어렵게 합니다.
• cf. 물론 어떤 입출력장치는 CPU나 메모리보다 전송률이 높은 경우도 있습니다.
  • 하지만 결과적으로 CPU나 메모리와 전송률이 비슷하지 않기 때문에 같은 어려움을 겪게 됩니다.

위와 같은 이유들로 입출력 장치는 장치 컨트롤러(device controller)를 통해 컴퓨터와 연결됩니다.

• 모든 입출력장치는 각자의 장치 컨트롤러를 통해 컴퓨터 내부와 정보를 주고받고,
• 장치 컨트롤러는 하나 이상의 입출력장치와 연결되어 있습니다.
• cf. 장치 컨트롤러는 입출력 제어기(I/O controller), 입출력 모듈(I/O module) 등으로 다양하게 불리는데,
  • 여기서는 장치 컨트롤러라는 용어를 사용하겠습니다.

1.1.1 장치 컨트롤러의 역할

장치 컨트롤러는 대표적으로 다음과 같은 역할을 통해 앞에서 언급한 문제들을 해결합니다.

• CPU와 입출력장치 간의 통신 중개

  • 입출력장치 종류가 많아 정보 규격화가 어려웠던 문제는
  • 장치 컨트롤러가 일종의 번역가 역할을 함으로써 해결

• 오류 검출

  • 번역하는 과정에서 장치 컨트롤러는 자신과 연결된 입출력장치에 문제는 없는지 오류를 검출하기도 함

• 데이터 버퍼링

  • 버퍼링(buffering) : 전송률이 높은 장치와 낮은 장치 사이에 주고받는 데이터를
    • 버퍼(buffer)라는 임시 저장 공간에 저장하여 전송률을 비슷하게 맞추는 방법

쉽게 말해 버퍼링은

• 버퍼에 데이터를 조금씩 모았다가 한꺼번에 내보내거나, 데이터를 한 번에 많이 받아 조금씩 내보내는 방법
• 즉, 장치 컨트롤러는 전송률이 높은 CPU와 전송률이 낮은 입출력장치와의 전송률 차이를
  • 데이터 버퍼링으로 완화합니다.

1.1.2 장치 컨트롤러의 내부구조

이번에는 장치 컨트롤러의 간략화된 내부 구조를 살펴봅시다. 장치 컨트롤러 내부는 위 그림과 같습니다.

• 실제로는 이보다 더 복잡하지만, 기억할 건 3가지입니다.
  • 데이터 레지스터(data register)
    • CPU와 입출력장치 사이에 주고받을 데이터가 담기는 레지스터(버퍼)
    • 장치 컨트롤러는 데이터 버퍼링으로 전송률 차이를 완화한다고 했었죠?
    • 데이터 레지스터가 그 버퍼 역할을 합니다.
    • 최근 주고받는 데이터가 많은 입출력장치에서는 레지스터 대신 RAM을 사용하기도 함
  • 상태 레지스터(status register)
    • 입출력장치가 입출력 작업을 할 준비가 되었는지,
    • 입출력 작업이 완료되었는지,
    • 입출력장치에 오류는 없는지 등의 상태 정보가 저장
  • 제어 레지스터(control register)
    • 입출력장치가 수행할 내용에 대한 제어 정보와 명령을 저장
• 이 레지스터들에 담긴 값들은 버스를 타고,
  • CPU나 다른 입출력장치로 전달되기도 하고,
  • 장치 컨트롤러에 연결된 입출력장치로 전달됩니다.
• cf. 상태 레지스터와 제어 레지스터는 하나의 레지스터(상태/제어 레지스터)로 사용되기도 합니다.
  • 다만, 여기서는 혼란을 방지하기 위해 상태 레지스터와 제어 레지스터를 분리하여 표현하겠습니다.

1.2 장치 드라이버

새로운 장치를 컴퓨터에 연결하려면, 장치 드라이버(device driver)를 설치해야 합니다.

• 장치 드라이버 : 장치 컨트롤러의 동작을 감지하고 제어하는 프로그램
  • 이렇게 함으로써 장치 컨트롤러가 컴퓨터 내부와 정보를 주고받을 수 있음
  • 프로그램이기에 당연히 실행 과정에서 메모리에 저장됨
• 장치 컨트롤러가 입출력장치를 연결하기 위한 하드웨어적인 통로라면,
• 장치 드라이버는 입출력장치를 연결하기 위한 소프트웨어적인 통로입니다.
• 컴퓨터가 연결된 장치의 드라이버를 인식하고 실행할 수 있다면,
  • 그 장치는 어떤 회사에서 만들어진 제품이든,
  • 생김새가 어떻든 상관없이 컴퓨터 내부와 정보를 주고받을 수 있습니다.
• 반대로 장치 드라이버를 인식하거나 실행할 수 없는 상태라면,
  • 그 장치는 컴퓨터 내부와 정보를 주고받을 수 없습니다.

💡 장치 드라이버를 인식하고 실행하는 주체는 OS

• 장치 드라이버를 인식하고 실행하는 주체는 윈도우, macOS와 같은 운영체제입니다.
• 즉, 운영체제가 장치 드라이버를 인식하고 실행할 수 있다면,
  • 그 장치는 컴퓨터 내부와 정보를 주고받을 수 있습니다.
• 장치 드라이버는 운영체제가 기본으로 제공하는 것도 있지만,
  • 장치 제작자가 따로 제공하기도 합니다.
  • 물론 장치 제작자가 장치 드라이버를 따로 제공하는 경우,
  • 입출력장치는 해당 드라이버를 직접 설치해야만 사용이 가능합니다.

2. 다양한 입출력 방법

입출력 작업을 수행하려면, CPU와 장치 컨트롤러가 정보를 주고받아야 합니다.

• 그렇다면 장치 컨트롤러는 CPU와 어떻게 정보를 주고받을까요?
• 여기에는 크게 3가지 방법이 있습니다.
• 프로그램 입출력, 인터럽트 기반 입출력, DMA 입출력

2.1 프로그램 입출력

프로그램 입출력(programmed I/O) : 프로그램 속 명령어로 입출력장치를 제어하는 방법

• CPU가 프로그램 속 명령어를 실행하는 과정에서 입출력 명령어를 만나면,
• CPU는 입출력장치에 연결된 장치 컨트롤러와 상호작용하며 입출력 작업을 수행합니다.

메모리에 저장된 정보를 하드 디스크에 백업하는 상황을 생각해보죠. CPU는 대략 아래 과정으로 입출력 작업을 합니다.

(1) **‘메모리에 저장된 정보를 하드 디스크에 백업한다’**는 말은 **‘하드 디스크에 새로운 정보를 쓴다’**는 말과 같습니다. 우선 CPU는 하드 디스크 컨트롤러의 제어 레지스터에 쓰기 명령을 보냅니다.

(2) 하드 디스크 컨트롤러는 하드 디스크 상태를 확인합니다. 하드 디스크가 준비된 상태라면, 하드 디스크 컨트롤러는 상태 레지스터에 준비되었다고 표시합니다.

(3)

1. CPU는 상태 레지스터를 주기적으로 읽어보며, 하드 디스크의 준비 여부를 확인합니다.
2. 하드 디스크가 준비됐음을 CPU가 알게 되면, 백업할 메모리의 정보를 데이터 레지스터에 씁니다.
   • 아직 백업 작업(쓰기 작업)이 끝나지 않았다면, 1번부터 반복하고, 쓰기가 끝났다면 작업을 종료합니다.

이렇듯 프로그램 입출력 방식에서의 입출력 작업은 CPU가 장치 컨트롤러의 레지스터 값을 읽고 씀으로써 이루어집니다.

• 그런데 CPU는 입출력장치들의 주소를 어떻게 아는 걸까요?
• 정확히 말해, CPU는 장치 컨트롤러의 레지스터들을 어떻게 아는 걸까요?

CPU 내부에 있는 레지스터들과는 달리, CPU는 여러 장치 컨트롤러 속 레지스터들을 모두 알고 있기란 어렵습니다. 그렇다면 아래와 같은 명령어들은 어떻게 명령어로 표현되고, 메모리에 어떻게 저장되어 있을까요?

• 프린터 컨트롤러의 상태 레지스터를 읽어라.
• 프린터 컨트롤러의 데이터 레지스터에 100을 써라.
• 키보드 컨트롤러의 상태 레지스터를 읽어라.
• 하드 디스크 컨트롤러의 데이터 레지스터에 ‘a’를 써라

여기에는 크게 다음 2가지 방식이 있습니다.

• 메모리 맵 입출력
• 고립형 입출력

2.1.1 메모리 맵 입출력(memory-mapped I/O)

• 메모리에 접근하기 위한 주소 공간과 입출력장치에 접근하기 위한 주소 공간을
  • 하나의 주소 공간으로 간주하는 방법
• e.g. 1,024개의 주소를 표현할 수 있는 컴퓨터가 있을 때,
  • 1,024개 전부 메모리 주소를 표현하는 데 사용하지 않습니다.
  • 512개는 메모리 주소를, 512개는 장치 컨트롤러의 레지스터를 표현하기 위해 사용됩니다.

주소 공간 일부를 아래와 같이 약속했다고 가정해 봅시다.

• 516번지 : 프린터 컨트롤러의 데이터 레지스터
• 517번지 : 프린터 컨트롤러의 상태 레지스터
• 518번지 : 하드 디스크 컨트롤러의 데이터 레지스터
• 519번지 : 하드 디스크 컨트롤러의 상태 레지스터

그렇다면 CPU는 **‘517번지를 읽어라’**라는 명령어로 키보드 상태를 읽을 수 있습니다. 그리고 **‘518번지에 a를 써라’**라는 명령어로 하드 디스크 컨트롤러의 데이터 레지스터로 데이터를 보낼 수 있습니다.

이때 중요한 점은 메모리 맵 입출력 방식에서

• CPU는 메모리의 주소들이나 장치 컨트롤러의 레지스터들이나,
  • 모두 똑같이 메모리 주소를 대하듯 하면 된다는 점입니다.
• 그래서 메모리에 접근하는 명령어와 입출력장치에 접근하는 명령어는 굳이 다를 필요가 없습니다.
• 즉, 메모리 접근 명령어 === 입출력장치 접근명령어

CPU가 **‘517번지를 읽어라’**라는 명령어를 실행했을 때,

• 517번지가 메모리상의 주소를 가리킨다면,
  • CPU는 메모리 517번지에 저장된 정보를 읽어들일 것이고,
• 517번지가 프린터 컨트롤러의 상태 레지스터를 가리킨다면,
  • CPU는 프린터의 상태를 확인할 수 있을 테니까요.

2.1.2 고립형 입출력(isolated I/O)

• 메모리를 위한 주소 공간과 입출력장치를 위한 주소 공간을 분리하는 방법
• e.g. 1,024개의 주소 공간을 가진 컴퓨터가 있다고 가정해봅시다.
  • 제어 버스에 ‘메모리 읽기/쓰기’ 선 이외에 ‘입출력장치 읽기/쓰기’ 선이 따로 있다면,
    • 메모리에도 1,024개의 주소 공간을 활용하고,
    • 입출력장치도 1,024개의 주소 공간을 활용할 수 있습니다.
  • CPU가
    • 메모리 읽기/쓰기 선이 활성화되는 명령어를 실행할 때는 메모리에 접근하고,
    • 입출력장치 읽기/쓰기 선이 활성화되는 명령어를 실행할 때는 장치 컨트롤러에 접근합니다.

고립형 입출력 방식에서 CPU는 입출력장치에 접근하기 위해,

• 메모리에 접근하는 명령어와는 다른 (입출력 읽기/쓰기 선을 활성화시키는) 입출력 명령어를 사용합니다.
• 메모리에 접근하는 명령어와 입출력장치에 접근하는 명령어가
  • 다를 필요가 없었던 메모리 맵 입출력과 대조적이죠?

2.2 인터럽트 기반 입출력

• 4장에서 다음 내용을 배웠습니다.
  • CPU가 입출력장치에 처리할 내용을 명령하면,
  • 입출력장치가 명령어를 수행하는 동안 CPU는 다른 일을 할 수 있다.
• 또 다음 내용도 배웠습니다.
  • 입출력장치가 CPU에게 인터럽트 요청 신호를 보내면,
  • CPU는 하던 일을 잠시 멈추고,
  • 해당 인터럽트를 처리하는 프로그램인 인터럽트 서비스 루틴을 실행한 뒤,
  • 다시 하던 일로 되돌아온다

장치 컨트롤러를 학습했으니, 입출력장치에 의한 하드웨어 인터럽트를 더 정확하고 자세하게 이해할 수 있습니다.

입출력장치에 의한 하드웨어 인터럽트는

• 정확히 말하면, 입출력장치가 아닌 장치 컨트롤러에 의해 발생합니다.
• CPU는 장치 컨트롤러에 입출력 작업을 명령하고,
• 장치 컨트롤러가 입출력장치를 제어하며, 입출력을 수행하는 동안 CPU는 다른 일을 할 수 있지요.

장치 컨트롤러가 입출력 작업을 끝낸 뒤, CPU에게 인터럽트 요청 신호를 보내면,

• CPU는 하던 일을 잠시 백업하고, 인터럽트 서비스 루틴을 실행합니다.
• 이렇게 인터럽트를 기반으로 하는 입출력을 인터럽트 기반 입출력(Interrupt-Driven I/O)이라고 합니다.

💡 폴링(polling)

인터럽트와 자주 비교되는 개념 중 폴링이라는 개념이 있습니다.

• CPU는 주기적으로 장치 컨트롤러의 상태 레지스터를 확인하며,
  • 입출력장치의 상태를 확인한다
• 폴링 : 입출력장치의 상태는 어떤지, 처리할 데이터가 있는지를 주기적으로 확인하는 방식
  • 폴링 방식은 당연하게도 인터럽트 방식보다 CPU의 부담이 더 큼
  • 인터럽트를 활용하면, CPU가 인터럽트 요청을 받을 때까지 온전히 다른 일에 집중할 수 있기 때문

이번에는 조금 더 일반적인 입출력장치가 많을 때를 생각해 봅시다.

• 키보드로 글자를 입력하고 있고,
• 모니터는 실시간으로 입력한 글자들을 띄워주고 있으며,
• 동영상 사이트에서 음악을 재생하니 스피커에서는 음악이 흘러나옵니다.
• 가끔 광고가 나올 때는 건너뛰기 위해 마우스를 움직이기도 합니다.
• 이는 컴퓨터 속 CPU가 동시다발적으로 발생하는
  • 키보드, 마우스, 모니터, 스피커 인터럽트를 모두 처리해야 한다는 말이기도 하죠.
• 이렇게 여러 입출력장치에서 인터럽트가 동시에 발생한 경우에는 인터럽트들을 어떻게 처리해야 할까요?

간단하게 생각하면, 인터럽트가 발생한 순서대로 인터럽트를 처리하는 방법이 있습니다.

• e.g. 인터럽트 A를 처리하는 도중 발생한 또 다른 인터럽트 B의 요청을 받아들이지 않고,
  • 인터럽트 A 서비스 루틴이 끝나면, 그때 비로소 인터럽트 B 서비스 루틴을 실행하는 것이죠.
• CPU가 플래그 레지스터 속 인터럽트 비트를 비활성화한 채, 인터럽트를 처리하는 경우
  • 다른 입출력 장치에 의한 하드웨어 인터럽트를 받아들이지 않기 때문에,
  • CPU는 이렇듯 순차적으로 하드웨어 인터럽트를 처리하게 됩니다.

하지만 현실적으로 모든 인터럽트를 전부 순차적으로만 해결할 수 없습니다.

• 인터럽트 중에서도 더 빨리 처리해야 하는 인터럽트가 있기 때문입니다.
• 즉, CPU는 인터럽트 간에 우선순위를 고려하여,
  • 우선순위가 높은 인터럽트 순으로 여러 인터럽트를 처리할 수 있습니다.
• e.g. 위 그림과 같이 현재 CPU가 인터럽트 A를 처리하는 도중에 또 다른 인터럽트 B가 발생했다고 가정해봅시다.
  • 만약 지금 처리 중인 인터럽트 A보다 B의 우선순위가 낮다면,
    • CPU는 A를 모두 처리한 뒤 B를 처리합니다.
  • 하지만 인터럽트 A보다 B의 우선순위가 높다면,
    • CPU는 A의 실행을 잠시 멈추고, B를 처리한 뒤 다시 A를 처리합니다.

플래그 레지스터 속 인터럽트 비트가 활성화되어 있는 경우,

• 혹은 인터럽트 비트를 비활성화해도 무시할 수 없는 인터럽트인 NMI(Non-Maskable Interrupt)가 발생한 경우
• CPU는 이렇게 우선순위가 높은 인터럽트부터 처리합니다.

우선순위를 반영하여 다중 인터럽트를 처리하는 방법에는 여러 가지가 있지만,

• 많은 컴퓨터에서는 프로그래머블 인터럽트 컨트롤러(PIC; Programmable Interrupt Controller)라는 하드웨어를 사용합니다.
• PIC는 여러 장치 컨트롤러에 연결되어,
  • 장치 컨트롤러에서 보낸 하드웨어 인터럽트 요청들의 우선순위를 판별한 뒤,
  • CPU에 지금 처리해야 할 하드웨어 인터럽트는 무엇인지를 알려주는 장치입니다.

PIC에는 위 그림처럼 여러 핀이 있는데,

• 각 핀에는 CPU에 하드웨어 인터럽트 요청을 보낼 수 있는 약속된 하드웨어가 연결되어 있습니다.
  • 가령 첫 번째 핀은 타이머 인터럽트를 받아들이는 핀,
  • 두 번째 핀은 키보드 인터럽트를 받아들이는 핀… 이런 식으로 말이죠.

PIC에 연결된 장치 컨트롤러들이 동시에 하드웨어 인터럽트 요청을 보내면, PIC는 이들의 우선순위를 판단하여 CPU에 가장 먼저 처리할 인터럽트를 알려줍니다.

PIC의 다중 인터럽트 처리 과정을 조금 더 정확히 알아봅시다.

1. PIC가 장치 컨트롤러에서 인터럽트 요청 신호(들)를 받아들입니다.
2. PIC는 인터럽트 우선순위를 판단한 뒤 CPU에 처리해야 할 인터럽트 요청 신호를 보냅니다.
3. CPU는 PIC에 인터럽트 확인 신호를 보냅니다.
4. PIC는 데이터 버스를 통해 CPU에 인터럽트 벡터를 보냅니다.
5. CPU는 인터럽트 벡터를 통해 인터럽트 요청의 주체를 알게 되고,
   • 해당 장치의 인터럽트 서비스 루틴을 실행합니다

일반적으로 더 많고 복잡한 장치들의 인터럽트를 관리하기 위해

• 위 그림과 같이 PIC를 2개 이상 계층 적으로 구성합니다.
• 이렇게 PIC를 여러 개 사용하면, 훨씬 더 많은 하드웨어 인터럽트를 관리할 수 있겠죠?
• cf. PIC가 무시할 수 없는 인터럽트인 NMI까지 우선순위를 판별하지는 않습니다.
  • NMI는 우선 순위가 가장 높아 우선순위 판별이 불필요하기 때문입니다.
  • PIC가 우선순위를 조정해주는 인터럽트는 인터럽트 비트를 통해 막을 수 있는 하드웨어 인터럽트입니다.

2.3 DMA 입출력

2.3.1 DMA 입출력 등장배경

앞에서 설명한 프로그램 기반 입출력과 인터럽트 기반 입출력에 공통점이 있다면,

• 입출력장치와 메모리 간의 데이터 이동은 CPU가 주도하고,
• 이동하는 데이터도 반드시 CPU를 거친다

e.g. 입출력장치 데이터를 메모리에 저장하는 경우, CPU는

1. 장치 컨트롤러에서 입출력장치 데이터를 하나씩 읽어, 레지스터에 적재하고,
2. 적재한 데이터를 메모리에 저장합니다.

e.g. 메모리 속 데이터를 입출력장치에 내보내는 경우, CPU는

1. 메모리에서 데이터를 하나씩 읽어 레지스터에 적재하고,
2. 적재한 데이터를 하나씩 입출력장치에 내보냅니다.

입출력장치와 메모리 사이에 전송되는 모든 데이터가 반드시 CPU를 거쳐야 한다면,

• 가뜩이나 바쁜 CPU는 입출력장치를 위한 연산 때문에 시간을 뺏기게 됩니다.
• 가령 하드 디스크 백업과 같이 대용량 데이터를 옮길 때는 CPU 부담이 더욱 커지겠죠.
• 그래서 입출력장치와 메모리가 CPU를 거치지 않고도,
  • 상호작용할 수 있는 입출력 방식인 DMA(Direct Memory Access)가 등장하였습니다.
  • DMA는 이름 그대로 직접 메모리에 접근할 수 있는 입출력 기능입니다.
  • DMA 입출력을 하기 위해서는 시스템 버스에 연결된 DMA 컨트롤러라는 하드웨어가 필요합니다.

2.3.2 DMA 입출력 과정

일반적으로 DMA 입출력은 다음과 같이 이루어집니다.

1. CPU는 DMA 컨트롤러에

   • 입출력장치의 주소, 수행할 연산(읽기/쓰기), 읽거나 쓸 메모리의 주소 등과 같은
   • 정보로 입출력 작업을 명령합니다.

2. DMA 컨트롤러는 CPU 대신 장치 컨트롤러와 상호작용하며 입출력 작업을 수행합니다.

   • 이때 DMA 컨트롤러는 필요한 경우 메모리에 직접 접근하여 정보를 읽거나 씁니다.

3. 입출력 작업이 끝나면, DMA 컨트롤러는 CPU에 인터럽트를 걸어 작업이 끝났음을 알립니다.

이번에는 메모리 내의 정보를 하드 디스크에 백업하는 작업이 DMA 입출력으로 어떻게 이루어지는지 알아봅시다.

(1) CPU는 DMA 컨트롤러에

• 하드 디스크 주소, 수행할 연산(쓰기), 백업할 내용이
• 저장된 메모리의 주소 등의 정보와 함께 입출력 작업을 명령합니다.

(2)

1. DMA 컨트롤러는 CPU를 거치지 않고, 메모리와 직접 상호작용하며 백업할 정보를 읽어오고,
2. 이를 하드 디스크의 장치 컨트롤러에 내보냅니다.

(3) 백업이 끝나면 DMA 컨트롤러는 CPU에게 인터럽트를 걸어 작업이 끝났음을 알립니다.

위 입출력 과정을 보면 알 수 있듯, 입출력장치와 메모리 사이에 주고받을 데이터는 CPU를 거치지 않습니다.

• CPU는 DMA 컨트롤러에게 입출력 작업 명령을 내리고,
• 인터럽트만 받으면 되기 때문에 작업 부담을 훨씬 줄일 수 있습니다.
• 다시 말해, CPU는 오로지 입출력의 시작과 끝에만 관여하면 됩니다.

그런데 여기서 생각해 봐야 할 문제가 있습니다.

• DMA 컨트롤러는 시스템 버스로 메모리에 직접 접근이 가능하지만,
• 시스템 버스는 동시 사용이 불가능합니다.
  • 시스템 버스는 공용 자원이기 때문입니다.
• CPU가 시스템 버스를 사용할 때,
  • DMA 컨트롤러는 시스템 버스를 사용할 수 없고,
  • DMA 컨트롤러가 시스템 버스를 사용할 때는, CPU가 시스템 버스를 사용할 수 없습니다.

그래서 DMA 컨트롤러는

• CPU가 시스템 버스를 이용하지 않을 때마다, 조금씩 시스템 버스를 이용하거나,
• CPU가 일시적으로 시스템 버스를 이용하지 않도록 허락을 구하고, 시스템 버스를 집중적으로 이용합니다.
• cf. CPU 입장에서는 마치 버스에 접근하는 주기를 도둑맞는 기분이 들 겁니다.
  • 그래서 이러한 DMA의 시스템 버스 이용을 사이클 스틸링(cycle stealing)이라고 부릅니다.

2.3.3 입출력 버스

마지막으로 DMA 컨트롤러와 장치 컨트롤러의 연결 방식과 입출력 버스에 대해 알아봅시다.

CPU, 메모리, DMA 컨트롤러, 장치 컨트롤러가 모두 같은 버스를 공유하는 구성에서는

• DMA를 위해 한 번 메모리에 접근할 때마다, 시스템 버스를 2번 사용하게 되는 부작용이 있습니다.
• 예시로 들었던 메모리 내 정보를 하드 디스크로 백업하는 상황을 다시 생각해 봅시다.

1. 메모리에서 DMA 컨트롤러로 데이터를 가져오기 위해 시스템 버스를 한 번 사용하고,
2. DMA 컨트롤러의 데이터를 장치 컨트롤러로 옮기기 위해 시스템 버스를 또 한 번 사용합니다.

DMA를 위해 시스템 버스를 너무 자주 사용하면, 그만큼 CPU가 시스템 버스를 이용하지 못합니다.

• 이 문제는 DMA 컨트롤러와 장치 컨트롤러들을
  • 입출력 버스(input/output bus)라는 별도의 버스에 연결하여 해결할 수 있습니다.
• 위 그림과 같이 장치 컨트롤러들이 시스템 버스가 아닌 입출력 버스로 DMA 컨트롤러에 연결된다면,
  • DMA 컨트롤러와 장치 컨트롤러가 서로 데이터를 전송할 때는
  • 시스템 버스를 이용할 필요가 없으므로, 시스템 버스의 사용 빈도를 줄일 수 있습니다.

현대 대부분 컴퓨터에는 입출력 버스가 있습니다.

• 다시 말해, 대부분의 입출력장치(장치 컨트롤러)는 시스템 버스가 아닌 입출력 버스와 연결됩니다.
• 이런 점에서 볼 때, 입출력 버스는 입출력장치를 컴퓨터 내부와 연결짓는 통로라고도 볼 수 있습니다.

입출력 버스에는 PCI(Peripheral Component Interconnect) 버스, PCI Express (PCIe) 버스 등 여러 종류가 있습니다.

• 위 그림은 여러 입출력장치들을 PCIe 버스와 연결해주는 통로인 PCIe 슬롯입니다.
• 여러분이 사용하는 거의 모든 입출력장치들은
  • 이렇게 입출력 버스와 연결되는 통로를 통해 시스템 버스를 타고, CPU와 정보를 주고받습니다.

💡 더욱 발전한 DMA, 입출력 채널

흑백 레이저 프린터 45 ppm | SL-M4530ND | Samsung 대한민국

DMA를 통해 입출력장치와 메모리가 CPU를 거치지 않고, 직접 데이터를 주고받을 수 있게 되었지만,

• 여전히 입출력 명령어를 인출하고, 해석하고, 실행하는 역할은 상당 부분 CPU의 몫이었습니다.
• 그래서 최근에는 메모리에 직접 접근할 뿐만 아니라,
• 입출력 명령어를 직접 인출하고, 해석하고, 실행까지 하는 일종의 입출력 전용 CPU가 만들어졌는데,
  • 이를 입출력 프로세서(IOP; Input/Output Processor)
  • 혹은 입출력 채널(Input/Output Channel)이라고 부릅니다.
• 실제로 일부 최신 입출력장치 내부에는 위 사진처럼 별도의 CPU가 포함되어 있는 걸 볼 수 있습니다.
• 입출력 채널이 있는 컴퓨터에서는 CPU가 입출력 명령어를 실행하지 않습니다.
  • CPU가 입출력 채널에게 메모리에 저장된 특정 입출력 명령어를 수행하라고 지시하면,
  • 입출력 채널은 해당 입출력 명령어를 인출하고, 해석하고, 실행한 뒤,
  • 인터럽트를 통해 결과를 CPU에게 알립니다.