14. I/O Systems

I/O Hardware

운영체제는 일관된 방식으로 I/O 디바이스에게 명령을 내린다. 내부적인 수행은 I/O 디바이스가 알아서 한다.
=> 수많은 종류의 I/O 디바이스를 관리하기 위함.

I/O 디바이스의 컨트롤러는 레지스터를 가지고 있는데, 그 레지스터에 명령을 써주는 것으로 디바이스를 컨트롤 한다.

컨트롤러의 레지스터에 어떻게 값을 써줄까?
메모리의 특정 주소를 I/O 디바이스의 버퍼와 매핑을 한다고 했다.
이 주소에다가 데이터를 써주면 매핑이 되어 디바이스의 버퍼에 들어간다고 했다.
=> Memory Mapped I/O

이것과 별개로 CPU가 I/O 명령을 별도로 가지는 경우도 있다.
I/O 디바이스에 명령을 내릴 땐 이 명령을 사용하도록 주어지는 경우도 있다.

 

I/O 포트는 4가지의 레지스터로 구성되어 있다.

Status Register

: 디바이스의 상태를 나타내는 레지스터이다.

Control Register

: 컨트롤 레지스터에 명령을 써주면 명령이 디바이스로 전달된다.

Data-in Register

: I/O 디바이스가 데이터를 읽어서 OS에 데이터를 전달하기 위해 임시로 저장하는 레지스터

Data-out Register

: 반대로 OS가 I/O 디바이스에 데이터를 Write하기 위해 데이터를 써주는 공간

 

Polling

status register의 값을 보고 busy면 명령을 내리면 안 되고 ready면 명령을 내려야 한다.

명령을 내릴 때 I/O 디바이스의 상태를 체크해야 하는데, 체크하는 방식의 디폴트가 Polling이다.
=> Polling은 Busy waiting을 하는 방식

while loop를 돌면서 I/O 디바이스가 ready 상태가 되기를 기다린다.
=> CPU 자원의 낭비

그러면 쓰면 안 될까? 매우 빠른 I/O 디바이스라면 조금만 기다리면 되니까 Polling도 괜찮은 방법일 수 있다.

 

Interrupt

Polling 방식이 Busy waiting을 하는 방식이라면, Interrupt는 I/O 디바이스가 Ready가 상태가 되면 인터럽트를 보내서 알려주자는 방식이다.

I/O 장치를 기다리지 않고 다른 일을 하고 있을 수 있으므로 효율적일 수 있다.

 

interrupt의 종류에는 2가지가 있다.

Interrupt의 disable 가능 여부에 따라 Nonmaskable, Maskable 인터럽트로 나뉜다.

Nonmaskable : Disable 시킬 수 없는 중요한 인터럽트
Maskable : Disable 시킬 수 있는 인터럽트

 

인터럽트가 왔을 때, 인터럽트 종류에 맞는 핸들러를 호출해야 한다.
해당 인터럽트에 해당하는 핸들러가 메모리의 몇 번지에 있는지 알아야 하는데 그러한 정보를 저장하는 공간이 바로 Interrupt vector이다.

 

A kernel I/O Structure

수많은 I/O 디바이스들을 OS가 어떻게 인지하고 구동시킬까?

더 큰 문제는 현존하는 디바이스는 어떻게든 커널이 인지해서 지원할 수 있다고 치더라도 앞으로 만들어질 새로운 디바이스는 어떻게 OS가 인식을 하게 될까?
과거의 OS가 미래의 디바이스를 지원?

Kernel I/O subsystem까지는 OS가 디폴트로 제공을 하겠다.

각 디바이스를 제어하기 위한 컨트롤러에 구체적인 명령을 내리는 것은 컨트롤러가 지원하는 명령으로 내려야 하는데, 그것은 디바이스를 만든 사람들이 정하는 것이다.

디바이스를 만드는 회사는 그 디바이스를 구동하기 위한 소프트웨어도 같이 만들어서 제공을 해라.

구체적으로 특정 디바이스를 구동하는 소프트웨어인 드라이버는 디바이스 회사에서 알아서 만들어야 한다.

별도로 제공하지 않으면 표준 디바이스 드라이버를 사용해서 구동해도 되는 것으로 알겠다라는 정책

 

Application I/O Interface

애플리케이션은 직접 I/O 디바이스에 접근할 수가 없다.
=> OS에게 대신 요청한다.
그 요청하는 방법이 바로 System call이었다.

요청하는 디바이스의 종류에 따라 다른 시스템 콜을 호출해야 하는 것이 원래지만, 애플리케이션 개발자 입장에서 이 프로그램이 돌아갈 기계에 하드 디스크가 연결되어 있을지 SSD가 연결되어 있을지 알 수 없다.
=> 일반화된 시스템 콜을 제공한다.

일반화된 시스템콜을 호출하면 각 디바이스 마다의 차이는 디바이스 드라이버가 알아서 처리해준다.

 

하지만 명확한 차이가 있을 때는 다른 시스템 콜을 호출해야 한다.

예를 들어 Character-stream과 Block이 있다.

Character-stream 디바이스는 데이터가 블럭 단위가 아닌 stream의 형태로 쭉 흘러가는 디바이스이다.
대표적으로 오디오 카드가 있다. 음악과 같은 데이터는 쭉 흘러간다.
또는 프린트의 경우 출력할 데이터가 쭉 흘러간다.

Character-stream 디바이스와 block 디바이스간의 차이를 I/O systemcall에서 구분해서 제공한다.

사용자에 의해 자발적으로 데이터를 생성하는 디바이스에 대해서는 캐릭터 디바이스를 많이 쓰더라.

 

블럭 디바이스에 대한 접근은 일반적으로 파일 시스템을 통해 접근된다.

