Proceedings of the 12th USENIX Symposium on Operating Systems Design and Implementation, OSDI 2016 James Litton, Peter Druschel
개요
하나의 프로세스에서 다른 memory, file desriptors, 그리고 access capabilitiy를 가지는 LwC라는 새로운 Protection domain을 만들었다. LwC를 전환하는 것은 kernel thread를 switching하는 것보다 더 빠르게 가능하기 때문에 여러 새로운 기능을 탐구하고, 그리고 기존의 fork로 하던 기능들의 속도를 개선할 수 있었다.
Motivation
Process는 Isolation을 제공하지만, resource accounting, context-swtiching, IPC와 같은 cost를 유발한다. 그런데, process교체시에 발생하는 hardware cost를 매우 적다. 대부분이 system level에서 일어나고 있는 것이다. Thread와 IwC는 Orthogonal하다.
Importance
전통적인 프로세서는 소프트웨어 적인 오버헤드가 너무 심하다. 이를 해결하기 위한 여러 논문들 연구들이 있지만, 이 논문의 Background에서 주장하는 것은 단점들이 존재한다는 것이다. 이를 이 논문에서는 LwC라는 Protection domain을 통해서 해결하였다.
Main idea
Process에서 Memory isolation, execution state 그리고 Privilege관리를 분리한다. 즉, 하나의 프로세서에 여러개의 Execution state를 두고 각각의 Execution state들이 서로를 침범하지 못하도록 하돼, Explicit한 kernel scheduling을 사용하는 것이 아니라, 각각의 LwC들이 thread와 Orthogonal하게 작동하도록 하였다. 스레드와 프로세서사이의 하나의 LwC를 만들었다가 중심 아이디어이다.
Design
이 논문에서는 Design section에서 어떻게 LwC를 Control할 것인지에 대한 내용을 주로 서술하고 있다. LwC의 생성, Priviledge관리 그리고 Context switching을 위한 기본적인 API중심으로 어떻게 LwC가 기존의 Process모델과 다른지를 서술하고 있다. 또한 System call interposition이나 Signal handling처럼 좀더 Specific한 주제들도 다루고 있다.
특히 이 논문은 새로운 디자인을 제시한 것이기 때문에 Usage를 제시하는 것이 중요하여 따로 Section을 제공하였다. 그리고 어떻게 LwC를 Kernel에 효율적으로 구현하였는지도 중요한 정보이기 때문에, Implementation section에 공을 들여서 작성하였다.
Usages
- Fast snapshot and rollback
- Event-driven방식에서 각각의 세션을 분리하기
- 민감한 데이터의 분리
- Reference monitor와 같이 여러 state에 걸치는 시스템의 분리
Implementation
- Memory: TLB flush가 들어가면 매우 느려지는 Workload이다. 그러나 Process context identifier라는 기능으로 인해서 같은 page라도 다른 Page table에 있는지를 구분할 수 있게 되었다. 따라서 LwC는 다른 Page table을 할당하고 PCID를 LwC에 맞게 할당하면 굉장히 빠르게 Memory context를 교환할 수 있다 (이는 Process도 동일하다). LWC_UNMAP으로 마킹된 부분은 복사되지 않으며, LWC_SHARE로 마킹된 부분은 다른 LwC로 같이 공유된다.
- File table: Fork처럼 file descriptor table도 복사된다. 마찬가지로 LWC_UNMAP으로 표시되어 필요하지 않은 Descriptor들은 복사되지 않는다.
- Credentials: UID, Limits와 같은 정보또한 복사된다.
- Permissions and Overlays: A->B->C순서대로 LwC를 생성하면 A>=B>=C의 Overlay를 가지게 된다.
Result
- LwC는 Process scheduling을 위해서 Lock잡고 Synchronization을 할 필요가 없기 때문에 Context change가 굉장히 빠르게 가능하였다. (Kernel thread의 반정도)
- Macro bench(HTTPS)를 이용한 테스트에서는 Kernel thread와 비슷한 경우를 보여준 경우도 있었지만, Process구현과도 비슷한 경우를 보여준 케이스가 있었다.
Contribution
- 기존에는 Priviledge + Isolation + Execution이 하나의 Process라는 Abstraction으로 주어졌는데, 이를 분리하여 어떤 점이 유용할 수 있을지를 분석하였다.
Criticize
- Process에서 scheduling cost가 없어져서 Synchronization을 위한 Overhead가 없어진 것이 빨라지는 이유의 전부처럼 보이도록 서술되어 있거나, 아니면 그런것 같다. 그렇다면 LwC처럼 다 분리하는 것이 아니라 Mandatory scheduling policy를 가지는 Thread만 있으면 되는 것이 아닌가?
- LwC의 성능 분석에 대한 좀더 자세한 내용이 있었으면 더 좋았을 수도 있을 것 같다.
- Usage를 초반에 설명하는 것도 좋지만 Evaluation과 함께 설명하면 더 유기적이지 않았을까? LwC의 사용을 강조하기 위한 용도였을까?