[OSTEP] 36. I/O Devices

1.1 왜 계층 구조인가#

핵심 이유는 물리적 제약과 비용입니다.

• 빠른 버스일수록 신호 무결성을 위해 길이가 짧아야 하고, 많은 장치를 멀리까지 달기 어렵습니다.
• 빠르고 복잡한 버스는 구현 비용이 큽니다.

그래서 고성능 장치는 CPU 가까운 고속 버스에, 나머지 장치는 한 단계 아래의 버스에 연결하는 계층 구조가 일반적입니다.

2.1 장치 인터페이스의 전형#

대부분의 장치는 다음과 같은 레지스터를 제공합니다.

• Status register: 장치 상태(준비됨, 바쁨, 오류 등)
• Command register: 수행할 동작 지정(읽기, 쓰기, 리셋 등)
• Data register: 데이터 송수신 통로

OS는 이 레지스터를 읽고 쓰는 것만으로 장치를 제어할 수 있고, 장치 내부의 복잡함은 장치가 알아서 처리합니다.

3.1 폴링 기반 프로토콜 흐름#

아래는 전형적인 흐름입니다.

1
// 1) 장치가 준비될 때까지 대기
2
while (STATUS == BUSY) { /* spin */ }
3

4
// 2) 데이터 레지스터에 필요한 데이터 채우기
5
write_data_to_DATA_register();
6

7
// 3) 커맨드 레지스터에 명령 기록
8
write_command_to_COMMAND_register();
9

10
// 4) 완료될 때까지 다시 대기
11
while (STATUS == BUSY) { /* spin */ }

3.2 폴링의 장단점#

• 장점: 구현이 단순하고 예측 가능함
• 단점: 장치가 느릴수록 CPU가 바쁜 루프만 돌며 낭비됨

폴링의 CPU 낭비를 아주 단순화해 보면, 장치 작업 시간이 $T_{dev}$ 일 때 CPU가 아무 일도 못 하는 시간이 거의 $T_{dev}$에 가깝습니다. 즉 CPU 유휴 시간을 활용할 수 없습니다. 정확히는 CPU가 idle이 아니라 busy-wait로 시간을 소비합니다.

4.1 인터럽트 기반 흐름#

1. OS가 장치에 요청을 보냅니다.
2. OS는 해당 프로세스를 block 시키고 다른 일을 수행합니다.
3. 장치가 작업을 끝내면 인터럽트를 발생시킵니다.
4. CPU는 커널의 인터럽트 핸들러로 들어가 마무리 작업을 합니다.
5. 대기하던 프로세스를 wakeup 합니다.

이 방식의 핵심 가치는 연산과 I/O의 중첩(overlap) 입니다. 폴링은 기다림 동안 CPU가 놀지만, 인터럽트는 그 시간을 다른 프로세스 실행에 사용합니다.

4.2 인터럽트가 항상 이득은 아니다#

인터럽트도 비용이 있습니다. 인터럽트 처리 과정은 보통 다음 오버헤드를 동반합니다.

• 트랩 및 컨텍스트 전환 비용
• 핸들러 실행 비용
• 캐시/파이프라인 교란 비용

따라서 장치가 매우 빠른 경우에는

일 때, 인터럽트 처리 비용 $T_{int}$ 가 지배적이 되어 오히려 폴링이 더 나을 수 있습니다. 그래서 현실의 시스템은 보통 짧게 폴링하다가, 오래 걸리면 인터럽트로 전환하는 하이브리드를 사용합니다.

4.3 인터럽트 폭주와 coalescing#

네트워크 패킷 폭주처럼 인터럽트가 너무 자주 발생하면, OS가 인터럽트 처리만 하느라 정상 작업을 거의 못 하는 livelock에 빠질 수 있습니다.

이를 완화하기 위한 대표 기법이 interrupt coalescing입니다.

• 일정 시간 또는 일정 개수의 이벤트를 모아
• 인터럽트를 한 번만 발생시켜
• 인터럽트 빈도를 낮춥니다

장점은 CPU 오버헤드 감소, 단점은 이벤트 처리 지연(latency) 증가입니다. 결국 이 역시 오버헤드 vs 지연의 트레이드오프입니다. 네트워크 스택에서는 인터럽트 완화와 함께 일정 구간 폴링으로 전환하는 방식도 흔히 결합됩니다.

5.1 DMA의 핵심 아이디어#

DMA(Direct Memory Access) 는 데이터 복사를 전담하는 하드웨어 엔진입니다.

1. OS가 DMA 엔진에 다음을 설정합니다.
   • 소스/목적지 주소
   • 전송 크기
2. DMA 엔진이 메모리와 장치 사이 데이터를 복사합니다.
3. 완료되면 DMA가 인터럽트로 OS에 알립니다.

이렇게 하면 CPU는 전송 동안 다른 일을 할 수 있어, 대용량 I/O에서 특히 큰 이득이 있습니다.

