일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- Python
- namespace
- docker
- 재테크
- MongoEngine
- built-in
- Linux
- 하나머니
- python3
- 리뷰
- 도커
- 토스카드
- 실사용
- MongoDB
- aws codecommit
- codecommit
- Container
- docker network
- VPC
- DocumentDB
- 포인트앱
- mininet
- 후기
- S3
- clone
- 커피머니불리기
- 앱테크
- network
- AWS
- 리워드앱
- Today
- Total
ㅍㅍㅋㄷ
Windows OS model : Microkernel or Monolithic kernel? 본문
1. Operating system model : kernel mode and user mode
대부분의 운영체제에서와 마찬가지로 Windows 또한 kernel 모드와 user 모드로 나뉘어진 OS 모델을 갖추고 있다.
kernel 모드는 모든 시스템 메모리와 CPU instruction에 접근이 허가되며, user모드에서는 접근이 제한된다.
이렇게 나눈 이유는 user application이 중요한 운영체제 데이터에 접근하지 못하게 하기 위함이다.
만약 user application 코드를 통해 모든 system instruction에 접근이 가능하다면?
오작동을 유발하는 application이 시스템 전체에 악영향을 끼치는 사태를 막을 방법이 없을 것이다. 또한 악의적인 시스템 코드 수정을 보호할 수 없을 것이다.
그렇다면 일반적인 user application이 전혀 하드웨어 리소스에 접근할 방법이 없다는 것인가?
2. System service call
user application이 하드웨어 리소스에 접근이 필요로 할때, 반드시 user mode에서 kernel mode로 레벨이 변경이 되어야만 접근이 가능하다.
여기서 user mode에서 kernel mode로 변경되는 과정을 system service call이라 부른다.
( 이러한 mode 변환은 context switch가 아니다. system service call이 실제 thread scheduling에 영향을 끼치지 않기 때문이다. )
즉, user mode의 application이 시스템 서비스를 호출할 때 프로세서는 호출을 trap하고 호출 thread를 kernel 모드로 전환한다.
시스템 서비스가 완료되면 운영체제는 thread context를 다시 user 모드로 변경하고 호출자가 계속 실행되게 한다.
여기서 OS achitecture의 중요 point가 있다.
" 과연 어디까지를 kernel 단으로 수용해서 설계하는 것이 좋은 설계일까 ? "
이것과 관련되서 두가지 커널 설계 관점이 있다.
바로 Micro kernel 과 Monolithic kernel 이다.
3. Microkernel
1970년경에 발명된 microkernel은 다양한 OS서비스를 kernel에서 꺼내 user mode로 옮긴다는 아이디어를 토대로 한 kernel 설계 방식이다.
즉, Kernel은 Memory 관리, Scheduling, 기본적인 IPC등 최소한의 가장 core한 부분만 담당을 하며, 나머지 처리는 모두 user 영역에서 모듈 형태로 개발하여 덧붙이는 방식으로 개발되었다.
이러한 microkernel 방식은 kernel의 경량화로 인해 그만큼 커널 소스를 유지하기 쉬웠으며, 유연한 확장과 포팅이 쉽다는 것이 큰 매력이었다.
하지만 microkernel의 단점은 시스템이 발전할수록 극명하게 드러나기 시작하였다.
위에서 언급했듯이 microkernel은 많은 기능들이 user 영역에서 동작하였고, 이 모듈들 간의 통신은 모두 message passing 방식을 이용하였다.
이는 시스템의 복잡도가 증가할 수록 overhead가 급격히 증가하는 결과를 낳았고, 결국 성능 저하라는 단점으로 이어졌다.
( 대표적인 예가 Mach 라는 운영체제였다. )
또한 시스템 복잡도가 증가할수록 시스템 설계의 복잡도로 인해 deadlock에 빠질 위험이 그만큼 높아짐을 의미하였다.
순수한 microkernel design의 상용화는 비현실적이었다.
4. Monolithic Kernel
microkernel과 반대의 개념인 monolithic kernel은 핵심적인 기능 이외에도 시스템 운영에 필요한 많은 서브 루틴들을 kernel 내부로 포함하도록 설계된 방식이다.
이러한 방식은 kernel의 크기를 상대적으로 커지게 만드는 단점이 있지만, 시스템 자원을 보다 효율적으로 관리할 수 있게 하였으며, 시스템콜을 통하여 kernel을 이용함으로 microkernel에 비해 빠른 성능을 보였다.
현재 가장 많이 쓰이는 운영체제인 UNIX와 Linux 또한 이 Monolithic kernel 방식으로 설계된 운영체제이다.
[ Monolithic kernel 과 Microkernel 비교 ]
5. Windows : Microkernel or Monolithic kernel ?
그렇다면 Windows Kernel은 Microkernel 일까, Monolithic kernel 일까?
초기 NT 커널이 개발될때(1987) Microkernel architecture를 따라 개발 되었다.
그래서 초기 설계에 따라 많은 부분이 Microkernel 과 비슷한 방식으로 design되어 있다.
하지만 성능에 영향을 끼치는 많은 코드( 파일시스템, 네트워킹, 메모리 관리 등)를 커널 모드에서 실행되도록 한 점은 Microkernel 보다는 Monolithic kernel 방식을 닮아 있다.
Windows internals 라는 책을 보면, 위에서 설명한 바와 같이 순수한 Microkernel architecture와는 다른 방식으로 설계되었다고 나와 있으며 ( 이유는 간단하다. 너무 비효율 적이라서.. ) Wikipedia에서는 이와 같은 kernel 설계 방식을 Hybrid kernel 이라고 소개하고 있다.
[ Windows 2000 kernel architecture ]
[참고]
Windows internals 5th edition, Mark Russinovich
http://blogs.msdn.com/b/noenemy/archive/2009/05/21/kernel-mode-vs-user-mode.aspx
http://www.joinc.co.kr/modules/moniwiki/wiki.php/man/12/microkernel
http://en.wikipedia.org/wiki/Microkernel
http://en.wikipedia.org/wiki/Hybrid_kernel
'IT > Windows' 카테고리의 다른 글
Windows 환경에서 32 bit 와 64 bit (1) | 2015.07.14 |
---|