캐릭터 디바이스를 위해 제공되는 시스템 콜에는 get, put 등이 있다.

get은 read와 대응되고, put은 write와 대응되는데, 캐릭터 단위로 I/O가 일어난다.

 

Blocking and Nonblocking I/O

Blocking I/O

I/O를 요청하고 I/O가 끝날 때까지 suspend가 된 채로 기다린다

 

Non-blocking I/O

I/O를 요청하고 끝나지 않아도 기다리지 않고 리턴한다.
결과를 받지 않는 것은 아니고, 리턴하는 시점에 진행된 I/O 만큼만 가지고 리턴한다.

 

Asynchronous I/O

프로세스가 I/O를 시켜놓고 결과를 받지 않고 바로 다른 일을 한다.
I/O가 끝났다는 것은 인터럽트를 통해 알 수 있다.

 

Kernel I/O Subsystem

Kernel I/O Subsystem이란 커널이 가지는 I/O를 지원하는 기능들이다

=> I/O의 성능 향상을 위한 기능들이 대부분

 

Scheduling

I/O 요청들을 어느 순서대로 처리할 것인지를 결정

 

Buffering

두 데이터 프로세싱 주체 사이에 데이터를 transfer하는 과정에서 중간 단계로 임시 저장하는 저장 장치.

예를 들어 네트워크 카드와 하드 디스크 사이에 네트워크로 전송되는 데이터를 하드 디스크에 저장하려고 한다고 하자.

네트워크 카드에서 전송하는 데이터의 속도를 하드 디스크가 받아들이지 못 한다.
또한 transfer되는 데이터의 사이즈 사이에도 차이가 발생할 수 있다.
네트워크 카드는 패킷 단위로 전송하고 하드 디스크는 블럭 단위로 전송한다.
=> 데이터 손실이 발생할 수 있기 때문에 중간에 버퍼를 둬서 그 차이를 극복한다.

 

Copy semantics라는 원칙을 지키기 위해서, I/O는 프로세스의 address space의 데이터를 바로 쓰는 것이 아니라
버퍼에 있는 값을 I/O 디바이스에 내리게 된다.
=> 이러한 용도로도 버퍼가 사용된다.

Copy semantics란?

애플리케이션이 어떤 데이터 아이템 A에다가 1을 썼다.
이건 애플리케이션이 가지는 address space내에 A에 해당하는 위치에 1이 써진 것이다. 그리고 그 애플리케이션이 A라는 데이터를 하드 디스크에 써라 라는 명령을 내렸다.

그런데 I/O를 하기 위해서 어떤 일이 벌어지냐면, 지금 당장 하드 디스크의 느린 속도를 감안해서 1 바이트를 쓰기 위해 바로 I/O를 발생시키지 않는다.

중간에 버퍼링을 해서 데이터를 웬만하면 모아서 쓴다.

이 데이터가 하드 디스크로 내려가기 전에 애플리케이션에서 A를 2로 바꿔버렸다면, 실제 I/O가 발생하는 시점에 2를 써야 할까 1을 써야할까?

당연히 I/O 명령이 내려진 시점의 데이터인 1을 쓰는 것이 맞다.
그러면 어떻게 해야 할까? A 값은 이미 1에서 2로 바뀌었는데 어떻게 이전 값을 쓸 수 있을까?
=> 버퍼가 이전 값을 저장하는 용도로 사용된다.
I/O가 발생할 때는 버퍼의 데이터를 하드 디스크에 쓰게 된다.

 

Caching

버퍼와 캐시는 엄연한 차이가 있다.
캐시는 원본 데이터의 똑같은 복사본이고, 버퍼는 어딘가로 가야할 데이터의 원본이다.

 

Spooling

디바이스에 보내는 output data를 중간에 임시로 저장하는 메모리 공간.

output 디바이스가 무척 느려서, 애플리케이션이 이 디바이스로 데이터를 막 보내는데 이 디바이스가 무지 느려서 애플리케이션이 마냥 기다리기엔 성능이 떨어지게 된다.
=> 디바이스로 보낼 데이터를 메모리의 Spool영역에 다 보내면, Spool에 있는 데이터를 디바이스로 보내는 것은 OS 커널의 Spooler가 보내주겠다.

대표적으로 Spooling이 사용되는 경우는 프린트가 있다. 프린트는 출력을 하기 때문에 매우 느린 장치

 

Performance

CPU에 비하면 I/O 디바이스는 매우 느리기 때문에 시스템의 성능에 많은 영향을 미친다.
이러한 느린 속도를 개선하기 위해 다양한 기능들이 제공된다.

I/O 성능 향상을 위 제공되는 인터럽트는 엄청 좋아보이지만, 사실은 소프트웨어적으로 매우 복잡한 매커니즘이다.

인터럽트가 오면 context switch가 발생하고, 그로 인해 context switch 오버헤드가 발생한다.

또한 성능 향상을 위해 I/O를 위해 메모리->메모리로의 copy가 많이 일어난다.
=> 예를 들어 아까 본 Buffering

 

I/O Performance Improvement

I/O 성능 개선을 위한 기능들을 개발할 때 주의해야 할 사항

• 컨텍스트 스위치를 최소화 해야 한다.
• 데이터 카피가 최대한 적게 일어나도록 해야 한다.
• 데이터를 한 번에 많이 가져오든지 해서 인터럽를 최대한 줄여라 => 인터럽트는 오버헤드가 꽤 큰 기능이기 때문

 

여기까지가 Operating System 강의에서 배운 모든 내용들이다.

OS는 거대한 사기술의 집합이라고 했다.

공부하면서 왜 교수님이 OS는 거대한 사기술의 집합이라고 하셨는지 다시 생각해보자.