Notice
Recent Posts
Recent Comments
05-18 00:00
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
Archives
Today
Total
관리 메뉴

Byeol Lo

1.2 Computer-System Organization 본문

OS/OS Design

1.2 Computer-System Organization

알 수 없는 사용자 2024. 4. 1. 14:20

 운영체제가 글로만 어떤건지 보았으니 이제 그 실체를 보자. 현대 일반적인 컴퓨터 시스템은 하나 이상의 CPU와 공통 버스(System Bus)를 통해 연결된 여러 디바이스 컨트롤러로 구성된다. 시스템 버스는 구성 요소 간의 액세스와 공유 메모리를 제공한다.

 여기서 각 디바이스 컨트롤러는 특정 유형의 장치( 디스크 드라이브, 오디오 장치, 그래픽 디스플레이, 마우스, 키보드, ... ) 를 담당하게 된다. 컨트롤러에 따라 둘 이상의 장치가 연결될 수 있는데, 그 예로 위의 USB controller가 있다. 여기서 CPU는 장치 컨트롤러가 작동하는 데 필요한 데이터를 임시로 저장하는 작은 저장소와 특수 목적으로 사용되는 레지스터(Special Purpose Register)를 갖고 있다.

 특수 목적 레지스터(장치 컨트롤러의 장치 상태를 나타내는 정보나 제어 명령을 저장하기 위해 특정 용도로 사용되는 레지스터)를 통해 컨트롤러는 장치를 효율적으로 관리하고 작동시킬 수 있다. 즉, 디바이스 컨트롤러라는 소프트웨어는 장치와의 데이터 통신을 위해 로컬 버퍼 저장소를 사용하고, 장치의 상태 및 제어 정보를 저장하기 위해 특수 목적 레지스터를 사용한다.

 또한, 각 디바이스 컨트롤러에 대한 디바이스 드라이버가 있는데, 이 디바이스 드라이버는 장치 컨트롤러를 이해하고 나머지 운영체제에게 장치에 대한 일관된 인터페이스를 제공한다. CPU와 디바이스 컨트롤러는 메모리 사이클을 경합하여 병렬로 실행될 수 있다. 공유 메모리에 대한 정돈된 액세스를 보장하기 위해 메모리 컨트롤러가 메모리 액세스를 동기화한다.

정리하자면 다음과 같다.

  • 각 디바이스 컨트롤러는 특정 유형의 장치를 담당.
  • 특수 목적 레지스터는 장치 컨트롤러의 장치 상태를 나타내는 정보나 제어 명령을 저장하기 위해 특정 용도로 사용되는 레지스터.
  • 디바이스 컨트롤러는 장치와의 데이터 통신을 위해 로컬 저장소를 사용함.
  • 디바이스 컨트롤러는 장치의 상태 및 제어 정보를 저장하기 위해 특수 목적 레지스터를 사용함.
  • 디바이스 컨트롤러는 소프트웨어임.

 

1.2.1 Interrupts

 전형적인 컴퓨터들은 I/O를 수행하는 프로그램. I/O 작업을 위해서는 다음의 과정을 거친다.

시작하려면 장치 드라이버가 장치 컨트롤러의 적절한 레지스터를 로드
→ 장치 컨트롤러(Device Controller)는 해당 레지스터를 조사해 어떤 작업을 수행할 지 결정
→ 컨트롤러는 장치에서 데이터를 로컬 버퍼(RAM 에 있는 일부 저장소)로 전송을 시작
→ 전송 완료 후 장치 컨트롤러는 장치 드라이버에게 작업을 완료했다는 것을 알림
→ 장치 드라이버는 운영체제의 다른 컴포넌트에게 제어를 양도.

 여기서 작업이 읽기인 경우에는 데이터나 데이터의 포인터를 반환할 수 있다. 다른 작업의 경우, 장치 드라이버는 '쓰기가 성공적으로 완료됨' 이나 '장치가 사용 중임' 등의 상태 정보를 반환한다.

 이때 의문이 들 수 있는 점은 어떻게 컨트롤러가 장치 드라이버에게 작업을 마쳤음을 알릴 수 있는지 일 것이다. 즉, 내부에서 신호를 주고받을 수 있는 매개체가 뭔지 궁금할 것이다. 그것이 바로 Interrupts이다. 보통 하드웨어는 언제든지 CPU에 대해 Interrupt를 발생시킬 수 있는데, 그 과정으로는 다음과 같다.

 CPU의 수행 중인 작업 중단 및 즉시 실행을 고정된 위치로 전송
