지밍이 블로그

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

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개) 시대가 도래할 것으로 예측되며, 이런 환경에서는 마이크로커널운영체제가 급 부상 할 수 있음

(참고 http://www.turby.net/42)

모니터링

1. CPU

2. Memory

3. Disk I/O

4. Network

# top

: CPU 점유 프로세스들을 실시간으로 조회

(1) 첫번쨰 줄 : 시스템의 전반적 상태. 가동시간, 평균사용량 등

(2) 두번째 줄 : 프로세스들의 상황

(3) 세번째 줄 : CPU 상황

(4) 네번째 줄 : Memory 상황

(5) 다섯번째 줄 : swap 메모리 상황

(6) ~ : 

: 옵션

# htop

: top보다 사용자 위주의 모니터링 도구

$ apt-get -y install htop

$ htop

# vmstat 

: 시스템 작업, 하드웨어 및 시스템 정보. 시스템의 리소스 상황(cpu, I/O, memory) 모니터링

$ vmstat

$ vmstat 3 

$ vmstat 3 2

$ vmstat -m

$ vmstat -a

# iostat

: 평균 CPU 부하 및 디스크 활동

$ apt-get install -y sysstat

$ iostat

# free

# w -

: 시스템에 로그인한 사용자와 프로세스 출력

# ps

2015. 04. 21 김영욱 에반젤리스트 한국마이크로소프트

[Windows 10 preview]

# 라즈베리2지원

# 1년동안 윈7이상인 경우 무상 업뎃가능(개인용만)

# windows 10

- Operating System보다는 platform!

- One Architecture : 바이너리단의 통합

- multi platform 지원

- 반응형 중시

- 유니버셜 지향

.... 졸았다...

# new API

# new Control

1. map

- 지도를 불러올 수 있음

- 업데이트 됨

2. Relative Panel

- 철저하게 상대좌표로 사용할 수 있음

3. App Services? 

: 두개의 앱이 통신하려면 백그라운드에서 서비스를 호출해서 앱사이를 연결하는 무언가가 생김

클라우드 단이 아닌 윈도 내부적으로 생김 

엔터프라이즈에서 사용할 만한 기능

"Think 'Web Services on device'"

- 시나리오 : 바코드를 스캔한다. 바코드 컨트롤이 데이터를 읽고 백그라운드에서 바코드를 디코딩하는 앱서비스를 만들어 동작하고 앱은 가볍게 동작!

- 엔터프라이즈 시나리오 : ERP솔루션의 경우 하나의 프로그램안에 모든기능이 많아,, 굉장히 무거워. 
        필요한 기능을 하나씩 떼어놓는게 필요. 이 과정중에 중복된 기능들이 많이 생기게됨. 이때 앱서비스로 만들고 앱서비스를 호출하여 사용하도록             구조를 바꾸어 사용한다.

- 앱서비스를 디버깅시에는 프로젝트 속성에서 반드시 해당내용과 관련된 체크박스를 확인해야한다!

# Ap Service Lifetime

: 지속적으로 늘어나는 앱서비스를 관리하기위해 lifetime 개념을 도입

: 평소에는 올라오지 않고 대기모드로 suspend되어있다가, 호출할 때만 올라옴.

   계속안쓰면 terminate됨

# Protocol

: Rest 기반의 웹기반 프로토콜을 사용

# Action Center & Quick actions

: 유니버셜앱이기때문데 어디서나 동일한 방법으로 앱을 사용할 수 있도록 지원

: 액션센터경우, 최장7일 앱당 20개의 notifications.

# XAML Transform3d

: 2d인데 3d처럼 보여준다. UX, UI 적용 가능함

좌표계가 (x,y,z)가 있어서 마치 3d인것처럼 계산한다.

이럴 때, 연산이 굉장히 많이 생기므로 내부적으로 gpu를 사용하도록 되어있다.

depth(z좌표)이용, 6번그림

--------------------------------------------------------------------

[브라우저]

# 기존의 브라우저에서는 많은 기능들이 들어있었다.

# 스파르탄은 다 빼서 엄청 가볍다.

# 유니버셜 앱. 어느 기기에서든 다 돌아간다. 기존앱에서의 호환성에대한 고민은?

사용자입장이 아닌 개발자입장에서의 스파르탄이 의미?

- 최신브라우저로의 업데이트에 포인트가 맞춰지고, 표준화를 지향한다.

# new feature

# Hosted Web Apps

- 하이브리드웹

---------------------------------------------------------------------

차주를 더 기대해주세요.

4/29~5/1 www.buildwindows.com에서 라이브이벤트

[Trouble shooting] ubuntu 디스크 늘리기(ESXi기반의 VM)

디스크를 새로추가하지 않고 기존의 디스크의 용량을 늘린다.
(주의)스냅샷이 있는 경우에는 늘려지지 않음

1. 디스크용량 확인
$ df -h

2. VM 종료 후 설정에서 DISK 추가

3. gparted
$ apt-get install gparted
$ sudo gparted
- 증설된 공간에 disk 추가하기
- gparted 닫기

4. lvm 추가
$ vgdisplay
$ fdisk /dev/sda
> p (확인,  *controller-vg)
> q (종료)
$ pvcreate /dev/sda4 (논리볼륨을 추가하기위해 pvcreate)
$ pvdisplay

$ vgextend controller-vg /dev/sda4 (controller-vg 확장)
$ lvextend /dev/controller-vg/root -l +100%FREE(논리볼륨확장)
$ resize2fs /dev/controller-vg/root (파일시스템을 파티션 크기에 맞추기)
$ df -h (확인)

참고.
http://lovevirus133.tistory.com/65