- Anderson, E. W. (1995). The performance of the Container Shipping I/O system. ACM SIGOPS Operating Systems Review, 29(5), 229. https://doi.org/10.1145/224057.225831
개요
기존의 시스템에서는 User level에서 사용되는 Resource들은 Scheduling의 단위로 사용하였다. 그러나, Kernel level에서 돌아가는 경우에는 Resource에 대한 Tracking을 제공하지않고 무시하였다. 이 논문에서는 Kernel레벨에서도 User level의 요청으로 인하여 사용되는 Resource들의 대한 점유를 추적함을써 가능한 여러 장점들과 방법을 제시하였다.
Problems and importance
기존의 시스템에서는 하나의 Process가 모든 Resource management의 단위가 되었다. 그러나 Modern?(1995) server에서는 하나의 혹은 적은 수의 프로세스가 한번에 여러 Connection을 가지고 kernel/User thread나 event driven을 통해서 다른 웹 서버와 통신하는 경우가 매우 많다. 이러한 경우 Resource management의 단위가 다르기 떄문에 Application이 Connection에 대한 Priority설정과 같은 Resource management를 불가능 하게 하였다. 또한 이러한 커널 레벨 에서의 처리가 Unlucky process running at the time of the interrupt에서 일어나기 떄문에 정확한 리소스 배분이 불가능하게 된다. 더하여, QoS의 하락과 LiveLock과 같은 여러 버그와 같이 Resource management를 위한 Unit을 Process에서 분리하는 것이 필요하다. 즉 이러한 상황에 대처하기 위해서 user level 그리고 kernel level에서의 resource usage를 모두 추적하는 fine-grained한 Resource management의 방법이 필요하게 되었다.
- Resource principal, independent from other abstractions such as process or thread, that precludes the application control we desire.
Main Idea and contribution
Resource container라는 user level, kernel level의 system resource를 모두 charging하도록 하고, container의 priority에 따라서 스케쥴링이 되도록 하여서 protection domain과 resource management의 domain을 분리하였다.
Design
Resource Container는 cpu가 사용하는 커널 레벨 그리고 유저 레벨에서의 모든 사용량을 측정하면서 스케쥴러에게 Resource container에 할당된 Prioirty와 사용량을 넘겨주어서 적절한 스케쥴링이 일어 날 수 있도록 하였다. 또한 thread, process마다 지정된 resource container가 있는 것이 아니라 적절하게 상황에 따라서 다른 resource container를 사용할 수 있도록 하여서, Resource의 측정을 유연하게 하였다. Resource container는 Hierarchy구조를 이용하여 이루어지도록 하여서, 손쉽게 전체 시스템의 Resource조절을 가능 할 수 있게 하였다.
Implementation
만약 여러 Resource container가 하나의 스레드에 사용되고 있는 상황이라면 잦은 스케쥴링 Policy변경으로 인하여 스케쥴러 성능이 하락될 수 있다. 이러한 문제를 해결하기 위해서 커널은 자동으로 여러 RC의 인자들을 하나로 합쳐서 스케쥴러에 Transparent하게 반영될 수 있도록 Resource container binding을 할 수 있도록 하였다. RC는 CPU뿐만 아니라 메모리나 IO까지 이용내역을 저장할 수 있지만, 이데 따른 Scheduling policy는 구현하지 않았다.
Crticizing
- Transparent한 이용이 불가능하다. 즉, 개념을 위해서 추가적인 Resource container을 위한 API를 새로 적용해야 한다.
- Priority를 어떻게 설정할 것이라는 문제가 있다. 최적의 RC의 Attribute를 설정하는 것도 하나의 문제이다.
- 커널 리소스를 일일이 추적해야 한다는 단점이 있다. 사실 현재 시스템과 같은 경우 kprobe, ebpf와 같은 기법을 통해서 Resource container구현이 가능하다.