11. I/O Systems

What is I/O system

File system과 마찬가지로 I/O 또한 abstraction을 잘 하는 것이 중요하다.

단순히 음원을 출력하는 것이라도 다양한 I/O 장치에 대한 입출력이 요구되는 것을 확인할 수 있다. User 입장에서 정확한 procedure를 모르더라도 kernel이 잘 관리해주어야 한다는 측면이 존재한다.

이번 챕터에서는 빨간색으로 표시된 I/O와 관련된 것을 다루고자 하는 것. 직접적인 HW access를 통해 I/O access가 되는 상황이다.

여러 I/O 장치를 컨트롤 하기 위해서 I/O bus가 존재한다. 하지만 I/O 별로 속도가 다르다는 문제점이 발생한다.

I/O controller는 interrupt 를 통해 CPU와 소통한다.

나머지 I/O controller는 자기에 해당하는 firmware를 돌리는 것이다.

💡

CPU와 Main memory는 memory bus를 통해 빠르게 정보가 이동하게 됨.

• I/O controller가 정확히 뭐야?

  I/O 컨트롤러는 특정 I/O 장치와 상호 작용하기 위한 하드웨어 구성 요소이며, I/O 장치 제조사가 제공하는 특정 소프트웨어나 펌웨어를 실행합니다. CPU와는 인터럽트를 통해 소통하여 작업을 조정합니다. 이제 더 자세한 과정을 설명해 드리겠습니다:

  1. I/O 컨트롤러는 I/O 장치와의 통신을 관리하기 위해 특정 소프트웨어나 펌웨어를 실행합니다. 이 소프트웨어나 펌웨어는 I/O 제조사에 의해 개발되며, I/O 컨트롤러의 동작을 제어하고 I/O 장치와의 데이터 전송, 제어 신호 전달 등을 담당합니다.

  2. CPU는 I/O 작업을 요청할 때 I/O 컨트롤러에게 명령을 전달합니다. 이를 통해 I/O 컨트롤러는 해당 작업을 시작하고 필요한 데이터 전송이나 I/O 장치의 제어를 수행합니다.

  3. I/O 컨트롤러는 작업이 완료되었거나 추가 작업이 요청되었을 때 CPU에게 알리기 위해 인터럽트를 발생시킵니다. 인터럽트는 CPU의 주의를 끌어 해당 I/O 작업을 처리하도록 합니다.

  4. CPU는 인터럽트를 받으면 현재 수행 중인 작업을 일시 중단하고 해당 인터럽트를 처리하는 인터럽트 서비스 루틴(Interrupt Service Routine, ISR)을 실행합니다. ISR은 I/O 컨트롤러가 보낸 인터럽트를 처리하고, 필요한 작업을 수행하여 I/O 컨트롤러와의 소통을 이어나갑니다.

  5. CPU가 ISR을 실행하면서 I/O 컨트롤러와 통신하여 추가 작업을 수행하거나 작업 완료 상태를 확인합니다. 필요에 따라 CPU는 I/O 컨트롤러에게 추가 명령을 내리거나 I/O 작업의 결과를 가져올 수 있습니다.

  6. 이러한 과정을 통해 CPU와 I/O 컨트롤러는 인터럽트를 통해 상호 작용하며, I/O 작업의 진행 상황을 주고받고 제어합니다.

  요약하면, I/O 컨트롤러는 특정 I/O 장치와 상호 작용하기 위한 하드웨어이며, 해당 장치 제조사가 제공하는 소프트웨어나 펌웨어를 실행합니다. CPU와는 인터럽트를 통해 소통하여 I/O 작업을 조정하고 제어합니다.

