6.9 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 | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 4a2d3332-81c3-44fa-a4fb-216a41abb504 | QUESTION | idle-vcpu-thread-appearance | 게스트가 유휴 상태일 때 vCPU 스레드는 이 테스트 환경에서 어떻게 보이는가 | cpu-virtualization | CPU 가상화 | virtualization | 초안 | OPEN | https://hyeonworks.com/studio/documents/4a2d3332-81c3-44fa-a4fb-216a41abb504/edit | no-commit · 밖에서 반입한 문서 한 편. 고정할 저장소 리비전이 없다 |
|
게스트가 유휴 상태일 때 vCPU 스레드는 이 테스트 환경에서 어떻게 보이는가
게스트에 할 일이 없으면 vCPU 스레드가 잠들거나 대기 상태로 들어가고, 그동안 호스트는 그 물리 CPU 를 다른 작업에 쓸 수 있다. 이 서술이 이 환경에서도 그대로 보이는지는 QEMU 프로세스의 스레드 목록을 유휴와 부하 두 상태에서 찍어 봐야 아는데, 아직 어느 쪽도 찍지 않았다. 이 QEMU 버전에서 vCPU 스레드가 어떤 이름으로 나오는지도 모른다.
관계
- KVM 에서 vCPU 가 물리 CPU 에서 실행되기까지 vCPU 스레드가 왜 잠들 수 있는지, 무엇이 그것을 깨우는지를 이 개념이 설명한다.
- pinning 없이 vCPU 스레드는 호스트 논리 CPU 사이를 옮겨 다니는가
같은
ps -eLo출력의psr값을 본다. 여기서 스레드를 가려내는 방법이 정해지면 그쪽 측정이 바로 이어진다.
사실
가상 머신에 4 vCPU 를 설정했다고 해서 4개의 호스트 논리 CPU 가 계속 예약되지는 않는다 : §10
§10 이 그린 유휴 흐름
Guest 에 실행할 작업 없음 Guest Kernel idle HLT 등 VM Exit KVM vCPU Thread block/sleep
이때 호스트 스케줄러는 물리 CPU 를 호스트의 다른 작업에 쓸 수 있다 : §10
§10 이 그린 깨어나는 흐름
vCPU wake-up runnable Host Linux Scheduler Logical CPU 에서 vCPU Thread 실행 KVM / VM Entry Guest 실행 재개
§10 은 깨우는 이유로 타이머, 인터럽트, I/O 완료를 든다.
§14.6 은 ps -T -p <QEMU_PID> 또는 top -H -p <QEMU_PID> 로 vCPU 관련 스레드를 호스트에서 관찰할 수 있다고 적으면서, 환경과 QEMU 버전에 따라 이름은 다를 수 있다는 단서를 함께 단다.
§20 은 게스트의 유휴 상태와 CPU 부하 상태를 비교하라고 적고 확인 명령으로 둘을 든다.
top -H -p <QEMU_PID> ps -eLo pid,tid,psr,pcpu,stat,comm
가정
QEMU 프로세스의 PID 를 먼저 찾아야 한다. 가상 머신 두 대가 도는 호스트에서 어느 PID 가 어느 가상 머신인지 가리는 방법을 아직 정하지 않았다.
vCPU 스레드를 이름으로 못 가리면 스레드 수를 그 가상 머신의 vCPU 수와 맞춰 가린다고 전제한다.
유휴라고 부를 상태를 이 가상 머신에서 만들 수 있다. 가상 머신 안에서 도는 것이 있으면 완전한 유휴가 아니다.
pcpu 와 stat 를 한 번씩 찍은 값으로 두 상태를 가를 수 있다.
미지수
이 환경의 QEMU 에서 vCPU 스레드가 어떤 이름으로 보이는지.
유휴 상태에서 그 스레드의 pcpu 와 stat 값.
CPU 부하를 걸었을 때 같은 두 값이 어떻게 바뀌는지.
vCPU 스레드 말고 어떤 스레드가 같은 QEMU 프로세스 아래에 함께 보이는지, 그 스레드들이 유휴 상태에서도 CPU 를 쓰는지.
유휴인데도 주기적으로 깨어나는 구간이 있는지. §10 은 타이머와 인터럽트를 깨우는 이유로 들었다.
제약
이 호스트에서 찍은 출력이 없다. §10 은 개념 흐름을 그린 것이고 이 환경의 실제 출력이 아니다. 결과가 §10 과 같으면 개념에 흡수되고 다르면 Case 가 된다는 갈림을 처음에는 이 물음을 따로 세우지 않을 이유로 봤다. 지금은 그것을 그대로 닫는 조건으로 쓴다 — 어느 쪽으로 갈리든 물음은 닫힌다.
§14.6 이 스레드 이름은 환경과 QEMU 버전에 따라 다를 수 있다고 적기 때문에, 이름으로 거르는 절차를 미리 굳혀 둘 수 없다.
§20 이 든 확인 명령 둘은 그 시점의 스레드 목록과 값을 보여 준다. §10 이 적은 HLT 에서 VM Exit 을 거쳐 block/sleep 으로 가는 전이를 단계마다 짚어 주지는 않는다.
상태를 바꾸는 것 말고 가상 머신 구성은 건드리지 않는다. vCPU 수를 조정하면 유휴와 부하의 차이 대신 구성 차이를 보게 된다.
선택지
1. 스레드 이름부터 확정한다
§14.6 의 ps -T -p <QEMU_PID> 로 그 QEMU 프로세스의 스레드 목록을 받아, vCPU 스레드로 보이는 것이 그 가상 머신의 vCPU 수와 같은 수로 나오는지 맞춰 본다. 이름을 확정해 두면 뒤의 두 출력에서 어느 줄을 읽을지 정해진다.
2. 유휴와 부하를 같은 명령 두 개로 찍어 나란히 둔다
§20 이 확인 명령으로 top -H -p <QEMU_PID> 와 ps -eLo pid,tid,psr,pcpu,stat,comm 둘을 들었다. 두 상태에서 같은 두 명령을 돌리면 pcpu 와 stat 두 열을 그대로 견줄 수 있다. §14.7 이 스레드가 어느 논리 CPU 에서 돌았는지 볼 때 든 ps 에는 stat 열이 없다. §20 은 이 물음의 확인 명령에만 그 열을 더했고, 스레드가 자고 있는지 실행 상태인지는 그 열에서 읽는다.
3. 호스트 쪽 CPU 사용량도 같이 본다
§10 은 vCPU 스레드가 잠들면 호스트가 그 물리 CPU 를 다른 작업에 쓸 수 있다고 적는다. vCPU 스레드의 pcpu 만 보면 그 스레드가 CPU 를 안 쓴다는 데까지만 확인되고, 비워 준 CPU 를 호스트가 실제로 다른 작업에 썼는지는 안 보인다.
4. 제외 — 추적으로 전이 시점을 직접 잡는다
HLT 로 VM Exit 이 나고 스레드가 잠드는 순간을 추적하면 §10 의 흐름을 단계마다 확인할 수 있다. 그러나 이 질문은 두 상태의 출력이 갈리는지를 묻고 §20 도 확인 명령을 두 줄로 적어 두었기 때문에, 더 무거운 도구는 두 출력이 갈리지 않을 때 꺼낸다.
다음 검증
- 가상 머신을 유휴 상태로 둔 채 top -H -p <QEMU_PID> 와 ps -eLo pid,tid,psr,pcpu,stat,comm 을 찍는다.
- 같은 가상 머신에 CPU 부하를 걸고 같은 두 명령을 다시 찍는다.
- 두 출력을 나란히 둔다. §20 이 적은 확인 명령 그대로다.
닫는 조건 : 유휴 상태에서 vCPU 스레드의 pcpu 가 0 에 가깝고 stat 가 sleep 계열이며 부하에서 실행 상태로 바뀌면, §10 의 서술이 이 환경에서도 성립하는 것으로 개념의 확인 사례에 흡수하고 닫는다. 두 상태에서 출력이 갈리지 않거나 §10 과 반대로 나오면 그 출력이 Case 가 된다.