238 lines
13 KiB
Markdown
238 lines
13 KiB
Markdown
---
|
|
id: e80853fa-98b8-4cc3-a2df-427c7147794b
|
|
kind: CONCEPT
|
|
slug: page-fault-layers-in-a-vm
|
|
title: VM 에서 page fault 는 세 계층에서 따로 일어난다
|
|
topic: memory-virtualization
|
|
topicName: 메모리 가상화
|
|
project: virtualization
|
|
status: 초안
|
|
basisVersion: x86-64 Intel EPT 기준의 second-stage translation · Linux Guest/Host kernel 의 page fault 처리 · AMD 는 NPT 계열로 대응
|
|
studio: "https://hyeonworks.com/studio/documents/e80853fa-98b8-4cc3-a2df-427c7147794b/edit"
|
|
assets:
|
|
- key: page-fault-layers-in-a-vm
|
|
file: ../../../final/assets/diagrams/page-fault-layers-in-a-vm/page-fault-layers-in-a-vm.svg
|
|
sourceRevision: no-commit · 밖에서 반입한 문서 한 편. 고정할 저장소 리비전이 없다
|
|
source:
|
|
- final/document.md#35-tlb-주소-변환-결과의-cpu-cache
|
|
- final/document.md#45-guest-page-fault
|
|
- final/document.md#46-page-fault의-대표적인-원인
|
|
- final/document.md#47-ept-violation
|
|
- final/document.md#48-guest-page-fault와-ept-violation-비교
|
|
- final/document.md#49-host-page-fault도-별도로-존재한다
|
|
- final/document.md#82-핵심-claim-registry
|
|
- final/document.md#86-문제를-진단할-때의-분류
|
|
---
|
|
|
|
# VM 에서 page fault 는 세 계층에서 따로 일어난다
|
|
|
|
가상 머신 안에서 메모리 접근이 완료되지 못하면 그 사건을 받는 곳이 셋이다. GVA(Guest Virtual Address)를 GPA(Guest Physical Address)로 바꾸는 첫 단계에서 막히면 Guest Page Fault 가 나서 게스트 커널이 처리한다. 그 GPA 를 HPA(Host Physical Address)로 바꾸는 두 번째 단계에서 막히면 EPT Violation 이 나고, VM Exit 뒤 KVM 이 받는다. QEMU 도 호스트의 일반 프로세스여서 자기가 마련한 메모리에 대해 Host Page Fault 를 따로 겪는다. 이름이 모두 fault 라 한 덩어리로 읽히지만 일어나는 단계도 처리하는 쪽도 다르고, 셋 중 어느 것이 늘었는지에 따라 볼 지표가 갈린다.
|
|
|
|
## 관계
|
|
|
|
- **Guest 메모리 주소가 물리 RAM 에 닿기까지 — GVA · GPA · HPA**
|
|
정상일 때 접근이 어떤 경로를 지나는지를 그 글이 세운다. 이 글은 그 경로가 완료되지 않을 때를 맡는다.
|
|
- **Host 메모리 압박이 Guest 와 스토리지까지 내려가는 경로**
|
|
호스트 쪽 fault 가 늘어나는 배경인 reclaim 과 swap 을 그 글이 다룬다.
|
|
- **게스트 page fault 증가는 workload 변화를 따라가는가**
|
|
게스트 쪽 fault 지표를 이 호스트에서 재는 질문이다. 이 글은 원인 분류까지만 적었다.
|
|
- **호스트 major fault 와 스토리지 지연은 같은 시간축에서 함께 움직이는가**
|
|
호스트 쪽 major fault 와 스토리지 지연을 같은 시간축에 놓는 질문이다.
|
|
- **메모리 증상 하나로 계층을 단정하지 않는다**
|
|
이 세 갈래가 그 기준이 요구하는 계층 구분을 만든다.
|
|
|
|
## 본문
|
|
|
|
<!-- body:start -->
|
|
|
|
## TLB Miss 와 Page Fault 는 다른 사건이다
|
|
|
|
주소 변환 결과는 CPU 의 TLB(Translation Lookaside Buffer, 주소 변환 캐시)에 담긴다. 거기에 찾는 변환이 없으면 TLB Miss 가 나지만, 그것으로 접근이 실패하지는 않는다.
|
|
|
|
```text label="TLB Miss 가 났을 때"
|
|
TLB에 translation cache가 없음
|
|
↓
|
|
Page Table을 조회
|
|
↓
|
|
정상 mapping 존재
|
|
↓
|
|
계속 실행
|
|
```
|
|
|
|
Page Fault 는 조건이 다르다. 페이지 테이블 상태로는 지금 접근을 정상으로 끝낼 수 없어서, 커널이 끼어들어 페이지를 마련하거나 매핑을 고쳐야 명령을 다시 시도할 수 있다. TLB Miss 는 테이블을 한 번 더 읽으면 풀리는데, 이쪽은 커널 처리를 부른다.
|
|
|
|
## 첫 번째 단계 — Guest Page Fault
|
|
|
|
이 fault 는 GVA 를 GPA 로 바꾸는 첫 번째 변환 단계에서 일어난다.
|
|
|
|
```text label="첫 번째 단계에서 접근이 완료되지 못할 때"
|
|
GVA
|
|
↓
|
|
Guest Page Table
|
|
↓
|
|
현재 접근을 완료할 수 없음
|
|
↓
|
|
Guest #PF
|
|
↓
|
|
Guest Kernel Page Fault Handler
|
|
```
|
|
|
|
게스트 프로세스가 아직 물리 페이지가 붙지 않은 가상 메모리 영역에 처음 접근하면 이 사건이 난다. 게스트 안의 Keycloak 을 예로 들면, 새 영역의 첫 접근에서 fault 가 나고 게스트 커널이 페이지를 확보해 매핑을 갱신한 뒤 명령을 다시 시도한다.
|
|
|
|
```text label="Guest 프로세스가 새 영역에 처음 접근할 때"
|
|
Keycloak
|
|
↓
|
|
새 Virtual Memory 영역에 첫 접근
|
|
↓
|
|
Guest Page Table
|
|
↓
|
|
현재 usable physical mapping 없음
|
|
↓
|
|
Page Fault
|
|
↓
|
|
Guest Kernel
|
|
↓
|
|
Page 확보 / mapping 갱신
|
|
↓
|
|
Instruction 재시도
|
|
```
|
|
|
|
이 사건 자체가 프로그램 오류를 뜻하지는 않는다. 정상적인 메모리 관리에서도 늘 일어난다.
|
|
|
|
## Guest Page Fault 를 부르는 다섯 가지
|
|
|
|
원문은 대표적인 원인을 다섯으로 나눈다. 앞의 넷은 커널이 처리해 실행이 이어지고, 마지막 하나만 프로세스로 신호가 간다.
|
|
|
|
| 원인 | 게스트 커널이 무엇을 하나 |
|
|
|---|---|
|
|
| Demand Paging | 아직 물리 페이지가 필요하지 않았던 영역에 첫 접근이 오면 페이지를 준비한다 |
|
|
| Swap-in | 필요한 페이지가 게스트 RAM 에 없으면 게스트 swap 에서 읽어 RAM 을 복원하고 페이지 테이블을 갱신한다 |
|
|
| Permission Fault | 읽기 전용 페이지에 쓰기가 들어오는 접근을 걸러 낸다 |
|
|
| Copy-on-Write | 쓰기에서 난 fault 를 의도적으로 이용해 페이지를 복제하고 쓰기 가능한 매핑을 새로 만든다 |
|
|
| Invalid Access | 정상 매핑으로 해결할 수 없는 접근이면 `SIGSEGV` 등으로 이어질 수 있다 |
|
|
|
|
권한이 fault 를 부르는 까닭은 페이지 테이블 엔트리가 매핑만 담고 있지 않기 때문이다. 같은 엔트리에 읽기·쓰기·실행 권한이 함께 들어 있다.
|
|
|
|
```text label="Page Table Entry 에 함께 들어 있는 값"
|
|
Physical Frame: 1234
|
|
Present: 1
|
|
Writable: 0
|
|
Executable: 0
|
|
```
|
|
|
|
이 엔트리로 매핑된 페이지에 쓰기가 들어가면 fault 가 날 수 있고, Copy-on-Write 는 그 성질을 거꾸로 이용해 쓰기가 들어온 순간에만 페이지를 복제한다. 다섯 가운데 Invalid Access 만 결과가 다르다. 게스트 커널이 정상적인 매핑으로 해결할 수 없는 접근이면 `SIGSEGV` 로 이어질 수 있고, 그래서 Page Fault 와 Segmentation Fault 는 같은 것이 아니다.
|
|
|
|
## 두 번째 단계 — EPT Violation
|
|
|
|
이번에는 게스트 페이지 테이블 변환이 성공해 GPA 까지 얻었다고 하자. 그런데 그 GPA 에 대한 두 번째 단계 접근을 지금 EPT(Extended Page Tables) 조건으로 끝낼 수 없으면 EPT Violation 이 된다.
|
|
|
|
```text label="Guest 변환은 성공했는데 second-stage 에서 막힐 때"
|
|
GVA
|
|
↓
|
|
Guest Page Table
|
|
↓
|
|
GPA ← Guest translation 성공
|
|
↓
|
|
EPT
|
|
↓
|
|
EPT Violation
|
|
↓
|
|
VM Exit
|
|
↓
|
|
KVM
|
|
```
|
|
|
|
게스트 안에서는 첫 단계가 정상으로 끝났으므로 게스트 커널의 fault 처리기가 이 사건을 보지 않는다. 제어권이 VM Exit 으로 VMX(Virtual Machine Extensions) Root 쪽으로 넘어가 KVM 이 처리한다.
|
|
|
|
## 두 사건이 갈리는 다섯 항목
|
|
|
|
| 무엇을 견주나 | Guest Page Fault | EPT Violation |
|
|
|---|---|---|
|
|
| 문제 위치 | GVA → GPA | GPA → HPA |
|
|
| 관련 테이블 | 게스트 페이지 테이블 | EPT |
|
|
| 기본 관점 | 게스트 가상 메모리 | 가상화 메모리 매핑 |
|
|
| 주요 처리 계층 | 게스트 커널 | VM Exit 후 KVM 쪽 |
|
|
| 앱 오류를 뜻하는가 | 반드시 아님 | 반드시 아님 |
|
|
|
|
Guest Page Fault 는 게스트가 자기 가상 메모리를 처리하는 사건이고, EPT Violation 은 두 번째 단계 가상화 변환에서 하이퍼바이저 처리가 필요한 사건이다. 마지막 줄이 둘 다 「반드시 아님」인 까닭은 앞에서 본 대로다. demand paging 이나 copy-on-write 처럼 정상 동작이 두 계층 모두에서 fault 를 만든다.
|
|
|
|
## 세 번째 — Host Page Fault
|
|
|
|
QEMU 도 호스트의 일반 사용자 공간 프로세스이므로 QEMU 가 마련한 메모리에는 호스트의 가상 메모리 관리가 그대로 적용된다. 게스트 RAM 을 담고 있는 그 영역도 호스트 페이지 테이블을 지나 호스트 물리 주소로 이어지고, 그 경로에서 demand allocation 이나 reclaim, swap 때문에 fault 가 날 수 있다.
|
|
|
|
```text label="QEMU backing 쪽에서 나는 fault"
|
|
QEMU / Guest RAM Backing
|
|
↓
|
|
Host Virtual Memory
|
|
↓
|
|
Host Page Fault
|
|
↓
|
|
Host Kernel
|
|
↓
|
|
필요한 Host page 처리
|
|
```
|
|
|
|
게스트 안에서는 이 사건이 fault 로 보이지 않는다. 게스트는 자기 메모리 접근이 오래 걸렸다고만 관측하고, 그 지연의 원인은 호스트 쪽 지표에 남는다. 그래서 가상 머신 메모리를 분석할 때는 Guest Page Fault 와 Host Page Fault, 그리고 EPT 관련 가상화 사건을 적어도 셋으로 갈라 놓는다.
|
|
|
|
|
|
|
|
그림에서 QEMU 쪽 갈래는 위의 두 갈래와 선으로 이어져 있지 않다. 근거 문서가 EPT 로 얻은 HPA 와 QEMU 가 마련한 메모리의 호스트 물리 주소를 같은 것이라고 적지 않아서 그 선을 긋지 않았다.
|
|
|
|
## 메모리 지연이나 OOM(Out Of Memory) 이 보일 때 셋을 어디에 놓나
|
|
|
|
증상 하나로 "메모리 부족"을 결론내리지 않고 어느 계층의 사건인지부터 가른다. 세 사건은 이 분류에서 서로 다른 가지에 들어간다.
|
|
|
|
```text label="메모리 문제를 계층으로 가르는 분류 (fault 가 걸리는 가지)"
|
|
문제
|
|
│
|
|
├─ Guest Virtual Memory?
|
|
│ ├─ Page Fault
|
|
│ ├─ Guest reclaim
|
|
│ ├─ Guest swap
|
|
│ └─ Guest OOM
|
|
│
|
|
├─ Virtualization Translation?
|
|
│ ├─ EPT-related event
|
|
│ ├─ TLB pressure
|
|
│ └─ Huge-page/mapping 특성
|
|
│
|
|
└─ Host Memory?
|
|
├─ Host reclaim
|
|
├─ Host swap
|
|
├─ Host major fault
|
|
└─ Host OOM
|
|
```
|
|
|
|
원문의 분류에는 Dynamic Memory 와 NUMA(Non-Uniform Memory Access) 가지가 더 있고, 위에 옮긴 셋이 fault 가 걸리는 가지다. 게스트 쪽 fault 가 늘었으면 게스트의 reclaim 과 swap 을 같이 보고, 호스트 쪽 major fault 가 늘었으면 호스트의 reclaim 과 swap 을 같이 본다. 어느 쪽 지표를 먼저 여느냐가 이 구분에서 정해진다. 다만 이 호스트에서는 어느 쪽도 아직 열지 않았다. 게스트 쪽 fault 지표도 호스트 쪽 major fault 도 읽은 적이 없어서, 이 분류는 아직 어느 지표부터 열지 정하는 데만 쓰인다.
|
|
|
|
## 이 글이 확정하지 않는 것
|
|
|
|
이 호스트에서 잰 값은 하나도 없다. 게스트 쪽 fault 지표도 호스트 쪽 major fault 도 읽지 않았고, 앞의 다섯 원인 가운데 무엇이 이 환경에서 실제로 일어나는지도 세지 않았다. 원문 제2부는 개념 서술이고 실제 서버에 딸린 값은 OQ(Open Question) 번호가 붙은 확인 목록 열넷으로 미뤄져 있다.
|
|
|
|
게스트 쪽은 OQ-13 이 받는다. page-fault 관련 지표를 관측한 뒤 그 증가가 무엇에서 왔는지를 네 갈래로 갈라 보는 확인이고, 증가 자체를 오류로 읽지 않는 것이 조건이다.
|
|
|
|
```text label="Guest page fault 가 늘었을 때 갈라 보는 것 (OQ-13)"
|
|
정상 demand paging?
|
|
COW?
|
|
Guest swap-in?
|
|
application working-set 증가?
|
|
```
|
|
|
|
호스트 쪽은 OQ-14 가 받는다. 호스트 메모리 압박 실험을 하면서 아래 넷을 같은 시간축에 놓고 견준다.
|
|
|
|
```text label="같은 시간축에 놓고 견줄 값 (OQ-14)"
|
|
Host Fault
|
|
+
|
|
Swap activity
|
|
+
|
|
Storage latency
|
|
+
|
|
Guest application latency
|
|
```
|
|
|
|
가운데 계층은 그 목록이 받지 않는다. 위 분류에는 EPT 관련 사건과 TLB 압박이 한 가지로 들어 있는데, 그것을 이 호스트에서 재라고 적은 항목은 열넷 가운데 없다. 이 글이 갈라 놓은 세 계층에서 확인 계획이 붙은 것은 게스트 쪽과 호스트 쪽 둘이다.
|
|
|
|
원문이 커널 버전을 적지 않아 이 글도 특정 버전에 고정하지 않았다. 여기 적은 것은 그 문서가 서술한 처리 구조이고, 이 서버에서 어떤 값이 나오는지는 위 두 확인을 돌려야 안다.
|
|
|
|
<!-- body:end -->
|