108 lines
6.4 KiB
Markdown
108 lines
6.4 KiB
Markdown
---
|
|
id: cd58d35d-3a93-4682-82b8-b64ce3a8813c
|
|
kind: QUESTION
|
|
slug: vcpu-thread-migration-without-pinning
|
|
title: pinning 없이 vCPU 스레드는 호스트 논리 CPU 사이를 옮겨 다니는가
|
|
topic: cpu-virtualization
|
|
topicName: CPU 가상화
|
|
project: virtualization
|
|
status: 초안
|
|
questionStatus: OPEN
|
|
studio: "https://hyeonworks.com/studio/documents/cd58d35d-3a93-4682-82b8-b64ce3a8813c/edit"
|
|
sourceRevision: no-commit · 밖에서 반입한 문서 한 편. 고정할 저장소 리비전이 없다
|
|
source:
|
|
- final/document.md#20-이-concept에서-파생되는-open-question-oq-5
|
|
- final/document.md#5-host-linux-scheduler와-실제-cpu
|
|
- final/document.md#14-실제-linux에서-확인할-수-있는-것-14-7
|
|
---
|
|
|
|
# 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번 실행에서 함께 적는 항목으로 넣는다.
|
|
|
|
## 다음 검증
|
|
|
|
1. ps -eLo pid,tid,psr,pcpu,comm | grep qemu 를 일정 간격으로 여러 번 찍어 같은 tid 의 PSR 이 바뀌는지 본다.
|
|
2. 게스트가 유휴일 때와 CPU 부하가 있을 때를 나눠 각각 찍는다.
|
|
3. 같은 실행에서 그 가상 머신에 친화도 설정이 있는지도 함께 적는다.
|
|
|
|
닫는 조건 : 관측 구간에서 같은 tid 의 PSR 이 바뀌면 이동한다는 사실을 개념의 확인 사례로 흡수하고 닫는다. 그 이동이 성능에 영향을 주는지는 pinning 전후를 비교하는 OQ-10 이 받는다. PSR 이 고정으로 나오면 친화도 설정을 먼저 확인하고, 설정이 없는데도 고정이면 그 관측이 Case 가 된다.
|