I/O Systems

2017. 6. 19. 13:51·레거시/OS

* I/O Hardware Detail

- CPU side: I/O bus와 I/O address

하드웨어 장치와 통신하기 위한 주소, 물리적 메모리 주소 공간에 매핑 가능


- Device side: hardware controller

Control 및 status registers (CSRs)


- 하드웨어 디바이스와 상호 작용하는 세가지 방법

폴링 (예 : 플로피 드라이버)

인터럽트 구동 (예 : 대부분의 다른 장치)

DMA (직접 메모리 액세스)



* I/O Architecture

- Three components

I/O ports

I/O interfaces

Device controller


- I/O ports

I / O 버스에 연결된 각 장치에는 "I / O 포트"라고하는 고유한 I / O 주소 집합이 있습니다.

각 장치의 I / O 포트는 일련의 특수 레지스터로 구성됩니다.

in, ins, out, outㄴ 명령을 통해 CPU와 I / O 포트 간의 데이터 전송.


- I/O interfaces

I / O 포트 그룹과 해당 장치 컨트롤러 사이에 삽입 된 하드웨어 회로.

I / O 포트의 값을 장치의 명령과 데이터로 변환하는 인터프리터 역할을합니다.


사용자 정의 I / O 인터페이스 :

• 키보드 / 그래픽 / 디스크 / 네트워크 / 버스 - 마우스 인터페이스

범용 I / O 인터페이스 :

• 병렬 포트, 직렬 포트, USB / PCMCIA / SCSI 인터페이스


- Device controller

I / O 인터페이스로부터 수신된 상위 레벨 명령을 해석하고, 적절한 순서의 전기 신호를 보내 특정 동작을 실행하도록 장치를 강제 실행합니다.

수신된 전기 신호를 변환하고 올바르게 해석합니다.

(I / O 인터페이스를 통해) 상태 레지스터의 값을 수정합니다.



* Polling vs Interrupts

- Polled I/O

CPU는 주의가 필요한 경우 장치에 "폴링"을 요청합니다.

- 장점

• 단순; 소프트웨어가 제어됩니다.

• CPU가 장치를 곧 준비 할 수 있으면 효율적입니다.

- 단점

• 사소한 시스템에서는 비효율적입니다 (CPU 사용률 높음).


- Interrupt-driven I/O

입출력 장치는 주의가 필요할 때 인터럽트를 요청합니다.

각 장치에 특정한 인터럽트 서비스 루틴이 호출됩니다.

인터럽트는 여러 장치간에 공유 할 수 있습니다.

- 장점

• CPU는 필요한 경우에만 장치에 접속합니다.

• 일반적으로 폴링보다 효율적입니다.

- 단점

• 초과 인터럽트는 프로그램 실행을 느리게 (또는 방지)합니다.

• 오버 헤드



* DMA

CPU를 바이 패스하여 I / O 장치와 메모리간에 직접 데이터를 전송.

대용량 데이터 이동을 위해 프로그래밍 된 I / O를 방지하는 데 사용됩니다.

DMA 컨트롤러 필요



* DMA 모드

- Cycle stealing

• DMA 컨트롤러가 가끔씩 CPU에서 임시 버스주기를 잠시 훔쳐 약간 지연시킵니다.

- Burst mode

• DMA 컨트롤러는 버스를 획득하고 일련의 전송을 실행 한 다음 버스를 해제합니다.

• 사이클 훔치기보다 효율적 : 버스 획득에는 시간이 걸리고 하나의 버스 획득 가격으로 여러 단어를 전송할 수 있습니다.

• CPU 및 기타 장치를 너무 오래 차단할 수 있습니다.



* DMA에서 어드레싱

- OS가 물리적 어드레스로 예정된 메모리 버퍼의 가상 주소를 변환하여 DMA 컨트롤러의 어드레스 레지스터에 기입한다.

- DMA 동안 대상 메모리 영역을 고정 (페이징되지 않음)해야합니다.



* I/O 하드웨어 접근

- 디바이스는 Direct I/O instructions를 사용하거나 Memory-mapped I/O(예: 그래픽 컨트롤러)를 사용한 주소를 가지고 있습니다.


- Direct I/O

I / O 포트 주소에 대한 특수 I / O 명령어를 사용


- Memory-mapped I/O

장치 제어 레지스터는 프로세서의 주소 공간에 매핑됩니다.

CPU가 표준 데이터 전송 명령어를 사용하여 I / O 요청을 실행합니다.

사용자 프로세스가 I / O (가상 주소 페이징)를 수행하지 못하게하는 특별한 보호 메커니즘이 필요하지 않습니다.

장치 레지스터 읽기 및 값 테스트는 단일 명령으로 수행됩니다.



* I/O 소프트웨어

- 응용 프로그램 I / O 인터페이스

장치가 매우 다양 할 때 OS가 어떻게 응용 프로그램에 편리하고 균일 한 I / O 인터페이스를 제공하는지


- 장치 드라이버 계층 추상화

커널에서 I / O 컨트롤러 간의 차이점을 숨깁니다.


- I / O 소프트웨어의 목표

기기 독립성

• 프로그램은 사전에 장치를 지정하지 않고도 모든 I / O 장치에 액세스 할 수 있습니다.

