SOSP 2009
개요
현재 대두하고 있는 많은 멀티 코어 시스템에서 OS는 genereal-purpose로 설계되고 있다. 그러나 새로운 하드웨어마다 optimization기술이 모두 다르고 이기종 간의 시스템을 연결할 수도 없어 이런 기존의 전통적인 OS는 장점을 멀티코어 환경에서 효율적으로 동작하지 않는다. 또한 이러한 멀티코어 시스템에서 효과적으로 커널과 프로그램을 작성하는 것은 정말 뛰어난 개발자가 심혈을 기울여서 작업해야 하는 어려운 작업이다. 이 논문의 contribution은 다음과 같다.
- 멀티커널 시스템이란 새로운 컴퓨터 시스템 구조를 제시하였다.
- 시스템이 shared memory 없이 message passing으로도 효율적인 커널을 작성할 수 있음을 보였다.
- 이러한 환경에서 어던 이점이 발생하는지 정리하였다.
motivations
- Linux와 같은 General Purpose OS는 하드웨어 마다 다른 Optimization기술을 적용할 수 없다.
- 코어는 본질적으로 같지 않다. 다른 코어는 다른 Instruction set을 가지기도 하며, 같은 CPU내에서도 서로 다른 코어 기술을 사용하기도 한다.
- 코어 수가 늘어나면서, 코어끼리의 통신이 네트워크화 되었다. 즉 이는 네트워크에서 가지는 문제들 - routing, congestion - 과 같은 문제가 생기게 되었다.
- 코어수가 늘어날 수록 shared memory방법보다 message passing이 오히려 효율적이고 scalability에도 좋다.
즉 Mutikernel에서는 OS구조를 서로 non-shared를 가지는 코어마다의 커널로 생각하고 shared memory가 꼭 필요한 시점에서 message passing으로 데이터를 전달하겠다는 아이디어를 제공하였다.
Multikernel
- 모든 코어들이 shared memory가 아니라 message passing으로 통신하게 한다. (Application Level에서는 Shared memory를 사용할 수 있ㄷ으나 커널에서만 사용하지 못하게 하였다.) 이를 통해서 pipelining 혹은 batching과 같은 기술을 이용하여 다른 코어들과 보다 효율적으로 통신할 수 있다. 또한 이 구조는 코어같의 Isolation과 resource management를 가시적이고 효율적으로 사용할 수 있게 해주었다.
- OS의 구조가 하드웨어와 분리 되도록 설계한다. 이를 통해서 각 코어 혹은 하드웨어중심의 Optimization기술이 OS마다 구현되는 것이 아니라 마치 디바이스 드라이버처럼, Multikernel의 기본적인 설계와 무관할 수 있도록 구현하였다. 이는 서로 다른 하드웨어 기술마다 최적화된 IPC, 혹은 TLB Shootdown과 같은 적절한 Optimziation이 가능하게 한다.
- Kernel state들이 공유되는 것이 아니라, Replicated된 상태 (각 코어마다 복제된상태)로 생각한다. 전통적인 이러한 State들은 Lock을 통해서 consistency를 유지한다. 이러한 업데이트는 non-blocking으로 작동하게 하였다. Replication은 코어간의 interconnection을 없애서, scalability를 올렸다. Replication이 Interconnection을 줄인다는 것은 각 코어마다 구현또한 Replication, Message passing의 API를 일치시키면 다르게 구현가능하다는 말과도 동일하다. 즉 다양한 기법을 사용하여 Core를 효율적으로 사용할 수 있게 해주는 방법이 되기도 한다.
- 이러한 구조는 1. message passing이 async하여 latency예측이 쉽지 않은점, 2. implicit하지 않고 explicit하기 때문에 개발자가 일일이 모든 specification을 작성해야 하는 점이 단점으로 작용한다.
Implementation
- CPU 코어가 각각의 CPU driver로 돌아가게 하며, 각 CPU driver는 커널에서 흔히 보이는 Scheduling, communication, low-level resource allocation과 같은 기능을 구현하여 각각의 드라이버의 통신은 message passgin을 통한 explicit한 기법으로 일어나도록 하였다.
- CPU 드라이버는 다른 코어와 state를 공유하지 않기 때문에, CPU코어는 완전히 event-driven이며, single thread, nnonpreemptable로 돌아가게 된다.
- CPU 드라이버 위에서 User space Monitor가 각각의 코어마다 돌아간다. Monitor은 기존의 Microkernel에서의 커널과 비슷한 역활을 한다. 디바이스 디라이버, 메모리 collection들이 위치하며, Global state와 같은 커널 information또한 여기 모니터에서 유지되고 관리된다. Monitor에서 유지하는, global state들은 모니터 끼리의 message passing을 통해서 replicated된 장소에 유지된다.
- IPC - URPC라는 특별한 RPC를 구현하여 최대한 빠르게 inter process communication이 가능하도록 하였다.
- 각 코어마다 각자의 kernel의 사용하더라도, shared memory 혹은 kernel global state를 보관하기 위해서는 공통된 memory location에 access해야 하는데, 이를 위해서 barrelfish는 capability모델을 통해서 이를 해결하였다. 이 capability는 Monitor가 저장하고 있다, memory allocation같은 것이 필요하면 CPU driver에 전송하여, CPU드라이버가 적절한지를 파악한후 이를 처리한다.