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>
6.6 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 | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| cd58d35d-3a93-4682-82b8-b64ce3a8813c | QUESTION | vcpu-thread-migration-without-pinning | pinning 없이 vCPU 스레드는 호스트 논리 CPU 사이를 옮겨 다니는가 | cpu-virtualization | CPU 가상화 | virtualization | 초안 | OPEN | https://hyeonworks.com/studio/documents/cd58d35d-3a93-4682-82b8-b64ce3a8813c/edit | no-commit · 밖에서 반입한 문서 한 편. 고정할 저장소 리비전이 없다 |
|
pinning 없이 vCPU 스레드는 호스트 논리 CPU 사이를 옮겨 다니는가
이 호스트에서 PSR 을 찍어 본 기록이 없어서, pinning 없이 같은 vCPU 스레드가 논리 CPU 사이를 옮겨 다니는지 아직 모른다.
PSR 은 ps 가 찍어 주는 값이고 그 스레드가 최근 실행된 논리 CPU 를 가리킨다(§14.7). 이 호스트의 논리 코어는 8 이고 두 게스트의 vCPU 는 각각 2 다(§197 · §218).
관계
- KVM 에서 vCPU 가 물리 CPU 에서 실행되기까지 vCPU 스레드가 호스트 Linux 스케줄러의 스케줄링 대상이라는 설명이 이 물음의 전제다.
- CPU pinning 전후로 Keycloak 지연과 vCPU 스케줄링 변동이 달라지는가 이동이 실제로 일어나야 pinning 을 걸어 볼 이유가 생긴다.
- 게스트가 유휴 상태일 때 vCPU 스레드는 이 테스트 환경에서 어떻게 보이는가
두 물음이 같은
ps출력을 읽으므로 한 번 찍어 둘을 같이 본다.
사실
§5 는 QEMU vCPU 스레드도 다른 호스트 스레드와 마찬가지로 Linux 스케줄러가 실행할 논리 CPU 를 정한다고 적었다. 그래서 같은 vCPU 스레드라도 시간에 따라 서로 다른 논리 CPU 에서 실행될 수 있다. 같은 절은 그 이동을 세 시점으로 그려 두었다. T1 에 CPU7 에서 돌던 vCPU 스레드 0 이 T2 에는 CPU7 을 다른 스레드에게 내주고, T3 에는 CPU3 에서 돈다. CPU pinning 을 적용하면 실행 위치를 특정 논리 CPU 집합으로 제한할 수 있다고 같은 절이 덧붙였다.
§14.7 은 ps -eLo pid,tid,psr,pcpu,comm | grep qemu 를 들고, PSR 로 스레드가 최근 실행된 논리 CPU 를 관찰할 수 있다고 적었다. 같은 절은 그 값이 vCPU 가 물리 CPU 에 영구 고정되어 있다는 뜻은 아니라고 못 박고, pinning 을 하지 않았다면 스케줄링에 따라 달라질 수 있다고 덧붙였다.
§20 의 OQ-5 는 PSR 과 스케줄러 추적으로 관찰한다고만 적었을 뿐 관찰한 결과는 남기지 않았다.
§197 은 2026-09-10 에 이 호스트에서 잰 값을 적었다. Core(s) per socket 4 에 Thread(s) per core 2 라 논리 코어가 8 이고, 실험대가 잡은 vCPU 는 2 + 2 + 1 = 5 다. §218 의 2026-09-03 배치는 kc-lab-1 과 kc-lab-2 에 각각 vCPU 2 를 적었다.
이 호스트에서 PSR 을 실제로 찍은 기록은 SSOT 에 없다.
가정
두 가상 머신에 pinning 이나 CPU 친화도를 걸지 않았다고 전제하고 이 물음을 세웠다. 실제로 걸었는지는 SSOT 에 적혀 있지 않다.
일정 간격으로 여러 번 찍으면 이동이 PSR 값의 변화로 잡힌다고 전제한다. 다만 표본과 표본 사이에 다른 논리 CPU 로 갔다가 돌아오면 두 표본은 같은 값으로 나온다.
게스트 부하가 있을 때와 없을 때 호스트 스케줄러가 스레드를 놓는 논리 CPU 가 달라질 수 있다고 전제한다. §5 는 스케줄러가 실행할 논리 CPU 를 정한다고만 적었지 부하에 따라 무엇이 달라지는지는 적지 않았다.
미지수
이 호스트에서 pinning 없이 같은 vCPU 스레드의 PSR 이 시간에 따라 실제로 바뀌는가.
바뀐다면 게스트가 유휴일 때와 CPU 부하가 있을 때가 서로 다른가.
현재 두 가상 머신에 친화도가 걸려 있는가.
스케줄러 추적을 이 호스트에서 쓸 수 있는가. §20 이 관찰 수단으로 들었지만 지원 여부는 확인하지 않았다.
제약
이 호스트에서 PSR 을 찍은 값이 없어서, 지금 이동 여부를 적으면 관측이 아니라 추측이 된다.
PSR 은 최근 실행된 논리 CPU 하나만 보여 주므로 두 표본 사이에 일어난 이동은 잡히지 않는다.
§20 이 든 관찰 수단은 PSR 과 스케줄러 추적 둘이고, 이 물음은 그 둘 안에서 닫는다.
이 물음을 pinning 전후를 비교하는 쪽의 관측 항목으로 넣지 않고 따로 세웠다. 이동이 없으면 그 비교를 걸어 볼 이유가 없어져서 이쪽이 먼저 닫혀야 한다. 그 대신 이동이 성능에 얼마나 걸리는지는 여기서 재지 않는다.
선택지
1. ps 출력을 일정 간격으로 여러 번 찍는다
§14.7 이 든 ps -eLo pid,tid,psr,pcpu,comm | grep qemu 를 그대로 쓰고 같은 tid 의 PSR 을 시간순으로 늘어놓는다. 게스트를 건드리지 않고 호스트에서만 찍으면 되고 따로 설치할 도구도 없다.
표본 사이의 이동은 보이지 않으니 몇 초 간격으로 몇 번 찍었는지를 값과 함께 적는다.
2. 스케줄러 추적으로 이동 시점을 본다
§20 이 PSR 과 함께 든 수단이다. 표본 간격에 기대지 않고 스레드가 옮겨 간 시점을 볼 수 있다.
다만 이 호스트에서 추적을 쓸 수 있는지 아직 확인하지 않았고, 호스트에 도구와 권한이 더 필요하다. 1번으로 이동이 이미 보이면 여기까지 가지 않는다.
3. 제외 — 친화도 설정만 읽고 답한다
설정에 pinning 이 없다는 것과 스케줄러가 실제로 스레드를 옮겼다는 것은 다르다. 설정 확인은 따로 두지 않고 1번 실행에서 함께 적는 항목으로 넣는다.
다음 검증
- ps -eLo pid,tid,psr,pcpu,comm | grep qemu 를 일정 간격으로 여러 번 찍어 같은 tid 의 PSR 이 바뀌는지 본다.
- 게스트가 유휴일 때와 CPU 부하가 있을 때를 나눠 각각 찍는다.
- 같은 실행에서 그 가상 머신에 친화도 설정이 있는지도 함께 적는다.
닫는 조건 : 관측 구간에서 같은 tid 의 PSR 이 바뀌면 이동한다는 사실을 개념의 확인 사례로 흡수하고 닫는다. 그 이동이 성능에 영향을 주는지는 pinning 전후를 비교하는 OQ-10 이 받는다. PSR 이 고정으로 나오면 친화도 설정을 먼저 확인하고, 설정이 없는데도 고정이면 그 관측이 Case 가 된다.