6.1 Explicit I/O instructions#

일부 아키텍처는 장치 접근을 위한 별도의 명령어를 제공합니다. 예를 들어 x86의 in, out 같은 방식입니다.

6.2 Memory-mapped I/O#

장치 레지스터를 물리 주소 공간의 일부로 매핑해, 일반 메모리 접근처럼 load/store 로 접근하는 방식입니다. 현대 시스템에서 매우 흔합니다. 다만 MMIO는 일반 메모리와 달리 재주문이나 캐싱의 영향을 받을 수 있어, 드라이버에서는 volatile 접근이나 메모리 배리어 같은 제어가 함께 쓰이기도 합니다.

7.1 스택으로 보는 위치#

예를 들어 파일 시스템은 아래와 같은 계층을 통해 디스크에 접근합니다.

• 파일 시스템: 읽기/쓰기 같은 논리 요청 생성
• 범용 블록 계층: 요청을 일반화하고 스케줄링
• 장치 드라이버: 실제 장치 프로토콜(레지스터 조작) 수행
• 하드웨어 장치

7.2 드라이버의 현실적인 어려움#

• 장치별로 드라이버가 다르고, 하드웨어 조합이 방대합니다.
• OS 커널 코드 중 상당 부분이 드라이버일 정도로 규모가 큽니다.
• 하드웨어 세부에 강하게 결합된 코드가 많아 버그가 생기기 쉽습니다.

즉 추상화는 필수지만, 유지보수 비용도 함께 커집니다.

8.1 IDE 인터페이스 개요#

IDE는 비교적 단순한 레지스터 기반 인터페이스를 갖습니다.

8.2 요청 처리 흐름#

전체 흐름은 아래처럼 이해하면 됩니다.

1. 요청이 들어오면 큐에 넣습니다.
2. 디스크가 idle이면 즉시 요청을 시작합니다.
3. 요청을 시작할 때 레지스터를 채우고 read 또는 write 명령을 내립니다.
4. 프로세스는 I/O 완료까지 sleep 합니다.
5. 디스크가 완료하면 인터럽트를 발생시키고, 핸들러가 필요한 데이터를 복사하거나 상태를 갱신한 뒤 잠든 프로세스를 깨웁니다.

여기서 중요한 포인트는 두 가지입니다.

• 요청 시작은 보통 인터럽트가 아닌 정상 실행 흐름에서 수행됩니다.
• 완료 처리는 인터럽트 핸들러에서 수행되고, 그 결과로 다음 요청을 이어서 시작합니다.

1
// 개념 코드: xv6 IDE 드라이버의 핵심 흐름을 단순화한 형태
2
// buf: 블록 I/O 요청 구조체(READ/WRITE 플래그, 섹터 번호, 데이터 버퍼 등)
3

4
static struct spinlock ide_lock;
5
static struct buf *idequeue;
6

7
static void ide_start(struct buf *b) {
8
    // 1) 장치 ready까지 짧게 폴링(status 확인)
9
    // 2) 섹터 번호/개수 및 데이터 레지스터 설정
10
    // 3) READ/WRITE 커맨드를 기록해 요청 시작
11
}
12

13
void ide_rw(struct buf *b) {
14
    acquire(&ide_lock);
15

16
    // 요청을 큐에 연결
17
    b->qnext = NULL;
18
    if (idequeue == NULL) idequeue = b;
19
    else tail(idequeue)->qnext = b;
20

21
    // 디스크가 idle이면 즉시 시작
22
    if (idequeue == b)
23
        ide_start(b);
24

25
    // 완료까지 sleep: 인터럽트 핸들러가 flags 갱신 후 wakeup
26
    while ((b->flags & (B_VALID | B_DIRTY)) != B_VALID)
27
        sleep(b, &ide_lock);
28

29
    release(&ide_lock);
30
}
31

32
void ide_intr(void) {
33
    acquire(&ide_lock);
34

35
    struct buf *b = idequeue;
36
    if (b == NULL) {
37
        release(&ide_lock);
38
        return;
39
    }
40
    idequeue = b->qnext;
41

42
    if ((b->flags & B_DIRTY) == 0) {
43
        // READ 완료: 장치 -> 메모리 전송(예: insl(DATA, b->data, BSIZE/4))
44
    } else {
45
        // WRITE 완료: 이미 메모리 -> 장치 전송(outsl)을 끝낸 상태
46
        b->flags &= ~B_DIRTY;
47
    }
48

49
    b->flags |= B_VALID;
50
    wakeup(b);
51

52
    // 다음 요청이 있으면 이어서 시작
53
    if (idequeue != NULL)
54
        ide_start(idequeue);
55

56
    release(&ide_lock);
57
}

완료 조건은 다음 불변식으로 요약할 수 있습니다.

즉 I/O가 끝나면 버퍼는 유효하고(B_VALID), 더 이상 dirty가 아니어야 합니다.