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

EMT: An OS Framework for New Memory Translation Architectures

noriwiki


EMT: An OS Framework for New Memory Translation Architectures
AuthorSiyuan Chai, Jiyuan Zhang, Jongyul Kim, Alan Wang, Fan Chung,

and Jovan Stojkovic, University of Illinois Urbana-Champaign; Weiwei Jia, University of Rhode Island; Dimitrios Skarlatos, Carnegie Mellon

University; Josep Torrellas and Tianyin Xu, University of Illinois Urbana-Champaign
ConferenceUSENIX OSDI 2025
pdfhttps://www.usenix.org/system/files/osdi25-chai-siyuan.pdf
Year2025



개요

EMT(Extensible Memory Translation)는 리눅스 기반의 메모리 변환(memory translation) 프레임워크로, Radix tree나 Hash table 등 다양한 구조를 사용하는 최신 하드웨어 메모리 변환 방식을 유연하게 지원하도록 설계되었다. 기존 리눅스 메모리 관리 시스템은 새로운 하드웨어 구조를 적용하기 어렵다는 한계가 있었고, EMT는 이러한 확장성 부족 문제를 해결한다. EMT는 아키텍처에 독립적인 인터페이스를 제공하며, 다음과 같은 핵심 기능을 지원한다.

  1. 다양한 메모리 변환 아키텍처(radix tree, hash table 등)에 대한 범용적 대응
  2. 하드웨어 특화 최적화(Hardware-specific optimization)의 지원
  3. 최신 하드웨어 및 OS의 구조적 복잡성에 대한 유연한 수용
  4. 기존 고정형 구현에 비해 성능 손실이 거의 없는 수준의 오버헤드

EMT위에 리눅스 메모리 관리 기능을 포팅한 결과, 확장성을 제공하면서도 성능 저하 없이 기존 시스템과 유사한 효율을 유지할 수 있었다. 또한 EMT는 실험적 메모리 변환 구조인 ECPT와 FPT를 OS에 구현하고 최적화할 수 있는 기반을 제공하였다.

Motivation & Importance

기존 메모리 관리 시스템은 메모리가 작은 시절 개발되었다. 현재 메모리의 크기는 나날이 증가하고 있다. 이 문제를 해결하기 위해서 Hardware 개발사들은 Hasing이나 Elastic Cuckoo Page Table (ECPT)와 같은 기술을 도입하고 있다. 그러나 기존 리눅스 메모리 관리 시스템은 새로운 하드웨어 구조를 적용하기 어렵다는 한계가 있다. 이는 기존 리눅스와 같은 메모리 관리 시스템이 확장성을 고려하지 않고 기존의 Page table walking만을 상정하여 개발하였기 때문이다.

기존의 Mach의 Pmap과 같은 경우에는 Fine-grained한 Memory management customization이 불가능하며, 기존의 몇몇 논문들은 Application-specific page prefethcing이나 replacement policy를 주로 신경 쓰었다. Related work으로 들수 있는 FBMM과 같은 경우에는, VFS를 재사용 해서, memory management를 확장하였지만, radix tree를 사용하는 리눅스의 내부 로직에 의존하여서 본 논문처럼 physical address management를 세밀하게 최적화 하지는 못한다. File system layer는 memory translation을 위한 좋은 abstraction이 아니라고 저자들은 주장한다.

Main Idea

Address Translation을 Abstraction하여서 마치 VFS와 같은 추상화된 API로 커널 개발자에게 제공할 수 있는 프레임워크를 개발하였다. 서로 다른 하드웨어 메모리 관리 기법에 대해서, 커널 개발자들은 마치 디바이스 드라이버를 작성하듯, MMU Driver만 작성하면 된다.

Design

EMT는 기본적으로 Object-oriented기반의 API를 디자인 하였다. 결국 핵심은 Virtual-to-physical address를 어떻게 구현하는가 이기 때문에, 기본적인 Abstracted된 API들은 VA를 PA로 바꾸는 작업에 초점을 맞추어 디자인 되었다. 이 디자인은 Hardware의 구현에 대한 Assumption을 배제하였다. EMT의 함수는 MMU Driver를 작성하는 사람이 반드시 작성해야 하는 API (Basic functions)와 Default implementation이 있지만 추가 구현이 가능한 API (Customizable functions)로 구성하였다.

Basic Functions
Basic functions은 Translation object, Translation database, 그리고 Translation service로 구성된다.
  1. Translation object은 virtual to physical address mapping을 encodding하고 metadata를 설정하는 역활을 담당한다. 예를 들어서 tobj는 dirty bit와 같은 PTE의 비트를 포함하고 있을 수 있다.
  2. Translation database는 실제로 tobj가 저장되는 DB (즉 하드웨어의 저장장치)를 말한다. Page table이 있을 수 있다. Input으로 vaddr를 받아서 output으로 tobj를 내보낸다.
  3. Translation service는 switch가 일어날때 일어나는 역활을 정의한다. 관련 함수들은 EMT오브젝트의 생성이나 삭제와 같은 일을 담당한다. TLB관련 함수들이 그 예시이다.
Customizable Functions
Default implementation이 있지만, 유저가 성능을 위해서 Optimization이 가능한 함수들이다. Linux convention을 따라 매크로로 정의되어 있다. 예시로 page table iterator를 들 수 있다.

그외, Linux에 EMT를 어떻게 구현하였고, 여러가지 다양한 Translation scheme을 어떻게 구현하였는지는 논문을 참고.

Conclusion

우선 논문의 Motivation이 매우 신선하게 느껴졌다. 곰곰이 생각해보면, 왜 하드웨어에서는 계속해서 새로운 주소 변환(Translation) 기법이 등장하는 반면, 리눅스 커널은 이러한 최적화(Optimization)를 적극적으로 반영하지 못하고 있는지에 대한 문제의식은, 평소에는 접해보지 못했던 참신한 시각이었다. 또한, 기존 VFS 레이어와 같은 기존 구조를 확장하는 방식이 아닌, 새로운 추상화 API를 설계해야 하는 이유와 그에 따른 디자인, 성능 평가까지 모두 설득력 있게 전개되었다고 생각한다. 추가로 어떻게 Linux의 복잡한 Memory management layer를 EMT로 재구성 하는 과정에서 큰 Engineering efforts가 필요했을 텐데, 이를 성공적으로 구현하였다.