• I/O controller는 결국 firmware를 돌리는 것인데, CPU가 안에 있는 것인가?

  I/O 컨트롤러는 하드웨어적인 기능을 수행하기 위해 특정 소프트웨어나 펌웨어를 실행하는데, 이를 위해 내부에 특정 형태의 프로세서 또는 컨트롤 유닛이 포함되어 있습니다. 하지만 I/O 컨트롤러에 내장된 프로세서 또는 컨트롤 유닛은 일반적으로 CPU라고 부르지 않는다. 이에는 몇 가지 이유가 있습니다:

  1. 기능 및 목적의 차이: I/O 컨트롤러에 내장된 프로세서는 일반적인 의미의 CPU와는 목적과 기능이 다릅니다. CPU는 주로 범용 프로세서로서 다양한 작업을 수행하는데 사용되는 반면, I/O 컨트롤러의 내장 프로세서는 주로 특정 I/O 장치와의 상호 작용을 관리하고 제어하는 역할을 합니다.

  2. 아키텍처의 차이: 내장된 프로세서는 전용으로 설계된 아키텍처를 사용하는 경우가 많습니다. 이 아키텍처는 주로 I/O 작업에 특화되어 있으며, CPU의 범용 아키텍처와는 차이가 있을 수 있습니다.

  3. 용어의 혼동 방지: CPU는 일반적으로 중앙 처리 장치를 가리키는 용어로 널리 사용되는 반면, I/O 컨트롤러의 내장 프로세서는 특정한 역할을 수행하는 프로세서를 가리킵니다. 이를 구분하여 사용함으로써 용어의 혼동을 방지할 수 있습니다.

  따라서 일반적으로 I/O 컨트롤러에 내장된 프로세서를 CPU라고 부르지 않고, 특정한 이름이나 용어를 사용하여 그 역할과 기능을 명확히 표현합니다.

I/O Hardware

CPU side

I/O를 handling하기 위해서는 I/O bus와 I/O address가 필요하다.

→ 즉 CPU는 특정 I/O address를 이용하여 I/O bus를 통해 소통하게 된다.

Device side

Hardware controller가 필요함. 각 controller에는 여러가지 buffer와 register가 존재한다.

I/O Architecture

• I/O port : CPU가 특정 I/O와 데이터를 주고 받을 때 필요한 interface (예를 들어 I/O 장치를 세팅하거나 저장되어있는 정보를 읽을 때). CPU는 해당 port를 I/O address 로 인식한다. 또한, 각 port는 I/o controller의 register로 구현되어 있고, CPU는 “in, ins, out, outs”라는 명령어를 통해 access를 하게 된다.

• I/O interface : I/O port에 있는 내용을 이해를 해서 device controller에게 전달하는 역할을 수행하게 됨. I/O port와 device controller사이에 있는 Hardware circuit이다.

  → Act as an interpreter that translates the value in the I/O ports into commands and data for the device.

• I/O controller : 실제 I/O 장치를 hardware적으로 제어하는 component이다.
  • Interprets the high-level commands received from the I/O interface and forces the device to execute specific actions by sending proper sequences of electrical signals to it.
  • Converts and properly interprets the electrical signals received from the device and modifies the value of the status register. (즉 device로 온 정보들을 받아서 status register의 값을 변경하는 역할을 담당하기도 한다.)

💡

즉, controller는 미리 프로그램 된 firmware code를 계속 돌리는 것이다. CPU의 operation과 별개라는 것을 주의해야 한다.

요약하면 다음과 같은 과정으로 진행되게 된다.

1. I/O port를 통해 CPU로부터 정보를 받는다.

2. 해당 정보들은 I/O interface를 통해 interpret되고 high-level command로 변환하여 device controller로 넘기게 된다.

3. 이 정보를 통해 device controller는 실질적으로 해당 device를 control하게 된다. (register의 값을 변경하거나 하는 작업들)

Interact with I/O device

Polled I/O

계속 CPU가 device를 checking하는 것

→ CPU asks (”polls”) devices if need attention

• Pros : Simple implementation

• Cons : Inefficient

Interrupt-driven I/O

표준적인 방법이다. device controller와 CPU는 독립적으로 수행하고 있지만 I/O 장치가 CPU의 도움이 필요할 경우에만 CPU에게 interrupt를 건다. CPU는 interrupt가 들어오면, 하던 일을 멈추고 mode switching을 하고 interrupt handler를 돌리게 된다.

💡

위 작업을 통해 CPU와 I/O가 asynchronous하게 수행을 할 수 있게 되는 것이다.

• Pros : CPU가 계속 체크할 필요가 존재하지 않으므로 효율적이다.

• Cons : Mode switch overhead가 존재한다.

Procedure

정확한 과정은 다음과 같다.

