Advanced Operating Systems Structure(1)

개요

Operating System의 목적은 다음과 같다.

• Protection: user와 OS 자체를 보호할 수 있어야 된다.
• Performance: service를 수행하는 데 걸리는 시간을 줄인다
• Flexibility: 확장성을 의미한다. 하나로 모든 것을 맞출 수는 없다.
• Scalability: 하드웨어 리소스가 증가하면 성능도 증가
• Agility: 애플리케이션의 요구사항 및 리소스 가용성 변화에 적응
• Responsiveness: 외부 이벤트에 대한
• 반응성

이러한 요구 사항을 충족시킬 수 있는 OS 구조에 대해서 알아볼 것이다.

OS 구조

Monolithic

Monolithic Structure

가장 단순한 구조이다. 하드웨어는 OS로부터 관리되고, 애플리케이션들, OS 모두 각자의 하드웨어 주소 공간을 가지고 있다. 각자의 주소 공간을 가지고 있다는 의미는 애플리케이션과 OS는 서로 보호되고 있다. 이것을 Protection Domain이라고 부른다. 그래서 대부분의 애플리케이션에서 OS Service(File System, Scheduling, Memory Allocation)를 사용하기 위해서는 System Call 같은 API를 통해서 애플리케이션의 Protection Domain에서 OS Protection 도메인으로 이동해야 한다.
Protection Domain 간의 이동은 Border Crossing 비용이 들어간다. Border Crossing 비용이란 Context Swithch/Data Copy(explicit cost)와 loss of locality(implicit cost) 등이 발생하면서 생기는 비용을 말한다. 예를 들어 Protection Domain 간에는 address space가 나눠져 있기 때문에 직접적으로 접근이 불가능하다. 그래서 애플리케이션에서 발생한 데이터를 가지고 OS Service를 이용할 때, 주소(referrence) 전 방식이 아님 값(value)을 직접 복사해서 전달해야 된다.

DOS-like

DOS-like Structure

MS의 DOS 방식은 App과 OS의 Address를 보호해주지 않는다. 그렇기 때문에 App이 직접 OS Service를 호출해서 사용할 수 있다. 그래서 OS Service 간의 Border Crossing 비용뿐만 아니라 App과 Service 간의 Border Crossing 비용도 들어가지 않는다. 하지만 보호하지 않는다는 의미는 보안에 취약하다는 의미이기도 하다.
초기 PC 시장에서는 보안보다는 성능을 중시했기 때문에 MS는 보안을 버리고, Border Crossing 비용을 줄여서 성능을 올리게 했다. 하지만 현대 일반적인 OS에서는 이러한 방식은 허용될 수 없다.

Monolithic 구조의 장단점

또한 Monolithic 구조에서는 모든 OS Service들이 하나의 거대한 뭉치로 구성되어있다. 애플리케이션은 하나의 System Call을 요청해도 OS 내부적으로는 여러 Service 간의 정보를 주고받아야 할 수 있다. 이런 경우 Monolithic 구조의 Service들은 하나의 Protection Domain으로 구성되어있기 때문에 커널 내부에서 Border crossing에 의한 성능 저하를 줄일 수 있다.
성능을 얻는 대신 잃는 부분도 있다. 하나의 거대한 OS로 구성되어 있다 보니 OS 구성 변경이 거의 불가능하다. 예를 들어 Game과 Coding에 필요한 OS Service가 다른데 사용자에 맞는 Service를 선택할 수가 없는 문제가 있다.

Customization

그렇다면 Customization을 할 수 있는 것은 무엇일까? 이해를 돕기 위해 OS Service 중 메모리 관리에 대한 예를 들어보자. 메모리 관리의 역할 중에 Page Fault를 처리해야 되는 로직이 있다. Page Fault가 발생하면 OS는 아래와 같은 액션을 취한다.

1. 비어있는 Page Frame을 찾는다.
   • 페이지 교체 알고리즘에 따라서 페이지를 찾는다
2.  page fault를 발생시킨 프로세스를 찾아서 page table을 업데이트해준다.
3. 프로세스를 다시 수행시킨다.

위에서 보면 다른 붉은색으로 표시한 부분 외에는 메커니즘으로 해결해야 되는 문제이고, 붉은색으로 표시한 부분은 정책으로 둘 수 있는 부분이다. 메커니즘은 변경이 불가능하지만 정책은 변경 가능하기 때문에 최소한의 메커니즘은 커널 영역에 두고, 페이지 교체 알고리즘 같은 정책은 OS Service로 만들어서 분리할 수 있다.

Micro Kernel

u-kernel Structure

위에서 설명한 구조를 설계하면 u-kernel과 같은 구조로 만들 수 있다. u-kernel은 확장성을 위한 구조이다. 위의 그림은 u-kernel 구조이다. 필수적인 메커니즘은 u-kernel이라는 커널 영역에 두고, 정책에 해당하는 Service들은 커널 위에 두었다. Memory Management Service 가 2가지로 나눠져서 사용자가 어떤 정책을 사용할지 선택할 수 있다.

Performance loss

확장성은 좋아졌지만 Monolithic 구조에 비해서 OS Service를 사용하는데 Border Crossing cost가 여러 번 발생하는 문제가 있다.

정리

feature	Monolithic	DOS-Like	u-kernel
Extensibility		O	O
Protection	O		O
Performance	O	O

위의 표와 같이 각 OS 구조는 각기 다른 장단점을 갖는다 OS가 사용되는 위치에 맞게 적절한 구조를 선택하면 된다. 다음 포스트는 여러 가지 커널에 대한 구조를 알아보면서 Extensibility, Protection, Performance에 대해 어떻게 접근하는지 알아보자.