→ 고정된 위치에는 인터럽트에 대한 서비스 루틴이 위치한 시작 주소가 일반적으로 포함되어 있음
→ 인터럽트 서비스 루틴이 실행되고 완료되면 CPU는 중단된 계산을 재게함.
밑은 위 과정의 유사 Gantt Chart 이다.

 

 인터럽트는 각 컴퓨터 설계마다 자체 인터럽트 메커니즘이 있겠지만, 일부 기능은 공통적이다. 인터럽트는 적절한 인터럽트 서비스 루틴으로 제어를 전달해야 하며, 이 전환을 관리하는 직접적인 방법은 인터럽트 정보를 검사하는 일반적인 루틴(특정 목적을 달성하기 위한 어떤 절차)을 호출하는 것. 이 루틴은 다시 인터럽트별 핸들러를 호출할 것이다. 하지만 인터럽트는 매우 자주 발생하기 때문에 빠르게 처리되어야 하고, 따라서 필요한 속도를 제공하기 위해 인터럽트 루틴의 포인터 테이블을 사용할 수 있다. 인터럽트 루틴은 중간 루틴이 필요하지 않고 이 테이블을 통해 간접적으로 호출되게 된다.

 일반적으로 포인트 테이블은 저 메모리에 저장된다. 이러한 위치는 다양한 장치에 대한 인터럽트 서비스 루틴의 주소를 보유하고, 이 주소 배열 또는 인터럽트 벡터는 인터럽트 요청과 함께 제공된 고유 번호에 의해 색인화 되어 인터럽트 장치의 인터럽트 서비스 루틴의 주소를 제공하게 된다. Windows, Unix와 같이 서로 다른 운영 체제도 이 방식으로 인터럽트를 처리한다.

  • 인터럽트는 컴퓨터 설계마다 차이가 있지만, 공통적인 기능이 있음.
  • 인터럽트는 적절한 인터럽트 서비스 루틴으로 제어를 전달함.
  • 루틴이 다시 인터럽트별 핸들러를 호출.
  • 인터럽트 루틴 내에서 포인터 테이블을 사용하여 빠른 속도의 처리 가능.
  • 인터럽트 번호를 통해 테이블에서 해당하는 서비스 루틴의 주소를 찾아서 실행함.

 

 인터럽트 아키텍처는 인터럽트가 발생하기 전의 상태 정보를 저장해야하고, 이렇게 함으로써 인터럽트 서비스 후에 이 정보를 복원할 수 있게 된다. 만약 인터럽트 루틴이 프로세서 상태를 수정해야 하는 경우에는 현재 상태를 명시적으로 저장한 다음 반환하기 전에 그 상태를 복원해야 하며 인터럽트가 서비스되면 저장된 반환 주소가 프로그램 카운터에 로드되고, 중단된 계산은 인터럽트가 발생하지 않았을 때와 마찬가지로 다시 시작된다.

 

Interrupts Implementation

 이제 내부적으로 I/O 동작과 인터럽트가 실행되는 동작을 동시에 살펴보자. CPU 하드웨어에서 각 명령을 실행한 후에 감지하는 "interrupt-request line" 이라는 선이 있고, 컨트롤러가 interrupt-request line 에 신호를 보내면 해당 신호의 인터럽트 번호를 읽고 이를 interrupt vector의 인덱스로 사용하여 인터럽트 핸들러 루틴으로 이동하게 된다. 그런 다음에 해당 인덱스와 관련된 주소에서 실행을 시작한다. 인터럽트 핸들러는 작동 중에 변경될 상태를 저장하고, 인터럽트의 원인을 결정하고, 필요한 처리를 수행하며, 상태를 복원하고, 인터럽트 전의 실행 상태로 CPU를 복귀시키는 interrupt 반환 명령을 실행한다.

CPU 명령 실행 후
→ interrupt-request line(전선, 선로) 에 interrupt가 들어왔는지 신호 감지.
→ 인터럽트 서비스를 실행하기 앞서 CPU의 상태 저장
→ CPU는 interrupt-request line에서 interrupt 번호 저장
→ CPU는 interrupt handler를 실행하고 해당 번호 전달.
→ interrupt handler 는 interrupt vector에서 이 interrupt 번호를 인덱스로 사용함.
→ interrupt vector[interrupt 번호]에 해당하는 주소로 이동
→ 맞는 interrupt-handler routine을 실행
→ 이 루틴 안에서 인터럽트의 원인, 그 장치에 대한 필요한 처리를 수행한다.
→ 루틴을 전부 실행하면, 해당 인터럽트 반환 명령이 실행됨.
→ 이때, CPU가 인터럽트 서비스 루틴을 실행하기 전의 상태로 복귀하게 된다. 이를 인터럽트 반환이라고 한다.

 이러한 처리 과정을 본다면 interrupt 아키텍처는 기본적으로 비동기(asynchronous) 이벤트에 응답할 수 있도록 되어 있다. 또한 현대에 와서는 다음과 같은 다양한 문제점들을 고려해야 한다.

  1. 중요한 처리 중에는 인터럽트 처리를 연기할 수 있어야 한다.
  2. 장치에 대한 적절한 인터럽트 핸들러로 효율적인 디스패치(특정한 작업이나 이벤트를 해당하는 처리기에 전달하는 것)가 필요
  3. 다중 레벨 인터럽트가 필요(즉, 우선 순위를 통해 적절한긴급도를 통한 대응이 필요)