1. 인터럽트가 발생하면 다음과 같은 처리 과정이 일어납니다: 인터럽트 발생: I/O 컨트롤러가 인터럽트를 발생시킵니다. 이는 특별한 하드웨어 신호를 통해 이루어집니다.

2. CPU 반응: 인터럽트가 발생하면, CPU는 현재 수행하고 있는 작업을 일시 중지하고 인터럽트를 처리합니다.

3. 인터럽트 서비스 루틴 실행: CPU는 운영 체제 내부의 특별한 함수인 인터럽트 서비스 루틴 (Interrupt Service Routine, ISR)을 실행합니다. ISR은 발생한 인터럽트의 타입을 확인하고 적절한 처리를 수행합니다.

4. 작업 재개: 인터럽트 처리가 끝나면, CPU는 인터럽트가 발생하기 전에 수행하던 작업을 재개합니다.

Direct Memory Access

이전까지는 storage와 main memory 사이의 데이터 transfer를 CPU가 관장했었다. 따라서 매번 transfer가 발생할 때마다 CPU가 관여했었다.

💡

이 과정에서 CPU cycle을 많이 소비했었다. 또한 I/O operation이 느리기 때문에 CPU의 utilization을 떨어트리는 문제가 발생한다.

이러한 I/O 관련된 CPU의 부담을 줄이기 위해서 등장한 개념이 DMA 라고 불리는 hardware conroller이다. 이 hardware component는 I/O 관련한 작업을 전담해서 빨리 처리하기 위함.

정확한 동작은 다음과 같다.

1. 입출력장치가 CPU에게 입출력 요청

2. CPU가 DMA controller에 명령을 보냄

3. DMA가 CPU에게 시스템 버스 사용 요청

4. CPU가 bus 사용 허가

5. DMA 컨트롤러가 입출력장치에서 데이터 읽은 후 메모리로 전송

6. 전송 완료 후 CPU에게 완료 신호 송신 (by interrupt)

💡

위 과정을 통해 CPU와 독자적으로 data transfer가 진행되게 된다. 즉 data transfer가 진행되는동안 CPU는 다른 일을 수행할 수 있게 된다.

DMA mode

이러한 DMA는 2가지 mode가 존재한다.

• 어떤 기준으로 2가지가 나뉘게 되었는가?

  CPU와 DMA는 memory bus를 결과적으로 공유하게 되는데, 이에 대한 문제를 해결하는 방식에 따라 구분된 것이다.

1. Cycle stealing : CPU가 op code를 decode하거나, execute연산을 수행하는 도중에는 memory bus를 사용하지 않는다. 이러한 상황에서 DMA가 memory bus를 이용하는 것. 즉 CPU가 memory bus를 사용하지 않을 때 조금씩 쓰겠다는 것이다.

2. Burst mode : 아주 많은 양의 data를 처리해야할 때 사용하는 방법으로, CPU가 memory bus를 안쓰게 하고 DMA가 빨리 일을 수행하게끔 하는 것.

   💡

   Bus의 주인을 바꾸는 것도 overhead가 발생하기 때문에, 이러한 측면에서는 cycle stealing보다는 효과적일 수 있다. 하지만 CPU나 다른 device를 오래 막을 수 있다는 점은 단점이 된다.

문제는 CPU와 DMA는 같은 bus를 공유한다는 문제점이 발생한다.

→ data를 load하거나 쓸 때 제외할 때 쓰자 : cycle stealing

→ 한번에 쓰자 : Burst mode

Note

1. DMA controller는 데이터 전송을 위해 출발지 메모리의 physical address와 도착지 메모리의 physical address를 알아야 합니다. 따라서 DMA controller’s address register에는 출발지 데이터의 physical address와 도착지 데이터의 physical address가 각각 저장됩니다. 이를 위해서 운영 체제(OS)가 DMA 컨트롤러의 주소 레지스터에 해당하는 가상 주소를 물리 주소로 변환하여 기록하게 된다.

   💡

   DMA controller’s address register는 DMA 컨트롤러의 내부 레지스터로, DMA 방식으로 이동할 데이터의 물리적인 주소가 저장되어 있습니다. 이 주소는 DMA 컨트롤러가 데이터를 읽거나 쓰는 메모리의 위치를 지정하는데 사용됩니다.

   💡

   이를 위해 Linux의 경우, physical memory의 하위 8MB를 DMA 전용 영역으로 할당해놓음.

