[OS] 6. I/O Management and Disk Scheduling

본 게시글은 PC버전에 최적화 되어 있습니다.

 

Operating Systems, Internals and Design Principles (9th Ed.), William Stallings, Pearson, 2017

1. I/O Divices

입출력장치는 Controller라는 부분을 가진다.

Controller는 Controller Register, Status Register, Intenal Buffer 로 구성된다.

 

1. Controller Register

장치 드라이버가 0 또는 1 비트를 세팅함으로써 장치에 명령을 내린다.

 

2. Status Register

장치 드라이버가 해당 장치의 현재 상태를 체크한다.

 

3. Internal Buffer

입출력이 임시로 저장되는 공간이다.

 

I/O Management

중요한 것은 이 Controller 부분이 제조사, 장치마다 달라질 수 있다.

그래서 OS가 이러한 모든 종류를 직접적으로 제어하는 것은 불가능하다.

따라서 기준이 되는 Interface를 정의하고 제조사는 기준에 맞게 장치 드라이버를 구현한다.

 

커널 I/O 매니지먼트의 역할은

Device Revervation, Device Scheduling, Error Handling, Buffering, Caching, Spooling

 

Buffering과 Spooling의 차이는

Buffering은 메인 메모리에 파일을 임시로 저장하지만 Spooling은 하드에 파일을 임시로 저장한다.

2. I/O Function

 

Device Driver

직접적인 제어는 장치 드라이버가!

커널 I/O 서브시스템은 장치와 직접적으로 관련되지 않은 제어

 

입출력 제어 방식에는 3가지가 존재한다.

1) Polling

 

Polling

프로그램에 의해 입출력이 진행되고 있는지를 감시하는 방법.

Status, Control, Read, Write의 4개의 레지스터가 존재한다. 

 

Instruction -> 시스템 콜 -> 커널 모드로 전환 -> I/O Management를 통해 장치 드라이버로 명령이 전달

-> 장치 드라이버가 장치를 직접 관리 -> 작업이 끝날때까지 Status를 계속 검사하며 Busy Waiting 상태로 존재

 

원래 I/O가 발생하면 다른 프로세스로 넘어가는게 멀티 프로세싱이었는데

Polling 방법에서는 다른 프로세스로 전환이 일어나지 않는다. -> Busy Waiting

 

결과적으로 입출력이 빠른 경우 polling 방법이 효율적이다.

입출력이 느린 경우 CPU가 계속 해당 프로세스에 할당되어 있으므로 비효율적이다.

 

이를 해결하기 위한 방법이 Interrupt Driven

2) Interrupt Driven

Interrupt Driven

3번까지 과정은 폴링과 같다.

프로세스가 I/O를 요청하면 시스템콜에 의해 커널 모드로 전환이 되고 I/O Management에게 명령을 전달한다.

하지만 이 방법은 입출력 과정에 Process Management를 호출하여 I/O를 요청한 프로세스를 Block 상태로 전환한다.

이후 문맥전환으로 다른 프로세스로 전환하고, 이 과정에서 I/O가 종료되면

IRQ(Interrupt Request)를 실행 중인 프로세스에게 전달하고 Interrupt가 발생해서 커널로 진입하게 된다.

이후 ISR(Interrupt Service Routine)을 통해 Block 상태인 프로세스를 Ready 상태로 바꿔준다.

최종적으로는 프로세스 스케쥴러에 의해 우선순위가 높은 프로세스가 실행된다.

 

I/O가 진행되고 있는 경우에도 다른 프로세스를 실행할 수 있으므로 CPU를 효율적으로 이용할 수 있다.

하지만 장치가 빠른 경우 비효율적. 이도저도 아닌 상태가 되버린다.

3) DMA (Direct Memory Access)

CPU의 효율적인 이용을 위해 I/O 관리를 다른 친구한테 넘기는 방법 (시작과 끝만 관리한다.)

기존 방식은 메모리 -> CPU -> 출력장치, 입력장치 -> CPU -> 메모리 이런 방식이었는데

파일의 크기가 큰 경우 CPU 소모가 크다.

 

이를 해결하기 위해 등장한 새로운 방법.

I/O만을 위한 새로운 CPU(?)를 만들자.

 

DMA Controller

I/O에 관한 사항을 전적으로 맡기므로 CPU 입장에선 부담 덜어내고 개꿀.

DMA에 저장되어 있는 정보는

1. Data Count : 데이터의 개수 (몇 바이트를 작업할거니)

2. Data Register : 데이터의 임시 저장소

3. Address Register : 메모리 어디에 저장되어 있나

4. Controller Logic : I/O가 종료됐을 때 CPU에게 알리기 위한 Interrupt와 Read를 할건지 Write를 할건지

 

특성에 따라 분류

Programmed I/O (Polling) : 메모리 <-> 프로세서 <-> I/O & Interrupt 사용 X

Interrupt Driven : 메모리 <-> 프로세서 <-> I/O & Interrupt 사용

DMA : 메모리 <-> I/O & Interrupt 사용

4. Interrupt

커널에 진입하는 방법은 인터럽트, 트랩, 시스템콜이 있다.

1) Interrupt

 

Interrupt

디바이스가 굉장히 많기 때문에 어떤 장치에서 Interrupt가 발생하는지 CPU에서 모두 관리하기란 어렵다.

중간에 다른 장치를 통해 관리하는데 이것이 PIC (Programmble Interrupt Controller)

 

디바이스 -> PIC -> CPU

PIC에서는 Interrupt의 종류를 판단한다.

CPU는 PIC에서 전달받은 Interrupt 종류에 따라 IDT(Interrupt Descriptor Table)에서

Interrupt에 해당하는 ISR(Interrupt Service Routine)을 실행한다.

 

진행 과정

1. 유저모드인 경우 커널모드로 전환

2. 커널 스택에 저장

3. PIC로 Interrupt의 주체 판단하고 IDT를 통해 ISR 실행

 

Interrupt and Interupt and...

Interrupt 도중에 새로운 Interrupt가 발생하면 이미 커널 내부이므로 Mode Change는 필요없다.

기존에 처리하던 Interrupt는 급한 부분만 처리하고 새로운 Interrupt를 처리한다.

덜 급한 부분은 유저모드로 들어가기 전에 일괄적으로 처리한다.

2) Trap Handling

소프트웨어가 거는 Interrupt, 엄밀히 말하면 CPU가 스스로에게 거는 Interrupt

디바이스가 Interrupt를 발생시키는 것이 아니므로 PIC가 필요없다.

 

종류에는

Div_by_zero

Invalid machine code

Page fault -> 프로그램을 종료하지 않는다.

Segmentation fault

Protection fault

나머지는 프로그램 종료.

3) System Call

 

System Call

프로세스가 커널한테 요청

System Call이 발생하면 Mode Change를 통해 커널 모드로 진입

-> Interrupt Handler -> IDT -> ISR -> SCT(System Call Table)

느낌 자체는 디바이스가 Interrupt하는 것과 동일.

두 개의 테이블을 거치는 이유는 IDT의 공간이 부족하기 때문에.

 

정리하자면 IDT에서 ISR을 생성하고 시스템 콜 테이블에서 이를 다시 처리.