6.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 | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 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 사이를 옮겨 다니는가
§5 는 QEMU vCPU 스레드도 다른 호스트 스레드와 마찬가지로 Linux 스케줄러가 실행할 논리 CPU 를 정한다고 적었다.
관찰 수단은 §14.7 이 든다. PSR 은 ps 가 찍어 주는 값이고, 그 스레드가 최근 실행된 논리 CPU 를 가리킨다.
다만 이 호스트에서 PSR 을 찍어 본 기록이 없어서, 같은 vCPU 스레드가 시간에 따라 다른 논리 CPU 로 옮겨 가는지는 아직 모른다.
관계
- 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 과 스케줄러 추적으로 관찰한다고만 적었을 뿐 관찰한 결과는 남기지 않았다.
이 호스트에서 PSR 을 실제로 찍은 기록은 SSOT 에 없다.
가정
두 가상 머신에 pinning 이나 CPU 친화도를 걸지 않았다고 전제하고 이 물음을 세웠다. 실제로 걸었는지는 SSOT 에 적혀 있지 않다.
일정 간격으로 여러 번 찍으면 이동이 PSR 값의 변화로 잡힌다고 전제한다. 다만 표본과 표본 사이에 다른 논리 CPU 로 갔다가 돌아오면 두 표본은 같은 값으로 나온다.
게스트 부하가 있을 때와 없을 때 호스트 스케줄러가 스레드를 놓는 논리 CPU 가 달라질 수 있다고 전제한다. §5 는 스케줄러가 실행할 논리 CPU 를 정한다고만 적었지 부하에 따라 무엇이 달라지는지는 적지 않았다.
미지수
이 호스트에서 pinning 없이 같은 vCPU 스레드의 PSR 이 시간에 따라 실제로 바뀌는가.
바뀐다면 게스트가 유휴일 때와 CPU 부하가 있을 때가 서로 다른가.
현재 두 가상 머신에 친화도가 걸려 있는가.
스케줄러 추적을 이 호스트에서 쓸 수 있는가. §20 이 관찰 수단으로 들었지만 지원 여부는 확인하지 않았다.
제약
이 프로젝트에는 이 호스트에서 잰 값이 하나도 없어서, 지금 이동 여부를 적으면 관측이 아니라 추측이 된다.
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 가 된다.