| Do-It-Yourself Virtual Memory Translation | |
|---|---|
| Author | Hanna Alam, Tianhao Zhang, Mattan Erez2, Yoav Etsion |
| Conference | ACM ISCA 2017 |
개요
DVMT는 하드웨어 Translation(Page table walking)을 효율적으로 만들 수 있도록 하기 위한 Memory Translation Architecture이다. DVMT는 Virtual to physical mapping을 Decoupling해서, Application이 Mapping을 관리할 수 있도록 함과 동시에, OS가 안전한 Security관리를 하도록 하였다. 또한 EPT에 적용시킬 수 있도록 Stacking이 가능하게 하였다.
Motivation & Importance
Virtual address translation은 보통 page table walking이 4번 (VM은 24번) 일어나기 때문에, TLB Hit rate에 큰 영향을 미친다. 이러한 문제를 해결하기 위해서 Application specific page table translation을 해야할 필요가 있다.
Main Idea
Application이 virtual mapping을 만들 때, 만약 TLB miss가 발생하면, Application이 미리 등록한 VA-to-PA 매핑 정보를 기반으로 helper thread를 호출하여 해당 값을 결정하게 한다. 이로 인해, VA-to-PA를 application 수준에서 customizing할 수 있으며, 결과적으로 application이 적절한 virtual address management를 직접 수행할 수 있도록 한다.
Memory protection과 같은 경우에는 Capability system을 이용하였다. OS가 Application에 허용한 Frame의 토큰을 현재 할당하고자 하는 PA의 토큰과 비교하여 일치하는 경우에만 Mapping이 이루어지도록 하였다.
Design
- Application초기화시에, DVMT는 User-level에서 관리할 연속적인 Virtual address를 지정하여, 하드웨어 레지스터인 DVMT_low와 DVMT_high에 할당한다.
- OS에서 DVMT가 사용할 Physical frame들을 할당한다. OS는 Permission tocken을 생성해서 PMTR이라는 프로세스별 Physical memory token register에 할당한다.
- TLB미스가 발생하면, 하드웨어는 Pending Missing Register(PMR)에 Translation sequence를 저장하고 미리 등록된 DVMT User-level helper thread를 호출한다.
- Helper thread가 Mapping을 처리하고 return값으로 physical address를 리턴한다.
- Hardware는 return된 physical frame의 토큰값을 ID table base register가 가리키고 있는 frame to token array에서 가져와 PMTR과 비교, 동일할 경우에만 TLB missing을 요청된 frame으로 처리하고, 그외의 경우는 page fault로 간주한다.
Conclusion
보통은 하드웨어에서 당연히 처리되어야 한다고 여겨지는 Page Table의 핵심 기능인 VA-to-PA 매핑을 Application 레벨에서 커스터마이징하려는 시도는 그동안 여러 연구에서 다양하게 시도되어 왔다. 이 논문은 그중에서도 VA-to-PA 매핑에서 permission check를 하드웨어 및 OS에 분리 위임하고, Application이 특정한 PA 매핑을 직접 제어할 수 있도록 허용한 점에서 새롭고 흥미로운 디자인을 제시하고 있다고 생각한다.
다만, 본 논문은 TLB hit rate을 향상시키기 위한 다소 특정한 use case에 초점을 맞추고 디자인과 평가를 구성하고 있어서, 이 시스템이 잠재적으로 가질 수 있는 보다 일반적인 확장 가능성이나 다양한 활용 가능성이 충분히 부각되지 못한 점은 아쉬운 부분이다.
또한 하드웨어적으로 capability 시스템을 구성하기 위해 도입한 base ID 구조는 설계 상의 명확성은 있으나, 메모리 오버헤드 측면에서는 추가적인 부담을 초래할 가능성이 있으며, 이에 대한 정량적 분석이 좀 더 보완되면 좋을 것 같다.
Translation thread 관련하여도, 해당 스레드가 PMR을 polling하면서 동작하는 구조라면, 동시 TLB miss 발생 시의 스케일러빌리티 이슈나 CPU utilization 문제를 무시하기는 어려워 보인다. 만약 이 translation thread가 하드웨어적으로 직접 관리되고 실행된다는 의미라면 오버헤드는 다소 희석될 수 있겠지만, 이 경우에도 scheduler 디자인이나 execution model에 대한 보다 구체적인 설명이 병행될 필요가 있어 보인다.
Evaluation에서 Memory overhead에 관한 분석과 DVMT의 하드웨어 & 소프트웨어 스택에 대한 Overhead분석이 없어서, SPEC CPU 2006의 성능 향상히 단순히 메모리를 많이 사용해서 이루어지는 향상인지, 아니면 DVMT의 디자인으로 인하여 발생하는 장점인지 명확한 분석이 필요해 보인다.
마지막으로, 제안된 motivation use case 자체는 흥미롭지만, TLB management 관련 기능을 일부 하드웨어에 통합하는 방식이 오히려 더 간단하고 효율적인 설계로 이어질 수 있지 않을까 하는 의문도 함께 든다.