CBMM: Financial Advice for Kernel Memory Managers

Ahn9807 (토론 | 기여)님의 2023년 2월 3일 (금) 11:46 판 (새 문서: 분류: 시스템 논문 USENIX ATC 2022 == 개요 == 기존의 시스템은 High-quality information이 MM policy에 사용되지 않았으며, User-space의 cost benefit을 고려하지 않은 MM Allocation 정책 그리고 그러한 Policy들이 커널의 여러 부위에 난잡하게 있어, Debugging과 유지 보수가 어렵다는 단점이 있었다. CBMM(Cost-based memory management)은 철저의 cost-benefit 모델에 의거하여, user space의 이익을 극대...)
(차이) ← 이전 판 | 최신판 (차이) | 다음 판 → (차이)


USENIX ATC 2022

개요

기존의 시스템은 High-quality information이 MM policy에 사용되지 않았으며, User-space의 cost benefit을 고려하지 않은 MM Allocation 정책 그리고 그러한 Policy들이 커널의 여러 부위에 난잡하게 있어, Debugging과 유지 보수가 어렵다는 단점이 있었다. CBMM(Cost-based memory management)은 철저의 cost-benefit 모델에 의거하여, user space의 이익을 극대화 하는 방법으로 Policy를 수립해야 함을 다양한 방식을 통해서 보여주고 있다.

Problems and Importance

Datacenter와 같은 경우에는 Application마다 요구하는 특성이 모두 다 다르다. 그러나 기존의 Huge page policy들은 이러한 특성들을 모두 한번에 만족시켜 주지 못하였다. 특히 다음과 같은 이유가 Huge page가 broad하게 사용되는 것을 막고 있다.

Information-poor environment
Page allocation을 위해서 수집하는 정보의 양과 질이, 그 정보를 얻기 위해서 희생하는 CPU Utilization보다 매우 떨어진다. 특히 Huge page가 Workload의 성능 향상에 영향을 미치는 정도는 Workload마다 너무 달라서, 제한된 정보로는 성공적으로 Huge page의 Impact를 측정할 수가 없다.
Ignore the cost of MM operations
MM operation을 수행하기 위해서 필요한 Cost를 생각하지 않고, MM operation의 특정 성능 향상 만을 위해서 사용하도록 디자인 되어 있다. 예를 들어서 Huge page를 사용하여 MMU overhead를 줄이는 작업은 큰 Initial latency [math]\gt 10^6[/math]를 가져온다. 또한 Allocator가 어떠한 조건에서 (예를 들어, Memory compaction을 진행하는지, Prezeroed page에서 메모리를 가져오는지, Shared page인지, Fallback Algorithm이 동작했는지... 등등) Memory allocation을 하는지도 Performance에 큰 영향을 미치는데 이러한 고려가 기존 Work에는 존재하지 않았다.
Implementation
기존의 Huge page MM들이 커널의 여러 부위에 난잡하게 퍼져있어서, 행동을 예측하기가 힘들고 결과를 해석하기도 힘들며, Debugging또한 매우 비효율 적이다.

Main idea and Contribution

CBMM은 Extimator란 커널의 Memory policy를 처리하는 모델을 제시하였다. Estimator는 기존의 Linux kernel의 Policy코드와는 다르게 여러 Information들을 철저하게 Cost와 Benefit을 분석하여 Policy에 반영하는 모듈이다. Estimator는 통계적으로 수집된 Application의 상태, Application의 현재 정보, 그리고 Offline에서 수집한 Cost와 Benefit정보를 사용하여 MM policy에 적용하였다. 이를 통해서 CBMM은 Consistent한 (즉 Universal하게 적용가능한) Memory management모델을 수립할 수 있었다.

Design

Estimator
CBMM,에서 Policy decision이 필요할 경우, MM subsystem은 명시적으로 Estimator를 현재 진행하려는 Operation의 정보와 함께 호출한다. Estimator는 받은 Operation이 현재 Application과 Kernel의 상태에 의거하여 어떤 Cost와 Benefit을 가지는지 분석하여 결과를 내보낸다. Memory policy decision이 하나의 장소에 이루어지도록 하여서, performance debugging과 Model development가 쉽게 이루어지도록 할 수 있었다.
Cost and Benefit Model
CBMM의 Policy결정은 Estimator가 내리는 Cost and Benefit모델을 따른다. Cost and Benefit Model은 Offline (Preloaded Profiles), Online information과 Application State들을 종합적으로 검토하여 내려지게 된다. Estimator의 Cost and Benefit Model은 쉽게 수정가능하며, 점진적인 개선이 이루어 질 수 있도록 디자인되어 있다.
Preloaded Profiles
Application마다 Huge page를 사용하였을 경우에 얻는 이득이 매우 다르기 때문에, Process의 Memory Policy에 관한 요구사항을 파일로 미리 Application Loading에 전달 받아서, Memory management에서 사용하였다.

Criticizing

  1. Profile이 어떻게 작성되어서 어떻게 성능향상을 미치는지 설명이 부족하다
  2. 성능향상의 원인이 자세히 설명되어 있지 않다. Profile때문인지, Cost and Benfit Model인지, Reduced Fall-back때문인지, 벤치미크와 이유 설명이 필요하다
  3. Profile이 너무 불편하며, Generous하지 않다. 성능 향상의 큰 원인이 Profile때문인것 같은데, 파일을 보니, 각 Memory address range마다 어떤 방식으로 Allocation할지를 Manually 적어 놨다. 이것의 성능 향상 폭에 어떠한 영향을 미치는지 확인해 봐야 할 것 같다.
  4. Profile automatically generation이 매우 힘들것 같은데, 어떻게 할지 적어두지 않았다.
  5. Contribution point가 적어 보인다. Estimator가 들어옴으로써, Cost and benefit model은 자연스럽게 생기는 것이고, Profile은 설명도 부족하고 장점이 크게 보이지 않아, Contribution point를 보강하였으면 한다.