통일 된 명명법

• 파일 또는 장치의 이름은 단순히 문자열 또는 정수 여야합니다.

효과적인 오류 처리

• 가능한 한 하드웨어 가까이에서 다루십시오.

성능 (버퍼링 / 캐싱을 통한)

• 장치에서 나오는 데이터는 최종 목적지에 저장할 수 없습니다.



* 장치 드라이버

- 장치 독립적인 I / O 소프트웨어 및 인터럽트 처리기와 상호 작용하는 각 I / O 장치를 제어하는 장치 별 코드.

- 잘 정의 된 모델과 나머지 OS와 상호 작용하는 방법에 대한 표준 인터페이스를 정의해야합니다.

- 장치 드라이버 구현 :

• 커널과 정적으로 연결됩니다.

• 실행 중에 시스템에 동적으로 로드됩니다. (특히 핫 플러그 형 장치의 경우).

- 표준 드라이버 인터페이스 필요



* 장치 독립적 인 I / O 소프트웨어 (Device-Independent I/O software)
- 장치 드라이버의 통일된 인터페이싱
UNIX에서 장치는 특수 "파일"로 모델링됩니다.
• 시스템은 open (), read (), write (), close (), ioctl () 등과 같이 시스템 사용에 접근했습니다.
• "파일 이름"은 각 장치와 관련됩니다.
주요 장치 번호는 적절한 드라이버를 찾습니다.
• 읽기 또는 쓰기 할 단위를 지정하기 위해 (inode에 저장된) 보조 장치 번호가 매개 변수로 드라이버에 전달됩니다.
파일에 대한 일반적인 보호 규칙은 I / O 장치에도 적용됩니다.


- Buffering

(a) Unbuffered

(b) Buffered in user space

(c) Buffered in the kernel space 

(d) Double buffering in the kernel


- 오류보고

대부분의 오류는 장치마다 다르므로 적절한 드라이버에서 처리해야하지만 오류 처리를위한 프레임 워크는 장치와 관련이 없습니다.

오류 처리 :

• 오류 코드와 함께 시스템 호출 반환

• 특정 횟수 재 시도

• 오류 무시

• 호출 프로세스 종료

• 시스템 종료.


- 장치 독립적 블록 크기

여러 섹터를 단일 논리 블록으로 처리합니다.

상위 계층은 모두 동일한 블록 크기를 사용하는 추상 장치 만 처리합니다.




* User-Space I/O software

- 라이브러리같이 제공

Standard I/O library in C

fopen() vs open()

Buffering for fgetc()


- spooling

멀티 프로그래밍 시스템에서 전용 I / O 장치를 다루는 방법.

데몬과 스풀링 디렉토리로 구현됩니다.

프린터, 네트워크 파일 전송, USENET 뉴스, 메일 등



* I / O 성능 향상

- I / O : 시스템 성능의 주요 요소

장치 드라이버, 커널 I / O 코드를 실행하도록 CPU에 요구합니다.

인터럽트로 인한 모드 전환

데이터 복사

특히 스트레스가 많은 네트워크 트래픽


- 가이드 라인

모드 스위치의 수를 줄이십시오.

데이터 복사 축소

대규모 전송, 스마트 컨트롤러를 사용하여 인터럽트 감소

DMA 사용

프로세싱 프리미티브를 하드웨어로 옮깁니다. CPU 및 장치 컨트롤러의 동시 작업

최고의 처리량을 위해 CPU, 메모리, 버스 및 I / O 성능의 균형을 맞 춥니 다.







'레거시 > OS' 카테고리의 다른 글

Mass Storage Structure  (0) 2017.06.19
Virtual Memory  (1) 2017.06.18
Memory Management  (0) 2017.06.18
File System(2)  (0) 2017.06.18
File System(1)  (0) 2017.06.18
'레거시/OS' 카테고리의 다른 글
  • Mass Storage Structure
  • Virtual Memory
  • Memory Management
  • File System(2)
pfldy2850
pfldy2850
인공지능의 서비스화와 현실화에 관심이 많은 엔지니어입니다.
  • pfldy2850
    DEV.DY
    Github LinkedIn
  • 전체
    오늘
    어제
    • All (104)
      • AI (68)
        • 어플리케이션 개발 (11)
        • 모델 인퍼런스 (9)
        • 검색 시스템 (11)
        • MLOps (8)
        • 기술,논문 리뷰 (7)
        • Lecture notes (10)
        • 오픈소스 릴리즈 노트 (12)
      • Infra (4)
        • Kubernetes (1)
        • Service Mesh (1)
        • Service Proxy (1)
        • Storage (1)
      • Data Engineering (4)
        • Spark (3)
        • Kafka (1)
        • Delta Lake (0)
      • 컴퓨터 공학 (2)
        • 소프트웨어 공학 (2)
      • 개발 (15)
        • ReactJS (8)
        • NodeJS (2)
        • Python (3)
        • Pytorch (1)
        • git (1)
      • 영어공부 (2)
        • GPT로 영어 회화 공부 (2)
      • 활동 (2)
        • 2017 NDC (2)
      • 기타 (1)
      • 레거시 (6)
        • OS (6)
  • 인기 글

  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.1
pfldy2850
I/O Systems
상단으로

티스토리툴바