이러한 세 가지 문제점들은 전부 CPU와 interrupt-controller hardware에 의해 기능들이 제공되어진다.

 대부분의 CPU는 두 개의 interrupt-request line을 가지고 있는데, 하나는 Nonmaskable interrupt, 다른 하나는 Maskable interrupt이다.

  • Nonmaskable interrupt: 복구할 수 없는 메모리 오류와 같은 이벤트를 위해 예약되어 있음.
  • Maskable interrupt: CPU가 중요한 명령의 실행 전에 인터럽트가 발생하지 않아야 하는 중요한 상황에서 비활성화 될 수 있음. 이것이 바로 일반적으로 장치 컨트롤러가 서비스를 요청할 때 사용되는 interrupt-request line임.

 

 이제 interrupt vector 기술을 보자. 인터럽트 핸들러가 서비스가 필요한 인터럽트의 소스를 찾기 위해 모든 가능한 인터럽트 소스를 검색하는 필요성을 줄이기 위해 이 벡터가 있다. 하지만 실제로는 컴퓨터에는 인터럽트 벡터의 주소 요소보다 더 많은 장치가 있고, 이 문제를 해결하기 위해 interrupt chaining을 사용한다.

 여기서 인터럽트 벡터의 각 요소는 인터럽트 핸들러 목록의 헤드를 가르키며 인터럽트가 발생하면 handler의 list들이 하나하나씩 호출되어 요청을 처리할 수 있는 핸들러를 찾을 때까지 호출이 된다. 이 방법은 거대한 인터럽트 테이블로 인한 메모리 과다 사용(그 많은 인터럽트에 대한 정보를 저장한 테이블을 메모리에 올려야 하기 때문)과 단일 인터럽트 핸들러로 디스패치하는 비효율성(인터럽트 핸들러가 병렬로 작업할 수 있는 여지가 없음) 사이의 타협이다.

 위는 인텔의 인터럽트 벡터이다(보통 테이블이라고 불리기도 함). 여기서 0부터 31까지의 이벤트는 마스킹할 수 없는 이벤트이고, 다양한 오류 조건을 신호화하는 데 사용된다. 32부터 255까지는 마스킹 할 수 있는 이벤트로, 장치에서 생성된 인터럽트와 같은 목적으로 사용된다.

  • 인터럽트 벡터는 singly linked list를 통해 간단히 구현할 수 있다.
  • 인터럽트 핸들러는 여러개가 있다(네트워크 인터럽트 핸들러, 타이머 인터럽트 핸들러, 디스크 인터럽트 핸들러, ...).
  • 인터럽트 벡터의 요소들은 인터럽트 핸들러가 가지고 있는 인터럽트 연결 리스트의 시작지점을 가르킨다. 이를 interrupt chaining이라고 한다.
  • interrupt chaining은 huge interrupt table과 inefficient single handler dispatches의 trade-off를 고려한 방법이다.
  • interrupt 중에는 nonmaskable 과 maskable인 interrupt 들이 있고 line 또한 두 가지 있다.

 

 또한 인터럽트들은 전부 우선순위 레벨을 가지고 있어서 CPU가 모든 인터럽트를 마스킹하지 않고 낮은 우선순위의 인터럽트 처리를 연기할 수 있도록 하며, 높은 우선순위의 인터럽트가 낮은 순위 실행을 선접할 수 있도록 한다.

 

