마이크로커널운영체제

[마이크로 커널 운영체제]

1. 마이크로커널 운영체제란?

# 마이크로프로세스의 수행모드

kernel mode <-> user mode

- kernel mode : OS의 모든 기능을 수행할 수 있음

- user mode : 대부분의 사용자 프로그램을 실행

멀티 프로세스를 지원하기 위함

# 운영체제의 2가지 종류

- 모노리틱 운영체제 : 모든 프로그램이 OS의 커널모드에서 수행되는 방식

os/360, Unix, VMS, MS-DOS, Linux, ...

- 마이크로커널 운영체제 : 운영체제의 최소 기능만 OS의 커널모드에서 수행되고 대부분의 기능이 user mode에서 수행되는 방식

Mach, Chorus, L4, Minix, ...

# Mechanism과 Policy의 분리

- Mechanism : 마이크로커널(커널모드)

  a. Thread Manager, 스레드 생성/종료

  b. IPC Manager ,  inter-process communication 여러 스레드, 프로세스 간 메시지 전달

  c. address space Manager : 주소공간을 생성 및 페이지 할당 등

  d. interrupt Manager : device는 policy를 사용하므로 micro kernel에 있지않고 user mode 쪽으로 존재. 이 드라이브를 micro kernel에 등록/호출 

- Policy : 서버프로그램들(유저모드)

  a. pager : 페이지폴트 처리

  b. device driver

그림 

b. 마이크로커널 운영체제의 변천사

- 1세대 : CMU에서 Mach OS 개발

개념이 너무 좋아서 많은 사람들이 굉장하였지만, 성능이 좋지않아 실망함 (사람들의 인식=>마이크로커널운영체제는 개념은 좋지만 성능은 별로)

- 2세대 : GMD의 Liedtke가 효율적인 IPC 구현 기술을 개발. 1세대 마이크로운영체제보다 수십배 빠른 마이크로운영체제를 만듬

굉장한 많은 복합적인 컴퓨터과학부분의 방법들을 적용을하여 Optimization 시킴

=> 성능향상 (개발자 왈 : 마크는 원래 개념도 좋고 성능도 좋다. 본디 최적회가 안되었을뿐)

- 3세대 :  수학의 logic과 프로그래밍언어의 sementics를 사용하여 formal verification 기술을 개발. (테스트가아닌 "증명"을 수행하여 신뢰할 수 있는 마이크로 커널을 만들게 됨)

=> 고 신뢰성을 보장. security, availability, reliability ...

2. 기본적인 특징 

: flexibility, safety, modularity

a. flexibility

: mechanism과 policy를 분리하여 유연한 운영체제를 구현. 모노리틱커널운영체제보다는 훨씬 쉽게 구현가능

- 하나의 microkernel 상에서 다수의 운영체제를 동시에 수행시킬 수 있음.

   ex. linux OS, windows OS

- 하나의 microkenel 상에서 다수의 정책을 쉽게 구현이 가능 ( 하나의 프로세스에 다수의 policy를 구현 )

   ex. 일반 paging, 멀티미디어용 paging을 동시에 적용 할 수 있음

- 어떤 file system 위에 다른 file system을 쉽게 구현 할 수 있음

   ex. stacked file system

b. safety 안전성

: microkernel과 server program이 분리되면서 microkernel 모듈이 굉장히 줄어들어 커널 자체가 가지는 안전성이 굉장히 높아짐.

: 대부분의 프로그램들이 server program에서 user mode로 수행이 되므로, OS의 한 부분에 문제가 생겨도 kernel이나 다른 서버에 문제가 생길 소지가 적어지게 됨(fault isolation)

c. modularity 모듈성

: 전체 OS가 작은 마이크로커널 + 다수의 서버프로그램으로 모듈화됨

:- os를 개발할 때 하나의 모듈을 개발 할 때 개발비용이 적어짐

- 모노리틱 커널에 비해 테스트가 용이

- 유지비수 비용이 낮아짐

- 운영체제를 재부팅하지 않고 file system 등 크리티컬한 프로그램도 쉽게 업데이트할 수 있음

3. 내부구조

# 마이크로커널 부분

a. thread manager

- thread_create, thread_exit

- thread scheduler : priority 기반의 round robin(scheduler는 policy가 있으므로 서버프로그램으로 구현하여야 하지만 성능의 문제로 아직은 micro kernel 내에 구현)

- data structure

: TCB(Thread Control Block), thread_id, thread_state, thread_quota, address_space(memory), kernel_stack(system call이 아예없지는 않기떄문인듯)

b. IPC(inter-process communication) Manager

: 시스템호출만 제공하여 두 스레드사이에 데이터를 주고받음

- synchronous IPC  : ipc_send, ip_resceive

- asynchronous notification: 데이터를 전달하는 개념보다는 어떤 이벤트가 발생했을 때, asynchronous하게 이벤트를 알려줌

  ipc_notify, ipc_getnotify, ipc_event 필요, 

* synchronous IPC + asynchronous notification

* 현재 microkernel에서는 synchronous IPC를 사용

why? microkernel 운영체제는 IPC 성능이 매우 중요

synchronous IPC를 제공하면서 많은 optimization을 적용할 수 있게됨

(synchronous IPC는 이미 많은 기술들이 발전했으므로 적용가능한 optimiza)