2. DMA를 통해 전송될 메모리 영역이 DMA 중에도 메모리에서 페이지 아웃되지 않도록 고정되어야 한다. DMA 작업 도중에 메모리 버퍼가 페이지 아웃되면 데이터 전송이 실패할 수 있다. 따라서 DMA 작업을 수행할 때는 해당 메모리 영역이 메모리에 고정되어 페이지 아웃되지 않도록 유지해야 한다. 이는 DMA 컨트롤러가 데이터를 안전하게 읽고 쓸 수 있도록 보장하기 위함이다.

   💡

   I/O와 관련된 page를 swap-out하지 않도록 해야한다는 측면과 관련이 되어있는 내용이다.

I/O Hardware Access

I/O port에 대한 address를 I/O 전용 address를 사용할 것인지, 아니면 기존의 메모리처럼 virtual address를 사용할 것인지에 따라 구분되게 된다.

💡

후자의 경우, virtual address에서 특정 범위는 I/O 장치와 매핑되어있다. 따라서 CPU는 메모리와 동일한 방식으로 I/O 장치와 데이터를 주고받을 수 있다. 이를 통해 주소 공간을 통합하여 편리한 접근을 제공하게 된다.

Direct I/O

특정 I/O device가 address를 가지고 있고, 해당 address를 통해 access하는 방식. 이를 위한 전용 명령어가 존재하는 것이다. Intel의 경우 “in, ins, out, outs” 명령어가 있다.

💡

정확하게는 I/O port를 address로 할당하는 것이다.

Memory mapped

I/O 관련된 address를 virtual memory의 일부분으로 사용하겠다는 개념이다. 즉 I/O port가 address가 virtual memory의 일부가 되는 것이다.

💡

기존의 Direct I/O 방식의 경우, kernel이 특정 I/O에 대한 port address를 알고 있고 특정 address를 사용해야하는데, Memory mapped I/O는 kernel은 기존 memory access와 동일한 interface로 I/O를 접근할 수 있게 된다.

가상 메모리는 페이지 단위로 관리되며, 여러 프로세스가 동일한 페이지에 액세스할 수 있습니다. 이는 여러 프로세스가 동일한 I/O 장치의 레지스터나 상태에 접근할 수 있다는 것을 의미합니다.

동일한 페이지를 동시에 공유하는 경우, 가상 메모리의 보호 메커니즘을 통해 해당 페이지의 액세스를 조절할 수 있습니다. 운영 체제는 페이지 테이블과 같은 메커니즘을 사용하여 프로세스 간의 페이지 공유와 액세스를 관리하며, 이를 통해 동시에 발생할 수 있는 문제를 방지하고 보호할 수 있습니다.

💡

즉 추가적인 protection algorithm이 필요가 없다. 애초에 동일한 page를 여러 process가 공유하는 상황에 대해 protection algorithm이 존재하기 때문에 해당 내용을 그대로 사용해주면 된다.

I/O Software

존재하는 I/O device는 다양함에도 불구하고 어떻게 kernel은 user로 하여금 이러한 특성을 숨기면서 동일한 interface를 제공할까?

💡

I/O software는 다양한 입출력 장치와 응용 프로그램 간의 인터페이스 역할을 수행하며, 사용자에게 동일한 인터페이스를 제공하여 입출력 작업을 쉽게 접근하고 제어할 수 있게끔 합니다. 이를 통해 사용자는 다양한 종류의 입출력 장치를 통일된 방식으로 액세스할 수 있고, 입출력 작업을 간편하게 처리할 수 있습니다.

Goal of I/O software

1. Device independence : 즉 어떤 device를 사용하든 동일한 interface를 제공해야한다는 것

2. Uniform naming : device의 이름을 다루는 방법이 일반적으로 존재해야 한다.

3. Effective error handling : 에러가 났을 때 일관적인 handling을 해주어야 한다.

4. Performance : I/O 작업을 효율적으로 처리할 수 있게끔해야 한다.

   → buffering이나 caching을 통해 속도를 올리는 것이 목표

