ASPLOS '19: Architectural Support for Programming Languages and Operating Systems
개요
Ingends[1], FreeBSD, Linux의 Huge page allocation은 여러 문제가 있다. HawkEye는 이 문제점을 분석하고, Async page pre-zeroing, De-dupulication of zero-filled pages, Access tracking, Hardware performance counter를 통해서 이를 극복하였다.
Problems and Importance
Background 내용은 Coordinated and Efficient Huge Page Management with Ingens 혹은 Huge Page참고. Ingens와 Linux는 Huge page할당에 있어서 Aggressive하게 할당한다는 문제가 있다. 이 논문은 Problems를 Motivation과 함께 소개 하고 있기에, 추가적인 내용은 Main Idea에 서술하였다.
Main Idea and Contribution
- MMU TCB Miss와 Memory Bloating의 Trade off
- Huge page를 사용하여 TCB overhead를 줄이면 memory bloating이 심해진다. Linux나 Ingens는 항상 혹은 Adaptive하게 Huge page를 Initial time에 할당하도록 하였다. 이럴 경우에는 나중에 Memory bloating을 줄이기 위해서 Demotion하는 단계에서 Initial allocated huge page 부분을 건드릴 수 없기 때문에, Memory bloating을 줄일 수 없는 문제가 생긴다. HawkEye는 이문제를 Initial time에 Allocate한 영역또한 Demotion할 수 있는 방법을 제시하여 해결하였다.
- Page fault Latency
- Huge page page fault는 Zeroing에 들어가는 시간으로 인하여 매우 긴 시간을 소요한다 (97%의 시간이 Zeoring에 소비됨). 이를 해결하기 위해서 미리 Zeoring된 Page를 준비해 두었다가, Huge page allocation 시점에 이를 사용하여 Huge page allocation Latency를 줄였다. 또한 Ingens와 다르게 먼저 4K를 할당하는 것이 아닌 우선적으로 Huge page를 할당하여 Page fault 수를 줄여 Performance 향상을 도모하였다.
- Fairness
- Ingens의 Contiguity모델은 Huge page의 몇몇 base page만 계속해서 Access되는 경우도 전체 Huge page에 Access가 많다고 잘못 측정하는 문제가 있다. 이를 해결하기 위해서 Memoru contiguity가 아닌 MMU Overhead를 Resource로 생각해야 한다고 주장한다. 이러한 MMU Overhead를 측정하기 위해서 HawkEye는 Hardware performance monitor를 이용하여 TLB Overhead를 가져왔다. Hardware performance monitor가 없는 하드웨어에서도 이러한 기능을 사용하기 위해서, Memory access pattern으로 이를 추적하는 모델도 개발하였다. 이러한 TLB Overhead를 통해서 HawkEye는 Fairness에 대한 고려를 하였다. 또한 Ingens나 Linux의 Lower -> Higher VA scanning보다 memory access pattern을 분석하여 제일 Access pattern이 높은 곳 부터 먼저 Promotion하는 방식을 제안하였다.
State of the art은 Ingens와 Real system인 Linux의 Huge page allocation의 단점을 분석하여, 해결방안을 Hardware performance monitoring 그리고 Zero filled page의 특성을 사용하여 해결하고자 노력하였다. Ingens의 단점을 Spot fix로 해결한 논문이다. 기존의 Work들과 중복되는 내용이 많으나, 해결되지 못하였던 몇몇 부분들을 성공적으로 해결하였다는 점에서 의의가 있다.
Design
- Asynchorous page pre-zeroing
- 많은 연구 / 구현에서 하는 것처럼 미리 Zeroing해둔 페이지를 이용하여 Huge page를 Allocation하였다. 장단점은 논문 참고!
- Managing bloat vs performance
- Scan Zero-filled pages
- Huge page demotion에서 Huge page에 Zeoring된 베이스 페이지들이 많을 경우 그 huge page를 Demotion하도록 하였다. 이를 통해서 Initial time에 Allocate된 Huge page들이 Demotion대상에 포함 될 수 있도록 하였다. (즉 Access가 없는 영역은 Demotion시킨다.) 이 작업은 다른 Kernel thread에서 특정 threashold가 넘어가면 수행되도록 하였다.
- Fine-grained Huge page promotion
- Memory access pattern을 Ingens의 Space bit vector와 유사한 Access map을 통해서 측정하여서, 이를 반영하여 Promotion이 이루어 지도록 하였다. 2MB huge page 의 크기를 가진 곳의 임의의 Sample의 Access pattern을 매 30초 마다 1초정도 Access bit을 Sampling하는 과정을 반복하여 Access가 huge page의 어느정도를 차지하는지를 측정하였다. (Ingens는 space allocation만을 측정하였으나 HawkEye는 추가적으로 Time space를 추가하였다.)
- Huge page allocation across multiple processes
- Huge page promotion을 할 Process를 선택하는 과정을 Hardware performance monitoring을 통해서 MMU (TCB) overhead를 가져와, 제일 Overhead가 많은 Process에 우선순위를 주어서 Promotion하도록 하였다.
Criticizing
- Zero-filled pages는 Memory scanning이 필요한데, 성능이 좋아 질 수가 있나? 만약 2MB 할당을 한다음 1나의 base page만 사용하는 W
orkload일 경우 매우 느려질 것 같은데...