Revisited: Computer System Operation

I/O request via I/O instruction

: cpu가 io장치에게 명령을 내리는 방식 Direct I/O vs. Memory-mapped I/O 두개가 있다.

cpu가 io명령을 내린다 수행한다는 것은 io 컨트롤러에게 명령을 전달한다는 것이고 특정 데이터도 같이 전달을 해주어야 명령을 수행 할 수 있는 경우도 있다. 이 io 컨트롤러에는 일반적으로 cpu에서 io 자치에게 내리는 명령어가 있고, 그 명령어를 받아와서 저장할 수 있는 ir 이 존재. 또한 데이터를 저장하는 데이터 레지스터가 존재하는 경우가 일반적이다.

• Communicates with registers in I/O controller
  → io 컨트롤러가 없다면 os가 다 처리를 해야하는데 그 사이에 io 컨트롤러가 대리해서 처리를 해준다.

• IR (Instruction Register) & DR (Data Register)
  io 컨트롤러에는 명령어를 가지고 오고 읽고 쓰는
  

I/O method

: io 디바이스가 명령을 수행하는 방식

• Programmed I/O
  • io장치에서 처리한 결과를 cpu 레지스터에 직접적으로 전달하는 방식, io의 결과의 양이 적은 경우, 키보다나 마우스처럼.
  • 키보드 마우스 입출력과 같은 단순한 작은 일들을 바로바로 처리할 때 사용
  • 많은 양의 데이터를 처리해야하는 일이 발생하면… cpu가 io때문에 다른 일을 못하기 때문에
• DMA
  • cpu를 거치지 않고 데이터를 처리
  • 디스크에서 많은 양의 데이터를 디스크에서 메모리로 올릴 때
• Interrupt
  • io장치가 처리를 다 했을 때 명령을 내린 주체인 cpu에게 알려주는 것

1. Polling
2. Interrupt
   : io 디바이스가 cpu에게 시그널을 보내서 cpu가 다 한일에 대해서 후처리를 한다

Direct I/O

메모리랑 io디바이스 영역을 분리를 한다. 메모리에서 데이터를 읽고 쓰는 명령어와 io장치에서 쓰고 읽는 명령어가 다르다

• 장점 : 분리되어 있으니 두가지 동작이 완전히 isolation 가능하다.

• 단점 : cpu 입장에서는 데이터를 쓰고 읽는 것이 같은데 상이한 명령어로 구성을 해야하니 하드웨어 설계가 어려워지고 cpu에 있는 pin수가 늘어난다.

• intel 에서 사용

• io device와 관련된 input/output instruction set을 따로 만듬 → hardware set을 따로 만들어야 함을 뜻함

• 정의되어 있는 io디바이스마자 주소가 존재하고, 어느 특정 주소는 메모리에 디스크에 쓴는 등 구분을 지어서 써야하는데 이것이 모두 하드웨어 로직으로 정해져 있다.

• RISC → ARM
  : 메모리에 데이터를 읽고 쓰는 것 하나로 씀

• 메모리에 특정 주소를 외부 아이오 디바이스 주소에 매핑을 해두고 사용?

• 인스트록션 셋의 개수가 줄어드니 더 효율

Memory-Mapped I/O

메모리의 특정 영역은 io 컨트롤러의 명령을 쓰는 것과 mapping을 시킨다.

메모리의 일부분을 io 컨트롤러에게 전달을 하거나 io컴트로러부터 받아오는 어떤 데이터들을 읽는 전용의 메모리 공간으로 mapping을 시켜 사용한다.

• 장점: cpu pin 수가 줄어들고 cpu 구성이 단순화 된다.
• arm에서 사용

A Typical PC Bus Structure

Device Controller

• 실제로 디바이스를 컨트롤하는 역할을 하드웨어적으로 구현을 해서 동작을 시킨다.

I/O Performance of Storage and Network Latency

---

위에까진 io HW에 대한 정리 지금부터는 io SW에 대한 정리

Kernel I/O Structure

• io 장치마다 device controller가 붙어 있다.
• 각 컨트롤러에 대응하는 드라이버가 하나씩 존재, 드라이버는 디바이스 컨트롤러를 소프트웨어적으로 하드웨어를 제어하기 위해 존재한다.
• 드라이버는 운영체제 밑에 커널에 붙어서 연결해주는 역할을 하고, 실제 디바이스의 성능을 100%로 끌어올리기 위해서
• kernel io subsystem : 드라이버는 특정 하드웨어에 dependent한 것들을 다루는 소프트웨어이고 이것들(드라이버, 디바이스 컨트롤러, 디바이스)을 다 아울러서 genenral한 처리를 해주는 것이 kernel io subsystem이다. 드라이버의 공통적인 부분들을 표준화 해서 만든 것이다.

Life Cycle of An I/O Request

• 시스템 콜을 통해 커널에게 io를 요청

• kernel io subsystem이 먼저 확인을 한다. 얘가 봤을 때 버퍼, 캐시에 요청한 io에 대한 자료가 있어 처리를 바로 할 수 있다면 실제 device driver, interrupt, device controller로 내려가지 않고 system call에 요청 결과를 바로 알려준다.

• 버퍼 캐시가 없으면 커널 아이오 서브 시스템이 일반적인 것을 처리하고 디바이스 드라이버로 디바이스 컨트롤러에 전달해주어야 하는 명령을 전달한다. 디바이스 컨트롤러는 여러것들을 처리를 하고 디바이스 컨트롤러에게 넘겨준다.