• Device Driver와 firmware와의 차이가 무엇인가?

  디바이스 드라이버(Device driver)는 운영 체제와 하드웨어 간의 통신을 관리하는 소프트웨어 모듈입니다. 디바이스 드라이버는 특정 주변장치와 컴퓨터 시스템 간의 인터페이스 역할을 하며, 주변장치의 동작을 제어하고 데이터를 주고받을 수 있도록 합니다. 디바이스 드라이버는 운영 체제에서 제공되는 소프트웨어로 개발되며, 특정 하드웨어와 호환되도록 설계되어야 합니다.

  반면에 펌웨어는 하드웨어 장치나 시스템의 특정 기능을 제어하기 위해 하드웨어에 내장된 소프트웨어입니다. 펌웨어는 하드웨어에 미리 프로그래밍되어 있으며, 하드웨어의 동작 방식과 기능을 정의하고 제어하는 역할을 합니다. 펌웨어는 주로 하드웨어 제조사에 의해 개발되며, 하드웨어 장치에 내장되어 출하됩니다.

  디바이스 드라이버는 운영 체제와 하드웨어 간의 인터페이스를 관리하고 특정 주변장치의 동작을 제어하는 역할을 수행합니다. 디바이스 드라이버는 운영 체제에서 제공되는 소프트웨어 모듈로, 일반적으로 운영 체제 개발자 또는 주변장치 개발자가 개발합니다. 반면에 펌웨어는 하드웨어 제조사에 의해 개발되며, 하드웨어 장치에 내장된 소프트웨어로서 동작합니다.

  요약하면, 디바이스 드라이버는 운영 체제와 하드웨어 간의 통신을 관리하는 소프트웨어 모듈로서 운영 체제 또는 주변장치 개발자에 의해 개발됩니다. 펌웨어는 하드웨어 장치에 내장된 소프트웨어로서 하드웨어 제조사에 의해 개발되며, 해당 장치의 동작을 제어하고 데이터를 처리하는 역할을 수행합니다.

• Device Driver / Device-independent I/o software와 VFS와의 관계는 무엇인가?

  Device driver와 device independent I/O software의 도움을 받아 Virtual File System (VFS)는 I/O access를 기존의 memory access와 유사한 방식으로 수행할 수 있도록 지원합니다.

  Device driver는 운영 체제의 I/O 스택 내에서 주변장치와의 상호작용을 관리하고, 해당 주변장치에 대한 접근을 제공합니다. Device independent I/O software는 이러한 Device driver와 함께 동작하여 I/O 작업을 추상화하고, 응용 프로그램이 특정 주변장치에 종속되지 않고 일관된 방식으로 I/O access를 수행할 수 있도록 합니다.

  VFS는 이러한 Device driver와 device independent I/O software를 활용하여 다양한 파일 시스템에 대한 접근을 제공합니다. VFS는 파일 시스템에 대한 추상화 계층으로서, 응용 프로그램이 특정 파일 시스템에 종속되지 않고 일관된 방식으로 파일 및 디렉터리에 접근할 수 있게 합니다.

사용자입장에서는 User level의 I/O software를 통해서 I/O를 request하고 정보를 받게 됨. 기본적으로 user는 kernel의 기능을 모르지만, 동일한 system call interface를 통해 I/O 작업을 수행하게 된다.

Revisit the goal of VFS (Virtual File system)

1. 다양한 파일 시스템 지원: VFS는 다양한 파일 시스템을 추상화하여 응용 프로그램이 특정 파일 시스템에 종속되지 않고 일관된 방식으로 파일 및 디렉터리에 접근할 수 있도록 지원합니다. 이를 통해 다양한 파일 시스템을 동일한 인터페이스로 지원할 수 있습니다.

2. 다양한 I/O 장치 지원: VFS는 다양한 I/O 장치를 추상화하여 응용 프로그램이 특정 장치에 종속되지 않고 일관된 방식으로 I/O 작업을 수행할 수 있도록 지원합니다. 이를 통해 다양한 I/O 장치를 동일한 인터페이스로 지원할 수 있습니다.