* asynchronous notification을 병행하는 이뉴? 마이크로커널의 성능을 높이기위해 

thread프로그래밍을 할 때 synchronous만 있는 경우는 너무 불편하므로 섞음

c. address space manager

- 모노리티커널의 메모리 관리자와는 완전 다름

- 최소한의 메커니즘만 제공

- as_create(address space create) : address space 생성

- as_map : 하나의 page 할당

- as_unmap : 할당받은 page 반환

- 사용하는 자료구조 

: AS, Address Space 구조제. AS구조체 내에 as_id와 page_table(물리주소) 필드를 사용

(* 실제 페이지를 바꾸는 처리나 page fault exception의 처리는 microkernel이 수행하지는 않고 "페이저"라는 서버프로그램이 담당)

d. interrupt manager

- system call : intr_register 새로운 디바이스 드라이버 등록, intr_unregister 등록된 디바이스 드라이버 해제

(device가 user mode에서 실행되는 서버프로그램이므로 인터럽트가 들어오면 어느 프로그램인지 알기위해 정보를 관리해야함)

- kernel interrupt handler : 인터럽트가 발생하면 실제 처리는 하지 않지만, 기본적으로 kernel로 올라오므로 등록된 디바이스 드라이버를 IPC로 호충

- 사용하는 자료구조

: IH, interrupt Handler 구조체. kernel_thread_id, device_driver_thread_id 등등

: Interrupt manager는 실제 처리는 안하고 인터럽트 종류와 처리할 프로세스간의 매핑 정보만 저장. 

ex) 인터럽트 5번은 인터럽트 스레드 50번에서 처리해

(-> Interrupt manager는 각 interrupt의 semantics를 알 지 못함, policy를 알지 않는다는 뜻)

# 서버프로그램부분

a. pager : page fault exception을 처리

- user_thread()에서 page fault가 발생하면, ipc_send(pager, faddr) 시스템 콜로 마이크로커널을 통해 pager_thread()에게 전달만 하게함

- pager_thread()에서 ip_receive(user, faddr)로 정보를 전달받음

- pager_thread()에서 kernel에게 as_map(faddr)시스템 콜을 통해 커널이 페이지매핑 요청만 하게함

- 다시 ipc_send(user, _)와 ipc_receive(pager, _)를 사용하여 마무리

b. device driver

- 인터럽이 발생하면 policy를 갖지않는 커널의 인터럽트 핸들러가 호출되어 인터럽트 처리는 하지 않고, irq 커널스레드를 통해서 처리해주는 thread와 맵핑. 실제 ipc 번호를 식별하여 인터럽트 처리 프로그램이 동작하게 됨.

# 결국, 마이크로커널운영체제에서는 모노리틱커널운영체제보다 ipc가 훨씬 많이 사용하게 된다.

4. 성능향상 기술

# 마이크로커널 운영체제에서 IPC

- 모노리틱커널운영체제 : function call

- 마이크로커널 운영체제 : IPC(IPC는 마이크로커널 운영체제에서 성능과 가장 많은 연관성을 가지고있음)

* 1세대의 microkernel은 IPC 성능을 향상시키지 못해 성능이 떨어졌다.

2세대의 microkernel은 IPC성능을 향상시키기위해 다양한 방법이 적용되었다.

현재의 microkernel은 모노리틱 커널과 거의 유사한 성능을 날 수 있음.

# IPC 성능향상 기술

a. Message Direct Transfer

: thread A에서 thread B로 IPC를 전달할 때, 주소공간이 다르므로 중간에 커널주소공간을 거쳐서 message가 복사된다. (2 copies)

-> 1 copy로 전환. Synchronous IPC와 temporary mapping을 사용. 

: 커널은 메시지 복사 전에 thread A의 주소공간 중 메시지가 있는 page를 thread B의 주소 공간에 임시매핑

- thread A의 message를 복사할 때,

- thread A의 message가 있는 page를 Thread B의 특별한 부분에 잠시 임시로 맵핑. 

- 커널이 그 사이 message를 copy

- 임시 매핑 해제

b. Short Message 사용

: 발생하는 수많은 IPC 중 50%-80%가 8bytes 이하의 짧은 메시지

: message를 메모리가아닌 register를 사용하여 zero message 기법으로 메시지 전달을 수행

(register는 어디에서나 접근이 가능하니까..)

c. Direct Process Switching

: thread A에서 thread B로 message전달 시, kernel의 스레드 스케줄러라는 또 다른 thread C가 수행되어 thread를 전환한 후 thread B가 수행됨

(thread A  ->  thread C(kernel의 스레드 스케줄러)  -> thread B)

=> 메시지 send/receive에서 성능저하가 나타남

: thread A에서 메시지 복사 후 스케줄러를 수행하지 않고(스케줄러를 무시하기), thread A의 남은 "time slice" 동안 IPC가 thread B로 컨트롤을 넘겨 thread B를 수행 후 다시 thread B가 thread A에게 메시지를 전달

(thread A  ->  thread B  -> thread A)

5. 마무리

최근에들어 보안의 중요성을 절실히 필요로하는 고신뢰성을 가지는 시스템을 구현하기에 마이크로 운영체제는 최적화되어있으며, 

many core(core가 1000~2000개) 시대가 도래할 것으로 예측되며, 이런 환경에서는 마이크로커널운영체제가 급 부상 할 수 있음