[OS] Chap12. I/O Systems

해당 글은
경희대학교 조진성, 허선영 교수님의 강의 자료 및 내용을 정리한 글입니다
개인적으로 공부하며 작성된 글이라 잘못된 부분이 있을 수 있습니다!
오류가 있다면 알려주세요

 

 

von Neumann 구조에서는

CPU, Memory가 존재하고, 이와 연결된 I/O device가 존재한다.

 

I/O device가 system으로 신호를 보내서 커뮤니케이팅을 하는 과정에서 사용되는 몇 가지 용어부터 정리하자.

Port : device의 connection point

Bus : PCI, Expansion bus, Serial-Attached SCSI(SAS)

Controller : port, bus, device 등을 작동시키는 Host adapter

 

Device들은 device driver가 명령을 배치하거나 data를 기록하기 위한 Special registers을 가진다.

device driver는 device controller(device에 붙어있는 하드웨어임)에 있는 register에 접근하여, 데이터를 주고받게 된다.

해당 register는 CPU 내에 있는 것이 아니라, 데이터를 주고 받기 위한 용도로 사용된다.

ex) Data-in register, data-out register, status register, control register

 

이때 Devices는 각자의 address를 가지고 controller와 커뮤니케이션 한다.

방식1) Direct I/O instructions

I/O device가 Bus를 통해서 각각의 Port로 연결되며, port address를 사용하여 연결함

 

방식2) Memory-mapped I/O

Processor의 address space에 사용하는 page들이 존재하는데, 

이와 같은 방식처럼 특정 메모리 공간에 I/O address를 두고 데이터를 읽거나 쓰는 방식이다.

따라서 직접 접근할 필요 없이, 메모리를 접근하는 것처럼 디바이스에 접근할 수 있다는 장점이 있다.

이때 해당 공간이 실제로 메모리가 할당된 공간이라는 것을 의미하는 것은 아니다. 

 

 

I/O device와 커뮤니케이션 하는 2가지 형식을 알아보자

 

 

 

Polling

Interrup 방식의 경우, 요청한 이후에 다른 작업을 수행하다가 작업이 완료되면 알림을 받는다.

Polling은 이와 다르게 데이터가 있는지/없는지를 계속해서 확인하는 방식이다.

 

과정

- Status register에서 Busy bit의 값을 읽고, 이것이 0이 될 때까지 기다린다. (Polling / Busy Waiting)

- Busy bit가 0일 경우 데이터를 읽고 쓸 수 있는 상태가 된 것이다

- Read/Write를 통해서 data-in / data-out register에 접근한다.

 

 

 

Interrupt

CPU가 Process의 instruction을 실행하는 과정에서 매번 Interrupt-request line을 check한다. (Interrupt 발생? 안 발생?)

 

Interrput-request line의 종류

• Nonmaskable interrupt : 해결할 수 없는 메모리 error 발생
• Maskable interrupt : service를 요청하기 위한 device controller의 일반적인 동작

 

전기적인 interrupt 신호가 발생한다면, CPU는 원래 진행하던 instruction을 중단.

Memory에 fixed address에 존재하는 Interrupt handler routine으로 Jump

 

이때 Interrupt handler routine을 Dispatch하기 위해서 사용하는 것이 Interrupt Vector이다.

Boot time에 운영체제는 interrupt handlers, 즉 kernel을 향하는 address를 vector 내에 세팅한다.

해당 vector가 관리할 수 있는 개수는 한정되어 있으므로, 같은 vector num에 다른 device를 사용할 수 있게끔하는 Interrput Chaining 방식도 활용된다.

 

Excaptions 또한 interrupt 처리의 메커니즘을 따릅니다.

memery access error는 Page Fault를 발생시키며, 해당하는 interrupt handler가 swipping 등을 처리한다.

System call는 Trap을 통해 request를 실행할 kernel을 trigger한다.

 

Multi-CPU system은 이러한 process의 interrupt를 concurrently하게 처리할 수 있는 것이고,

Time-sensitive한 시스템이라면 interrupt를 사용합니다.

 

 

 

 

Direct Memory Access

Memory 접근할 때 CPU가 관여하지 않는다! 그 시간에 다른 유용한 작업을 진행하고,

I/O device와 memory가 바로 데이터를 주고 받습니다.

 

DMA controller가 필요하며

주로 많은 데이터가 이동해야하는 경우 Transfer 시간을 줄이기 위해서 활용하는 방식입니다.

 

 

 

 

Kernel I/O Structure

 

Device Driver는 각자 다른 I/O controller의 특성을 Kernel이 알지못하도록, 일반화 합니다.

 

▶Block and Character Devices

Disk Devices

• Block Drive를 포함
• read(), write(), seek() 등의 명령어
• Raw I/O, Direct I/O, file-system access
• Memory-mapped file access

OS의 File system interface를 통해서 디스크에 접근하게 될 경우,

해당 File을 Buffering하여 이후에 접근할 때 더 빠를 수 있도록 한다.

 

Raw I/O, Direct I/O 의 경우 OS 관여 없이, DB를 직접 관리해야하는 경우에 좋은 성능을 유지하기 위해 해당 방식을 사용

 

 

Character Devices

• keyboards, mice, serial ports
• get(), put()
• Libraries layered

 

 

▶Clocks and Timers

CPU 동작을 할 때 Clock에 맞추어서 동작하게 된다.

instruction이 하나 실행할 때 = Clock 1 Cycle 과 같이 맞추어서 동작하게 된다.

 

Programmable interval timer: timer의 count value가 올리고, 일정 지점을 넘어가면 interrupt 발생

 

 

 

Nonblocking and Asynchronous I/O

• Blocking: Process는 요청 이후에 I/O device의 처리가 끝날 때까지 기다림
• Nonblocking: I/O 처리에 따른 데이터를 기다리지 않는다. 있다면 받고, 없다면 받지 않는다. (예: 키보드, 마우스)
• Asynchronous: I/O 데이터를 기다리지 않고, 다른 일을 수행하다가 처리가 완료되면 신호를 받는다.

 

 

 

I/O Request Life Cycle

 

System call Process

User process, System cal을 통해 I/O request를 보냄

→ System call로 인해 Kernel에서 interrupt trap 발생

→ Interrupt(System call) handling 

→ 해당 요청이 바로 처리 가능한 상태인지 확인

→ 가능 = Kernel이 file을 미리 buffering(cache)을 해둠, 디바이스까지 가지 않고 데이터 전달 가능

    불가능 = Device에 요청해야함 

→ Device driver에게 request 전달

→ Device controller에게 전달

→ Controller에서 요청받은 데이터를 처리해서 돌려줌

→ Kernel로 돌아옴. CPU에게 Interrupt 발생시켜 System call result를 돌려줌

 

 

 

 

챕터 12 끝 ~