결과적으로 VFS는 파일 시스템과 I/O 장치에 대한 다양한 종속성을 추상화하고, 응용 프로그램이 동일한 인터페이스를 통해 이러한 기능을 활용할 수 있도록 합니다. 이를 통해 응용 프로그램은 파일 시스템 및 I/O 장치의 변화에 유연하게 대응할 수 있으며, 다양한 환경에서 일관된 방식으로 작업을 수행할 수 있습니다.

Interrupt Handlers

I/O에서 발생하는 interrupt를 CPU에게 알려주기 위해서는 추가적인 하드웨어가 필요한데, 이를 interrupt controller 라고 한다.

해당 장치는 여러 I/O port부터 온 interrupt를 모아서 CPU에 전달해주게 된다.

• Interrupt controller란 정확히 무엇인가?

  Interrupt Controller는 다수의 I/O 장치로부터 발생하는 Interrupt를 관리하고 우선순위를 결정합니다. Interrupt Controller는 CPU에게 신호를 보내어 해당 Interrupt에 대한 처리를 알립니다.

  Interrupt Controller는 여러 개의 Interrupt를 받아들여 중재하고, 우선순위에 따라 CPU에게 Interrupt를 전달합니다. 이를 통해 CPU는 Interrupt에 대한 처리 우선순위를 판단하고, 해당 Interrupt에 대한 처리 루틴을 수행합니다.

추가적으로 Device마다 처리해야하는 interrupt의 내용이 달라지게 되는데, 따라서 interrupt handler가 device driver를 호출하게 된다. 이를 통해 각자 다른 device에 대한 Interrupt를 적절하게 처리할 수 있게 된다.

Device Drivers

이거는 kernel code

특정 I/O 장치에 depend하는 I/O 장치를 control하기 위한 code이다. 즉 Device driver는 'device independent I/O software'와 'interrupt handlers'와 상호작용하여 I/O 장치를 효과적으로 제어한다.

→ 즉 다시 말해서 kernel이 알아야할 정보이다. 해당 device가 OS와 어떤 방식으로 상호작용할지에 대한 정보들을 담고있다고 생각해주면 된다. (firmware는 자체적으로 해당 hardware를 구동시키기 위해서 알아야할 정보만을 담고있다.)

💡

일반적으로 I/O 장치를 만드는 회사가 device driver를 제공한다.

이때 interface가 다르게 되면 계속해서 kernel code가 바뀌어야하는 문제가 발생하게 된다.

→ VFS처럼 표준적인 형태를 제공하고, 이 형태를 device drivers가 지키게끔 강제시킴으로써 일관되게 처리할 수 있게끔한다.

• firmware와의 차이는 무엇인가?

  Firmware는 하드웨어 장치 자체를 제어하고 설정하는 프로그램이며, 디바이스 드라이버는 운영 체제와 하드웨어 사이의 인터페이스 역할을 하며, 해당 장치와 관련된 작업들을 처리합니다.

Device Independent I/O software

다른 I/O여도, 동일한 interface를 제공하려고 하는 것

UNIX의 경우 device 또한 file처럼 모델링 된다.

→ open, read, write, close 형태로 접근할 수 있다.

💡

즉, user입장에서는 memory access와 I/O access를 구분하지 않아도 된다.

• major device number : 어떤 device driver를 사용할 것인지에 대한 정보를 담고 있음
  • 커널 내에서 해당 디바이스 드라이버를 식별하는 데 사용됩니다.
  • 각 디바이스 드라이버는 고유한 Major device number를 가지고 있으며, 이 번호를 통해 커널이 해당 드라이버를 식별합니다.

  💡

  즉, major device number를 통해 device driver를 특정함으로써 어떤 로직으로 해당 디바이스의 I/O와 interrupt를 처리해야할 지 알 수 있게 된다.

• minor device number
  • Minor device number는 해당 디바이스 드라이버 내에서 특정 디바이스를 구분하는 데 사용됩니다.
  • Major device number와 결합하여 고유한 디바이스를 식별하는 데 사용됩니다.
  • 예를 들어, 하나의 디바이스 드라이버가 여러 개의 디바이스를 지원할 때, Minor device number는 각 디바이스를 개별적으로 구분하는 데 사용됩니다.

Buffering : 성능에 대한 issue

(a) Unbuffered (b) Buffered in user space (c) Buffered in the kernel space (d) Double buffering in the kernel

💡

