메뉴 여닫기
환경 설정 메뉴 여닫기
개인 메뉴 여닫기
로그인하지 않음
지금 편집한다면 당신의 IP 주소가 공개될 수 있습니다.

Arrakis: The Operating System is the Control Plane

noriwiki
Ahn9807 (토론 | 기여)님의 2025년 1월 2일 (목) 07:52 판 (새 문서: 분류: USENIX OSDI Arrakis: The Operating System is the Control Plane Simon Peter, Jialin Li, Irene Zhang, Dan R. K. Ports, Doug Woos, Arvind Krishnamurthy, and Thomas Anderson, University of Washington; Timothy Roscoe, ETH Zürich == 개요 == Arrakis는 전통 적인 커널의 역활을 Control plane과 Data plane으로 분리하여서, Customized data plane operation이 가능하도록 하여, Application의 성능을 올릴 수 있도록 하는 새로운 Kernel Des...)
(차이) ← 이전 판 | 최신판 (차이) | 다음 판 → (차이)


Arrakis: The Operating System is the Control Plane
Simon Peter, Jialin Li, Irene Zhang, Dan R. K. Ports, Doug Woos, Arvind Krishnamurthy, and Thomas Anderson, University of Washington;
Timothy Roscoe, ETH Zürich

개요

Arrakis는 전통 적인 커널의 역활을 Control plane과 Data plane으로 분리하여서, Customized data plane operation이 가능하도록 하여, Application의 성능을 올릴 수 있도록 하는 새로운 Kernel Design principle을 제공한 논문이다.

Motivation

점차 하드웨어의 성능이 빨라지고 있고, 이에 따라서 오버헤드의 큰 부분을 차지하는 커널의 Data path를 Optimization하고자 하는 노력이 심화되고 있다 (2012년도 기준). 이에 따라서 다양한 Optimization work들이 나오고 있지만, 제각기 Linux커널에 패치가 반영되는등, Generality를 위한 OS의 디자인 Concept과는 거리가 멀다.

Main Idea

거의 대부분의 I/O operation에서 Kernel data path를 없앤다. 또한 없애는 과정에서 Application이 전통적인 OS와 같은 Security model을 가지도록 신중히 Design을 한다. Arrakis는 다음의 Design goal을 목표로 하였다.

  • Minimize kernel involvement for data-plane operations
  • Transparency to the application programmer: POSIX API를 Transparently하게 Support하여서 Legacy Application도 대응하도록 한다.
  • Appropriate OS/hardware abstractions: Arrakis의 API는 다양한 I/O 패턴에 대응할 수 있도록 Flexible하여야 하며, Scale well해야 하고, Locality와 load balance와 같은 Application의 요구에도 대응할 수 있어야 한다.

Challenge

Design

Overview
Arrakis는 SR-IOV와 같은 하드웨어 가상화를 지원하는 디바이스를 요구한다. 이러한 디바이스는 Control plane이 각 가상화된 device instance들을 분리된 protection domain에 할당할 수 있도록 한다. Application은 제공된 virtual device를 통해서 커널과의 상호작용 없이 각 virtual device에 접근한다. Arrakis는 user-level library를 통해서 I/O stack에 접근할 수 있도록 하였다. virtual device는 서로 isolation되어 있기 떄문에 각 Application은 library를 통해서 스스로에게 최적화된 data-path를 구성할 수 있다. Sharing을 위해서 global naming system을 제공하였다. 즉, Application은 데이터에 대한 접근 방식을 관리하고, Kernel즉 Control plane은 naming과 coarse-grain allocation을 기존의 directory와 file system을 통해서 제공한다.
Hardware Model
Hardware independent layer를 만드는 것이 중요한 Challenge중에 하나이다. 이를 위해서 Arrakis는 하드웨어가 특정 규칙에 따라서 Input을 virtual (network/storage/...) interface card간의 multiplexing이 가능하다고 가정하였다. 각각의 VIC들은 DMA버퍼를 통해서 User-space와 Queue방식으로 통신한다 가정하였다. Control plane은 transmit과 receive filter의 configuration을 조정하여서 multiplexing policyBandwidth limit을 결정한다.
Control Plane Interface
핵심이 되는 Abstraction을 VIC, doorbell, filter, VSA, 그리고 rate specifier로 구성하였다. Application은 VIC을 생성하여 doorbell을 특정한 VIC의 특정한 event에 대해서 설정할 수 있다. doorbell은 IPC end-point로 Application에게 Packet arrival이나 I/O completion과 같은 event에 대한 event handler로 작동한다. Filter는 type(송신/수신으로 구성)과 predicate(IP Address와 같은 Specific data)로 구성된다. Filter는 기존 커널이 담당하던 Network packet multiplexing을 flexible하게 구현할 수 있도록 한다.
File Name Lookup
핵심이 되는 Abstraction인 File naming을 Data plane에서 분리하기 위한 디자인이 서술되어 있다. Application은 자신이 사용하는 file과 directory name을 커널의 Virtual file system을 통해서 export할 수 있다. 외부 Application이 VFS를 통해서 접근하면 Operation은 mount한 Application의 내부에서 직접 커리된다. 접근은 크게 3방식으로 할 수 있다. POSIX를 이용한 default방식, 전체 VIC에 접근하는 방식, 그리고 mount한 Application이 특정한 format으로 export하는 방식이다. 이를 통해서 대부분의 접근인 POSIX를 transparent하게 허용하여서 쉽게 사용할 수 있도록 하였다.

이외, Network와 Storage API에 대한 specification은 논문의 Design섹션을 참조.

Implementation

  • Barrelfish multicore OS코드에 33,786라인의 코드로 구현하였음

Result

Conclusion

SR-IOV혹은 IOMMU와 같은 Operating system과 Application에 가상화를 제공하는 특수한 기능을 지닌 하드웨어를 사용해야 한다는 단점이 있다. 또한 기능이 특정한 하드웨어가 제공하는 Feature들에 의존적이라는 단점이 있다. 그러나 I/O스택을 어떻게 User-level application에 bypass하는 효율적인 매커니즘을 제공하느냐의 문제를 OS Design과 Control plane, data plane으로 나누어서 디자인한 점이 큰 Contribution point로 보인다.