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>
7.4 KiB
id, kind, slug, title, topic, topicName, project, status, questionStatus, studio, sourceRevision, source
| id | kind | slug | title | topic | topicName | project | status | questionStatus | studio | sourceRevision | source | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 61b7486f-5dab-41df-8f4f-e8fc21d88617 | QUESTION | vm-exit-distribution-by-workload | 실제 작업에서 주로 발생하는 VM Exit 은 무엇인가 | cpu-virtualization | CPU 가상화 | virtualization | 초안 | OPEN | https://hyeonworks.com/studio/documents/61b7486f-5dab-41df-8f4f-e8fc21d88617/edit | no-commit · 밖에서 반입한 문서 한 편. 고정할 저장소 리비전이 없다 |
|
실제 작업에서 주로 발생하는 VM Exit 은 무엇인가
perf kvm 이 이 환경에서 열리는지부터 아직 확인하지 않았다. VM Exit 은 게스트를 실행하던 CPU 가 KVM 쪽으로 제어권을 넘기는 전환이지 가상 머신이 꺼지는 것이 아니다(§7.2). §8 이 든 일곱 동작 가운데 무엇이 실제로 Exit 을 내는지는 이 호스트의 VMX 설정과 돌리는 작업이 정한다.
관계
- KVM 에서 vCPU 가 물리 CPU 에서 실행되기까지 VM Entry 와 VM Exit 이 무엇이고 Exit 뒤에 무엇이 처리하는지를 이 개념이 설명한다.
- Keycloak 작업의 VM Exit 분포는 idle · CPU-bound · I/O-bound 와 어떻게 다른가 같은 측정에서 Keycloak 쪽 분포만 떼어 묻는다. 도구가 열리지 않으면 두 질문이 같은 이유로 닫힌다.
사실
§8 이 든, VM Exit 을 발생시킬 수 있는 동작
HLT I/O Port 접근 - IN / OUT CPUID Control Register 접근 MSR 접근 Exception External Interrupt
Intel VMX 에는 VMCS(Virtual Machine Control Structure)가 있고 하이퍼바이저는 VM-Execution Control 등을 통해 어떤 동작을 가로챌지 설정한다 : §8
§8 은 「특권 명령이면 전부 VM Exit」이나 「root 가 실행하면 VM Exit」 같은 규칙이 맞지 않는다고 적는다. VM Exit 여부는 VMX 설정과 해당 동작의 종류에 따라 결정된다.
모든 CR(control register) 접근이 항상 VM Exit 을 발생시키지는 않는다 : §8.4 Page Fault, Breakpoint, Debug Exception 같은 CPU 예외도 Exception Bitmap 등의 설정에 따라 게스트가 직접 처리할 수도 있고 하이퍼바이저가 가로챌 수도 있다 : §8.6
CPU 에는 MSR(Model-Specific Register)이 있고 RDMSR 과 WRMSR 로 접근한다. 특정 MSR 접근을 하이퍼바이저가 가로채도록 설정했다면 VM Exit 이 발생할 수 있다 : §8.5
§8.2 는 I/O port 접근에서 나온 Exit 을 KVM 이 받고, 사용자 공간에서 가상 장치를 흉내 내야 하면 KVM_RUN 이 반환되어 QEMU 가 처리한 뒤 다시 KVM_RUN 을 호출한다고 적는다.
§14.9 는 환경이 지원하면 perf kvm 으로 KVM 관련 실행 통계를 확인할 수 있다고 하면서 sudo perf kvm stat live 를 예로 든다. 지원되는 명령과 표시되는 Exit 이유는 커널, perf 버전, CPU 아키텍처 및 설정에 따라 다를 수 있다. 그래서 perf kvm --help 를 함께 확인하고, 필요하면 KVM tracepoint 를 이용한 별도 추적도 검토하라고 적는다.
§197 은 2026-09-10 에 이 호스트에서 커널 7.2.2-arch1-1 과 QEMU emulator version 11.1.1 을 받아 적었다. CPU 는 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz 이고 lscpu 의 Virtualization 은 VT-x 다. §14.9 가 표시되는 Exit 이유를 좌우한다고 든 것 가운데 커널과 CPU 아키텍처는 여기서 정해진다. perf 버전은 적혀 있지 않다.
§20 이 든 비교 후보 다섯
idle CPU-bound workload I/O-heavy workload Keycloak 정상 요청 Keycloak 부하 테스트
가정
다섯 작업을 이 호스트에서 각각 만들 수 있다. Keycloak 정상 요청과 부하 테스트는 이미 돌리는 실험을 그대로 쓴다고 전제한다.
호스트에서 sudo 로 perf 를 돌릴 수 있다. §204 는 이 호스트의 sudo 가 비밀번호를 요구해 비대화식으로는 읽지 못했다고 적었으므로, 콘솔에 붙어 직접 치는 실행으로 잡는다.
한 작업을 재는 동안 다른 가상 머신이 내는 Exit 이 결과에 섞이지 않는다고 전제하는데, perf kvm 이 호스트 전체를 보는지 프로세스 하나만 보는지는 확인하지 않았다.
Exit 이유가 다섯 작업 사이에서 같은 이름으로 표시된다.
미지수
이 환경에서 perf kvm 이 어떤 하위 명령을 지원하는지.
열린다면 어떤 Exit 이유가 표시되는지.
다섯 작업의 Exit 이유 분포가 서로 얼마나 다른지.
perf kvm 이 열리지 않을 때 KVM tracepoint 로 같은 것을 볼 수 있는지.
한 작업을 얼마나 오래 재야 분포가 더 흔들리지 않는지.
제약
이 호스트에서 Exit 분포를 잰 값이 없기 때문에, 분포를 재기 전에 도구가 열리는지부터 확인해야 한다. 열리지 않는 것으로 확인되는 것도 이 물음을 닫는 결과다.
§8 에 따르면 어떤 동작이 Exit 을 내는지는 VMX 설정이 정하기 때문에, 나온 분포는 이 호스트의 설정에 딸린 값이라 다른 호스트로 옮겨 읽을 수 없다.
§14.9 는 표시되는 Exit 이유가 커널 · perf 버전 · CPU 아키텍처 및 설정에 따라 다를 수 있다고 적는다. 표의 열 이름도 이 환경에서 나온 그대로 쓴다.
Exit 총 횟수만으로는 작업을 견줄 수 없다. §8.2 처럼 QEMU 까지 돌아가는 Exit 과 KVM 안에서 끝나는 Exit 은 처리 경로가 다르다. §24.9 도 확인할 때 Exit 횟수만 보지 말라고 적으면서 「VM Exit이 많다 = 장애로 바로 판단하지 않는다」로 닫는다.
선택지
1. perf kvm --help 로 열리는 하위 명령부터 확인한다
§14.9 가 지원 여부는 환경마다 다르다고 적어 두었기 때문에 도구부터 확인한다. 여기서 안 열리면 뒤의 계획이 통째로 바뀐다.
2. 열리면 sudo perf kvm stat live 로 다섯 작업을 각각 돌린다
§20 이 든 다섯을 하나씩 돌리며 Exit 이유 분포를 받아 적는다. 유휴 구간을 먼저 재 두면 나머지 넷에서 늘어난 Exit 이 무엇인지 견줄 수 있다.
3. 열리지 않으면 KVM tracepoint 추적을 검토한다
§14.9 가 대안으로 든 방법이다. 이쪽도 안 되면 「이 호스트에서는 Exit 분포를 관측할 수 없다」가 이 질문의 답이 된다.
4. 제외 — Exit 총 횟수만 세어 작업을 견준다
숫자 하나로 다섯을 늘어놓을 수 있어 간단하다. 그러나 §8.2 가 적은 대로 Exit 마다 처리 경로가 달라서, 총 횟수는 작업 사이의 차이를 설명하지 못한다.
다음 검증
- perf kvm --help 로 이 환경이 지원하는 하위 명령을 확인한다.
- 열리면 sudo perf kvm stat live 로 §20 의 비교 후보 다섯을 각각 돌리며 Exit 이유 분포를 받아 적는다.
- 열리지 않으면 §14.9 가 말한 KVM tracepoint 추적을 검토하고 그 결과도 기록한다.
닫는 조건 : 다섯 작업의 Exit 이유 분포를 한 표로 놓을 수 있으면 그 표가 Case 가 되고 닫는다. perf kvm 도 tracepoint 도 이 환경에서 열리지 않으면, 「이 호스트에서는 Exit 분포를 관측할 수 없다」를 그대로 적고 §24.9 의 확인 항목에서 Exit 이유를 빼는 근거로 남긴 뒤 닫는다.