DongHyeonkaandClaude Opus 5
2109f726fe
기록 84편을 계약 에이전트로 다시 썼다. 기존 71편(kss 25 · virt 46)과, 계약에만 있고 안 쓰여 있던 새 글감 13편이다. 원장 84개를 열어 단계마다 스킬 영수증과 관문 종료 코드를 적었고 verify-pipeline-run.py 가 error 0 으로 닫는다. SSOT 결함 둘을 고쳤다. - kss 의 `약 58일` 이 반입 중 `약 59일` 로 바뀌어 있었다. 원 증거 파일이 「남은 일수: 88일 … 실제 갱신까지 약 58일」로 산수를 직접 적는다. D-4a 쪽 `약 59일` 은 강제 갱신 뒤(`VALID: 89 days`)라 맞는 값이라 그대로 뒀다. - virt §198 의 `11.6GB` 는 §178 의 원 측정 `Mem: 11648`(MiB)과 어긋나는데 원 가이드의 표기 그대로라 고치지 않고 쓰이는 자리에 대조를 적었다. 기록의 수치 오류 셋을 고쳤다 — CASE 요약의 「게스트 셋에 8240MB」(5120+3120 은 둘이다), k3s 편이 같은 것을 여섯·일곱·여덟로 세던 것, no-docker 편의 「셋을 더 든다」(§281 의 표는 네 행이고 디스크 행이 빠져 있었다). 계약을 셋 고쳤다. - kss 의 sourceRepository 리비전이 cdac9b8 이었는데 그 커밋에는 docs/guides/** 28개가 아예 없다. 9465582b 로 바꾸고, 반입한 바이트가 어느 커밋과도 같지 않다는 것을 측정값과 함께 적었다 — 반입은 커밋이 아니라 그 시점의 작업 트리에서 떠 온 것이다(kss 297/306 · virt 12/14 가 작업 트리와 같고, 200 커밋을 거슬러 전수 대조했을 때 가장 가까운 커밋도 28개가 어긋났다). - virt 계약이 「2026-09-11 재배분」이라고 적는데 SSOT 는 재배분 날짜를 적지 않고 재배분 뒤 값은 이미 2026-09-10 측정에 찍혀 있다. - kss 후보 대장이 지나친 절 아홉에 처분을 적었다(warn 9 → 0). 새 글감은 0건이고 넷은 앵커가 h3 슬러그의 접두가 아니라 중간 토막이라 검사기가 못 본 것이었다. style_profile.mjs 의 결함 둘을 고쳤다 — frontmatter 가 문장으로 세어져 (실측 398자짜리 「문장」 하나) 평균 길이를 기준 안으로 밀어 올리고 있었고, engPerSent 의 분자는 목록을 포함한 글에서, 분모는 목록을 걷어낸 글에서 세고 있었다(Question 기록에서 11.94 → 3.86). verify-pipeline.py 전 항목 PASS · error 0 · unittest 334건 OK. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
101 lines
8.7 KiB
Markdown
101 lines
8.7 KiB
Markdown
---
|
|
id: f460e9a2-35ef-46ff-81cf-b36627a1b231
|
|
kind: QUESTION
|
|
slug: vm-ram-backed-by-hugetlb
|
|
title: 가상 머신 RAM 이 HugeTLB 로 명시적으로 backing 되어 있는가
|
|
topic: memory-virtualization
|
|
topicName: 메모리 가상화
|
|
project: virtualization
|
|
status: 초안
|
|
questionStatus: OPEN
|
|
studio: "https://hyeonworks.com/studio/documents/f460e9a2-35ef-46ff-81cf-b36627a1b231/edit"
|
|
sourceRevision: no-commit · 밖에서 반입한 문서 한 편. 고정할 저장소 리비전이 없다
|
|
source:
|
|
- final/document.md#83-실제-환경에서-확인할-open-question-oq-5
|
|
- final/document.md#55-hugetlb
|
|
- final/document.md#52-vm에서-huge-page를-볼-때-주의할-점
|
|
---
|
|
|
|
# 가상 머신 RAM 이 HugeTLB 로 명시적으로 backing 되어 있는가
|
|
|
|
HugeTLB 는 관리자가 미리 잡아 둔 Huge Page pool 을 가상 머신이나 애플리케이션이 명시적으로 지정해 쓰는 방식이다. 이 호스트의 게스트 세 대가 그 방식으로 RAM 을 받고 있는지는 아직 읽지 않았다. §83 OQ-5 가 libvirt 설정을 읽은 뒤 호스트 /proc/meminfo, QEMU smaps 계열과 교차 검증하라고 적어서 설정 한 곳만 봐서는 끝나지 않는다.
|
|
|
|
## 관계
|
|
|
|
- **Huge Page 를 VM 에서 볼 때 갈라지는 세 자리**
|
|
§52 가 나눈 세 단계 가운데 호스트 backing 쪽만 이 물음이 확정한다.
|
|
- **이 호스트의 THP 정책과 huge page 상태는 무엇인가**
|
|
HugePages_Total 과 HugePages_Free 를 그쪽이 읽는다. 그 값이 이 물음의 교차 검증 재료가 된다.
|
|
- **QEMU 프로세스가 실제로 붙잡고 있는 호스트 메모리는 얼마이고 어떻게 나뉘어 있는가**
|
|
두 물음이 같은 smaps_rollup 출력을 읽으므로 한 번 찍어 나눠 쓴다.
|
|
- **메모리 실험 결과에는 Host · VM · Workload 조건을 함께 남긴다**
|
|
memory backing 설정이 그 기준의 VM 조건 목록에 들어 있다.
|
|
|
|
## 사실
|
|
|
|
- §55 는 HugeTLB 를 명시적인 Huge Page pool 을 쓸 수 있는 Linux 메커니즘으로 적었다.
|
|
THP 는 애플리케이션이 일반 메모리 할당을 하면 커널이 알아서 Huge Page 를 활용하는 경로이고, HugeTLB 는 관리자가 풀을 준비한 뒤 애플리케이션이나 가상 머신이 명시적으로 쓰는 경로다.
|
|
- §55 는 물리 RAM 안에 일반 메모리 영역과 2 MiB 단위 HugeTLB Pool 이 나뉘어 있는 그림으로 그 풀을 그렸다.
|
|
- §55 는 사전 확보로 예측 가능성을 높일 수 있지만 일반 메모리 할당의 유연성이 감소하는 trade-off 가 있다고 밝혔다.
|
|
- §52 는 가상 머신에 translation 단계가 둘이라 "Huge Page 를 사용한다"는 말만으로는 부족하다고 적고 셋을 구분하라고 했다.
|
|
게스트 page-table 단계에서 큰 페이지를 쓰는가
|
|
호스트 backing 이 Huge Page 인가
|
|
EPT mapping 에서 큰 mapping 을 활용하는가
|
|
- §52 는 게스트와 호스트의 page-size 선택을 하나의 동일한 설정으로 취급하면 안 된다고 못 박았다.
|
|
- §83 OQ-5 는 확인 명령으로 virsh dumpxml <VM_NAME> 을 들고, libvirt memory backing 관련 설정을 확인한 뒤 호스트 /proc/meminfo, QEMU smaps 계열과 교차 검증하라고 적었다.
|
|
- §83 OQ-3 이 QEMU 프로세스 쪽 명령으로 cat /proc/<QEMU_PID>/smaps_rollup 을 들었다.
|
|
smaps 계열에서 huge page 사용량을 어느 항목 이름으로 읽는지는 개념 문서가 적지 않았다.
|
|
- 세 자료 가운데 호스트 쪽은 항목 이름이 적혀 있다. §56 은 호스트 확인 명령을 적으면서 AnonHugePages 와 HugePages_Total 이 같은 의미가 아니라고 못 박았다. §83 OQ-4 도 THP policy · AnonHugePages · HugePages_Total · HugePages_Free · Hugepagesize 를 확인 항목으로 들었다. 이름이 없는 것은 QEMU smaps 쪽 하나다.
|
|
- §187 이 적은 게스트는 kc-lab-edge · kc-lab-1 · kc-lab-2 세 대이고 배정한 메모리는 차례로 1024MB · 5120MB · 4096MB 다.
|
|
- §197 이 이 실험대의 libvirt 12.7.0 과 QEMU 11.1.1, 커널 7.2.2-arch1-1 을 적었다.
|
|
- 이 호스트의 libvirt 설정을 읽은 기록이 개념 문서에 없다. 호스트 /proc/meminfo 의 huge page 값을 찍은 기록도 없다. huge page 와 THP, HugeTLB 는 SSOT 제2부에서만 서술되고, 실험대를 세우고 값을 잰 제5~9부에는 그 이름이 한 번도 나오지 않는다. 그래서 이 물음이 다시 읽을 기존 출력이 없고 세 자료를 새로 찍어야 한다.
|
|
|
|
## 가정
|
|
|
|
- 게스트 세 대 모두 libvirt 로 정의되어 있어 virsh dumpxml 로 설정을 통째로 읽을 수 있다고 본다.
|
|
- 설정에 memory backing 관련 요소가 없으면 명시적 HugeTLB backing 을 쓰지 않는 것으로 읽는다. 그 해석이 §197 이 적은 libvirt 12.7.0 에서 맞는지는 확인하지 않았다.
|
|
- 세 자료를 같은 시각에 찍으면 같은 순간의 상태를 가리킨다고 전제한다.
|
|
- QEMU 프로세스 번호를 가상 머신마다 가려낼 수 있다고 본다.
|
|
|
|
## 미지수
|
|
|
|
- 각 가상 머신의 libvirt 설정에 memory backing 항목이 있는지, 있다면 HugeTLB 를 가리키는지.
|
|
- 있다면 그 요구량이 호스트 HugePages_Total 및 HugePages_Free 와 맞물리는지.
|
|
- QEMU smaps 계열에서 huge page 사용량을 어느 항목으로 읽는지. 개념 문서가 항목 이름을 적지 않아 실행하는 쪽이 정한다.
|
|
- 설정과 호스트 값이 어긋나는 상태가 이 호스트에 실제로 있는지.
|
|
|
|
## 제약
|
|
|
|
- 게스트 안에서 본 huge page 상태를 호스트 backing 의 증거로 쓰지 않는다. §52 가 두 단계를 구분하라고 적었다.
|
|
- 세 자료 중 하나만으로 결론을 적지 않는다. OQ-5 가 교차 검증을 지시했다.
|
|
- 이 물음에서 풀을 새로 잡거나 backing 설정을 바꾸지 않는다. 현재 상태를 확정하는 것이 전부다.
|
|
- §84 의 권장 실험 순서는 THP/HugeTLB 상태 확인을 다섯째 한 단계로 묶었지만 §83 은 호스트 정책을 OQ-4 로, 가상 머신 backing 을 OQ-5 로 갈라 물었다. 앞의 것은 호스트 하나에 대해 한 번 읽는 값이고 뒤의 것은 가상 머신마다 갈릴 수 있는 설정이다. 이 물음이 받는 것은 뒤쪽이고, 앞쪽 값은 「이 호스트의 THP 정책과 huge page 상태는 무엇인가」가 읽어 여기에 교차 검증 재료로 들어온다.
|
|
- 개념 문서가 smaps 항목 이름을 적지 않았으므로 실행한 명령과 출력을 그대로 남겨야 다음 사람이 같은 값을 다시 읽는다.
|
|
|
|
## 선택지
|
|
|
|
### 1. libvirt 설정부터 읽고 backing 항목이 없으면 거기서 끝낸다
|
|
|
|
게스트마다 virsh dumpxml 을 한 번씩 찍는 것으로 시작한다. 세 설정 모두 memory backing 관련 요소가 없으면 명시적 HugeTLB backing 이 아니라는 답이 거의 정해지고, 호스트 HugePages_Total 이 0 인지만 확인하면 닫힌다.
|
|
|
|
설정에 항목이 있으면 결국 세 자료를 다 받아야 하므로 호스트와 QEMU 쪽을 다시 찍으러 간다.
|
|
|
|
### 2. 세 자료를 한 번에 찍어 나란히 놓는다
|
|
|
|
설정과 호스트 /proc/meminfo, QEMU smaps_rollup 을 같은 시각에 받아 나란히 둔다. OQ-5 가 요구한 교차 검증이 한 번의 실행으로 끝나고, 설정과 실제 값이 어긋나는 경우에도 그 어긋남이 같은 시각의 자료로 남는다.
|
|
|
|
QEMU 프로세스 번호를 먼저 가려내야 하고, 게스트 세 대가 같은 시각에 켜져 있어야 한다.
|
|
|
|
### 3. 호스트 HugePages_Total 하나로 가른다 — 제외
|
|
|
|
풀이 잡혀 있지 않으면 어떤 가상 머신도 HugeTLB 로 backing 될 수 없으니 그 값 하나로 끝내자는 방법이다. 0 이 아닌 경우에는 그 풀을 쓰는 것이 이 가상 머신들인지 다른 프로세스인지 가리지 못한다. 그 구분이 이 물음이 답해야 하는 내용이다.
|
|
|
|
## 다음 검증
|
|
|
|
1. 가상 머신마다 virsh dumpxml <VM_NAME> 을 남기고 memory backing 관련 요소를 그대로 인용한다.
|
|
2. 같은 시각에 호스트에서 grep -i huge /proc/meminfo 를 찍는다.
|
|
3. 같은 시각에 각 QEMU 프로세스에 대해 cat /proc/<QEMU_PID>/smaps_rollup 을 찍고, huge page 로 읽은 항목의 이름을 함께 적는다.
|
|
4. 세 출력을 나란히 놓고 서로 맞는지, 어긋나면 어느 값이 어떻게 다른지 적는다.
|
|
|
|
닫는 조건 : 세 자료가 서로 맞으면 이 환경이 어느 쪽으로 backing 되어 있는지를 확정하고 닫는다. 설정에 backing 이 없고 HugePages_Total 도 0 이면 이 가상 머신들은 명시적 HugeTLB backing 을 쓰지 않는다고 적고 닫는다. 그 경우 남는 것은 §54 가 적은 THP 쪽 특성이고, 정책 값은 「이 호스트의 THP 정책과 huge page 상태는 무엇인가」가 읽는다. 설정과 호스트 값이 어긋나면 그 어긋남이 Case 가 된다.
|