느린 장치로부터 데이터를 모았다가 한번에 처리할 수 있게끔하는 것. 느린 device와 빠른 device 사이의 속도차이로 인한 성능 저하를 막고자 하는 것

Error reporting

다양한 device가 발생하는 error를 표준화시키려고 하는 것. (하지만 많은 에러들은 device specific하므로 이 또한 device driver의 도움을 받아야 한다.)

Device-independent block size

파일 시스템에서는 I/O access나 memory access 모두 동일한 블록 크기를 사용하여 데이터에 접근합니다. 따라서 I/O 작업이나 파일의 저장과 관리에 있어서 동일한 블록 크기를 사용하고 처리합니다.

이를 통해 파일 시스템은 일관된 방식으로 데이터를 처리하며, 블록 크기를 기준으로 파일을 조각내어 저장하고 관리합니다. I/O access나 memory access 모두 동일한 블록 크기를 사용함으로써 일관성을 유지하고, 파일 시스템의 성능과 효율성을 향상시킵니다.

User-Space I/O Software

library로부터 동일한 형태의 interface만을 가지고 접근할 수 있게 된다.

Spooling

Spooling은 "Simultaneous Peripheral Operations On-Line"의 약자로, 입출력 장치와 컴퓨터 사이에서 작업을 조정하는 기술이나 방식을 의미합니다. Spooling은 주로 입출력 장치와 컴퓨터 간의 속도 차이로 인해 발생하는 시간 지연을 줄이고, 시스템의 효율성과 처리량을 향상시키기 위해 사용됩니다.

일반적으로 컴퓨터에서 프린터와 같은 입출력 장치는 한 번에 하나의 작업만 처리할 수 있습니다. 그러나 Spooling은 입출력 작업을 큐(Queue)에 저장하고, 작업이 진행되는 동안 다른 작업을 처리할 수 있도록 합니다. 이를 통해 입출력 작업과 컴퓨터의 작업이 병렬적으로 수행될 수 있으며, 작업간의 시간 지연을 최소화할 수 있습니다.

일반적으로 Spooling은 다음과 같은 방식으로 동작합니다:

1. 입출력 작업을 요청하는 프로세스는 작업을 Spooler라는 프로그램에 전달합니다.

2. Spooler는 작업을 큐에 저장하고, 다른 작업과 병렬로 처리될 수 있도록 스케줄링합니다.

3. 입출력 장치는 큐에 있는 작업을 차례대로 처리하며, 결과를 다시 Spooler에 전달합니다.

4. Spooler는 처리된 결과를 원래 요청한 프로세스에게 돌려줍니다.

Improving I/O Performance

I/O가 결국 느리기 때문에 system performance의 bottleneck이 된다.

1. Mode switch가 요구됨

2. Data copy가 많이 요구됨

3. Network traffic은 일반적으로 많이 들어오게 됨

따라서 성능 관리를 굉장히 잘해야 한다.

Guideline

1. mode switch의 수를 줄일 것

2. Data copy를 줄일 것 (한번에 copy할 때 큰 양을 copy할 것)

3. DMA를 쓸 것

→ 어쨌든 CPU와 memory, bus, I/O의 performance를 throughput이 최대가 되게끔 balancing해야한다.

Case Study : Linux Device Driver

I/O file도 그냥 file로 취급한다. 즉 storage에 있는 file를 access하는 것처럼 사용할 수 있다.

💡

Unix에서의 device는 file 로 취급한다.

I/O 장치에 대해서도 메모리처럼 open 명령어를 수행해주면 된다. 따라서 I/O device driver도 VFS의 함수로 존재하는 것.

즉 I/O device가 그냥 virtual file system의 component처럼 구현을 하는 것.

💡

기본적으로 Linux는 memory mapped I/O가 아니다. memory mapped I/O의 경우에는 I/O address를 일종의 virtual address의 일부분에 할당한 것이다. 예를 들어 I/O access를 하고 싶은 경우에는 memory access 명령어(load, store)를 수행함으로써 I/O access를 할 수 있다. 실제로 I/O access에 대한 방법론 자체는 device driver가 알고 있는 상황이고, 해당 virtual address에 대응되는 device driver도 알고 있는 상황이므로 크게 문제가 없다.