OSDI 2022
개요
Lightwegith한 커널내 Fork를 만들어서, Auxiliary Task라 불리우는 Process의 sub group을 안전하게 Isolate된 환경에서 돌릴 수 있도록 하였다.
Problems
Application의 task중에서 optimize, examine, debug 그리고 control목적으로 사용되는 task들이 있는데, 그것들을 Auxiliary Task라고 부른다. 만약 Auxiliary Task가 Main process의 자원에 제약없이 접근 가능하다면, Auxiliary Task의 문제가 main 프로세스로 전파된다. 주 이유는, OS에 Process와 Thread사이에 해당하는 Context가 없다는 것이다. 기존 Work들은 이러한 용도로는 부합하지 못하다는 문제가 있었다.
Importance
Auxiliary Task를 기존의 Fork, Process, LwC와 같은 방식으로 구현하게 되면, Main process의 Performance에 영향을 끼치거나, Auxiliary Task의 Bug가 Main Process에 까지 전파되는 문제가 있었다. 이를 해결하면 Auxiliary Task의 구현을 완벽하게 할 수 있다.
Fork와 같은 방식은, Fork시스템콜이 매우 무거운 콜인점과, CoW가 전체 Application에서 이루어 짐으로, Performance degradation이 심해진다는 점, 그리고 Parent process의 상태를 Update할 수 없다는 점이 단점으로 뽑히게 된다. 이러한 문제를 해결하기 위해서는 새로운 Protection domain의 정의가 필요하다.
Main Idea
Auxiliary Task가 Isolated된 domain에서 다른 Task에 대한 Read-only observation만 가능한 새로운 Kernel provided protection domain을 제시하였다.
Contribution
Orbit을 통해서, Auxiliary Task를 구현하게 되면, Fault isolated, Resource isolation 그리고 Performance isolation을 이룰 수 있디. 이를 통해서 Orbit은 Overvability 와 Isolation그리고 Performance 를 동시에 잡을 수 있는 Solution을 제시하였다. 이를 위한 새로운 protection-domain의 정의를 Orbit을 통해서 정의하였다.
Design
- Lightweight Copy-on-write
- Orbit은 분리된 Address space를 가지고 있으며, Orbit에서 Main process의 접근을 위해서라면, orbit_area_alloc이라는 API를 통해서 메모리 영역이 Orbit에 의해서 Mirror되어 있다는 것을 표시해야 한다. 이렇게 표시된 영역은 CoW로 표시되어서, 나중에 Orbit에서 접근하는 경우 최신 CoW를 통해서 snapshot된 메모리 영역을 제공한다. 이떄 만약 CoW과정에서 Page접근을 막기 위해서 kernel에서 Lock을 잡으면 Main application이 느려지는 문제가 발생할 수 있는데, orbit은 이를 Application 으로 delegate함으로써 해결?하였다.
- Automatic State Synchronization
- Orbit area와 같은 Main process와 shared 된 공간은 Kernel에 의해서 자동으로 동기화 된다.
- Modifcation by scratch space
- 때론 Auxiliary task에서 main process의 값을 Update해야 할 수도 있는데, 이를 해결하기 위해서 Privildge가 있는 Orbit은 특정 API를 통해서만 Main process의 값을 바꿀 수 있도록 하였다. Syncrhonization을 위해서 우선 write가 발생하면 scratch page에 먼저 적고, orbit에서 push를 부르고 main에서 pull하는 방식으로 (MVCC), commit되게 하였다.
- First-class Entity
- Orbit의 task방식의 Execution을 지원하며, Orbit을 부른 Main process는 concurrent하게 orbit이 끝날때까지 기다리거나, 아니면 asynchrounous하게 실행시킬 수 있다. 이러한 기능을 제공하기 위해서 Kernel은 여러 Orbit의 Execution을 조절할 수 있는 system call들을 제공하였다.
Criticize
Thread와 Process사이의 간극을 메울 수 있는 새로운 Protection-domain의 개발이다.
우선 Auxiliary Task를 thread가 아니라 Orbit으로 Isolate 해야 하는 이유가 빈약하다. Pthread와 같은 lightweigth thread를 사용하면 안되는 이유가 Isolation말고는 없는 것 같은데, 이게 Valid한 문제일까? Auxiliary Task를 안전하게 만드는 것이 그렇게나 힘든 일인가? Pthread + SFI쓰면 안될 이유가 있을까?
그리고 일일이 Orbit Area를 마킹하는 작업이 필요한데, Shared memory access하는 작업은 Redundant한데 이작업은 쉽다? 이해되지 않는다.
또한 Concurrency를 해결하기 위해서 즉 만약 orbit area가 여러 Main process들이 작업하는 영역이라면 in-consistent한 결과가 나올 수 있는데, 이는 Application에서 lock을 잡는 다는 가정! 하에 해결됨으로 표시하였다. 결국 Fork에서 consistency를 뺀것인데...홍홍
그러나, Process 와 Thread사이의 빈공간을 채운 LwC처럼 Orbit은 Process와 Thread사이의 빈 공간을 Light Weight Fork란 방식으로 채운 아이디어는 흥미로운 아이디어라 할 수 있다. 특히 Auxiliary Task라는 사람들이 조금은 무관심 했을 수도 있는, 그러나 Fault isolation의 domain이 있으면 좋은 부분을 집어내어 그 해결책을 새로운 Protection domain을 통해서 제시하였다는 점이 좋았다. 또한 다양한 Optimization기법들을 소개함으로써, 어떻게 Light weight fork를 구현할지에 대한 고민도 중요한 부분으로 생각된다.