• 그러면 디바이스 컨트롤러는 실제 io를 수행을 하고 수행이 종료되면 io 디바이스가 인터럽트를 걸고 그러면 인터럽트 핸들러가 동작을 하고 인터럽트 핸들러가 디바이스에게 그 동작을 전달해준다.

• 유저 어플리케이션에게 그 io 수행한 결과를 시스템 콜에 대한 응답으로 전달 한다.

Intercomputer Communications

• 사용자가 키보드로 무언가를 입력
  

Device-Functionality Progression

• io 시스템이 다 갖춰져 있는 상태에서 뭔가 새로운 기을을 추가하려고 하는 상황에 어디다가 구현을 하는 것이 좋을까.

• 아래로 가면 갈수록 하드웨어로 구현이 된다. 이렇게 되면 구현이 완료되었을 때 효율이 좋다. 빠르다. 소프트웨어보다 하드웨어가 동작속도가 빠르니끼. 효율은 좋아지지만 개발기간이 늘어나고 비싸진다. 하지만 abstraction이 좋아진다. 운영체제가 하드웨어가 어떻게 동작하는지 몰라도 알아서 잘 되게 해주니까.

• 유연성이 떨어진다. 새로운 알고리즘이 들어오면 다음세대의 물리적인 하드웨어를 새롭게 만들어야 한다.

• 반면 윗단으로 갈 수록 유연성이 좋아진다. 더 위로 가면 갈수록 flexibility가 높아진다. 디바이스 code같은 경우 하드웨어 dependency가 아주 높다. application code는 밑에가 abstraction이 잘 되어 있으니 변경을 하기 아주 쉬울 것이다.

Goals of I/O Software

• Device independence

• Uniform naming
  : 통합해서 처리, 코드 재사용성
  

• Error handling
  : 오류의 후처리
  

• Synchronous vs. asynchronous
  : 둘 중에 어떤 것으로 동작시킬것이냐
  

• Buffering
  : 성능을높이기 위해 버퍼링 혹은 캐싱
  

• Sharable vs. dedicated devices
  : io 디바이스를 공유할 수 있도록 할건지 나만 쓸 수 있도록 할 것인지
  

I/O Software Layers

Device-Independent I/O Software

Uniform interfacing for device drivers

→ kernel io subsystem 을 이야기하는 것

Buffering
: 버퍼에 데이터를 임시로 저장하는 행위

1. Unbuffered
   버퍼를 상용하지 않는 것
2. Buffered in user space
   유저 프로세스에 버퍼링을 하는 것.
3. Buffered in the kernel space
   커널에 하는 것
4. Double buffering in the kernel
   커널에 이중으로 하는 것
   • 캐시 hit ratio도 높아지겠지만 커널의 메모리를 많이 써야 한다.

→ 3,4 캐싱에서 이점도 있고 빠르고 좋다. 그래서 요 두가지를 많이 사용

Error reporting

io device에 protection측면에서훨씬 더 시스템을 안정할 수음

io software단에서 에러 리포팅 관련된 것들은 cpu dependency가 높다.

• ARQ : 재전송 알고리즘
• 에러를 무시
• 메모리에서 이상한 짓하면 프로세스 죽여버림

Allocating and releasing dedicated devices

Device-independent block size

User-Space I/O Software

Spooling
버퍼링이랑 비슷한데 application이 io장치에 데이터를 쓰려면 커널한테 시스템 calll을 요청하고 쓸 데이터를 커널한테도 쓴다. 커널이 버퍼에 쓸 내용들을 저장하고 그 내용을 아이오 장치에 전달을 한다. 만약 아이오가 엄청나게 느리면.. 커널의 버퍼링 사이즈가 계속 커져서 메모리 사이즈를 계속 잡아먹게 된다.

• 그래서 어플리케이션에서 커널을 통해서 메모리를 버퍼링하는 것이 아니라 어플리케이션에서 file로 버퍼링을 한다.
• 버퍼링이랑 비슷한데 메모리에 하냐 file에 하냐의 차이다

I/O Systems Layers

• user process에서 io에 대한 권한이 없으니 커널에 요청을 하고 시스템 콜의 형태로 커널이 요청을 받아 device independent software (io subsystem)에 넘겨주면 공통적으로 할 수 있응 부분들을 처리해주고 디바이스에 특화된 동작들을 device driver을 통해서 하고 실제로 하드웨어 io 컨트롤러에게 명령을 전달을 하면 io 컨트롤러가 하드웨어적으로 io 디바이스를 동작을 시킨다.
• 동작이 완료가 되면 프로세스에게 cpu에게 알려줘야 하니까 인터럽트를 발생 시키면 인터럽트 핸들러가 동작 하면서 처리해줄거 해주고 디바이스 드라이버에게 전달을 해주면 이것를 다시 subsystem 받아와서 유저 프로세스한테 처리한 동작들을 전달을 해준다.

• io system은 하드웨어랑 소프트웨어로 나뉘어져 있고 하드웨어 단은 컨트롤러가 있고 컨트롤러 밑에 실제로 io를 수행하는 것들이있고 sw 쪽은 디바이스 드라이버, 혹은 특정한 io 디바이스에 대응되어서 드라이버가 존재하고 specific한 부분들을 건드리고 그런 것들의 공통적인 것을 모아서 처리하는거가 subsystem