1.2.2 Storage Structure

 CPU는 명령어를 메모리에서만 로드할 수 있으므로, 실행할 프로그램은 전부 메모리에 로드(적재)가 되어 있어야 한다. 일반적인 목적의 컴퓨터는 주로 메인 메모리라는 재기록 가능한 메모리에서 대부분의 프로그램을 실행하는데, 메인 메모리는 주로 다이나믹 랜덤 액세스 메모리(DRAM)라는 반도체 기술로 구현되게 된다.

 또 다른 형태의 메모리로는 부트스트랩(전원을 킬 때 실행되는 프로그램, bootstrap program)이 저장되는 곳으로 휘발되지 않는 메모리에 저장되어져야 하는 프로그램이다. 하지만 RAM은 휘발성이기에 이 프로그램을 저장하기 적합하지 않고, 용량도 적고 비싸기 때문에 신뢰할 수 없다. 따라서 컴퓨터는 electrically erasable, programmable 한 read-only memory (EEPROM) 또는 펌웨어 메모리(form ware)를 사용하게 된다.

 워드(word): 컴퓨터의 기본적인 데이터 단위이며, 워드는 하나 이상의 바이트로 구성이 된다. 64비트 레지스터와 64비트 메모리 주소 지정이 있는 컴퓨터는 일반적으로 8바이트의 워드를 가지며, 이런 컴퓨터들은 보통 바이트 단위가 아니라 워드의 크기로 많은 작업을 수행하게 된다.
  • CPU는 메인메모리를 통해 명령어를 로드 한다.
  • 실행할 프로그램은 전부 메인메모리에 로드 되어 있다.
  • 메인 메모리는 rewritable하고, volatile 하다.
  • bootstrap program을 실행하기 위해 non-volatile의 EEPROM 또는 펌웨어(firm ware)의 저장소를 사용할 수 있다.
  • 대부분의 프로그램을 메인 메모리에 저장하기에는 너무 용량이 작고 휘발성이기에 내용이 손실된다.

 

 여기서 모든 종류의 메모리는 바이트 배열을 제공하고, 각 바이트에는 고유한 주소가 있다. 이때 프로그램이나 데이터를 워드 단위로 읽어올 때 혹은 저장할 때 필요한 과정 즉, CPU가 메모리에 접근하여 워드를 레지스터로 읽어오는 것(load) 또는 CPU가 레지스터에 있는 워드를 메모리에 저장하는 것(store)이 메모리의 특정한 주소를 대상으로 이루어 진다. 이 명령들이 연결되어서 프로그램이나 데이터가 메모리에 올라가거나 저장될 때마다 순차적으로 실행되게 된다.

 물론 다른 저장 시스템들도 많이 있다. tertiary storage라고 불리는 CD-ROM 또는 블루 레이, 자석 테이프 등등이 있으며, 이러한 다양한 저장 시스템은 저장 용량과 액세스 시간에 따라 계층 구조로 구성될 수 있다.

 

1.2.3 I/O Structure

 운영체제는 시스템의 신뢰성과 성능에 대한 중요성과 장치에 대한 다양한 특성 때문에 I/O를 관리하는데 굉장히 집중을 한다. 처음 그림에서 보다시피 컴퓨터 시스템은 모든 장치의 공통 버스를 통해 데이터를 교환하는 것을 보았을 것이다. 보통은 system bus를 통해 데이터를 교환을 하지만, 인터럽트에서 설명했다시피 인터럽트 기반의 I/O의 형태는 작은 양의 데이터를 이동하는 데는 적합하지만 대량의 데이터 이동에는 오버헤드를 초래할 수 있기 때문에 DMA(Direct Memory Access)라는 기술이 사용된다.

 DMA란, I/O 장치에 대한 버퍼, 포인터 및 카운터를 설정한 후에 장치 컨트롤러는 CPU의 개입이 없이 장치와 주 메모리 사이에서 전체 데이터를 블록 단위로 직접 전송한다. 낮은 속도의 장치는 데이터를 전송할 때마다 인터럽트가 발생하지만, 한 블록당 하나의 인터럽트만 생성되기 때문에 빠르고, 다 전송이 되면 DMA는 CPU에게 작업이 완료되었음을 알리는 인터럽트 신호를 보내고 CPU는 전송의 시작과 끝 부분에만 관여하게 된다. DMA 컨트롤러가 이러한 작업을 수행하는 동안 CPU는 아무것도 하지 않기 때문에 다른 작업을 수행할 수 있다. 일부 더 발전된 시스템에서는 공유 버스에서 사이클을 경쟁하는 대신 스위치 아키텍쳐를 사용하고, 이는 여러 구성 요소가 동시에 다른 구성 요소와 통신할 수 있어서 DMA가 더 효과적으로 실행된다

  • 인터럽트 기반의 I/O는 작은 양의 데이터를 이동하는데 적합
  • 인터럽트 기반의 I/O는 대량의 데이터에는 오버헤드를 초래
  • 빠른 순위 : 메모리 직접 접근 I/O(DMA)-더 빠름 〈 인터럽트 처리에 의한 I/O
  • DMA는 인터럽트 처리 기반의 I/O에 비해 CPU의 개입이 없어서 더 빠름
  • 데이터를 블록 단위로 직접 전송하기에 그냥 데이터를 전송하는 것보다 대량으로 처리.
  • DMA작업이 다 완료되면 CPU에게 작업이 완료되었음을 알리는 인터럽트 신호를 보냄

 

'OS > OS Design' 카테고리의 다른 글

1.6 Security and Protection  (0) 2024.04.06
1.5 Resource Management  (0) 2024.04.04
1.4 Operating-System Operations  (1) 2024.04.03
1.3 Computer-System Architecture  (0) 2024.04.01
1.1 What Operating System Do  (0) 2024.03.05
Comments