관찰하다:
800MHz에서 1500MHz까지 확장할 수 있는 AMD 듀얼 코어 CPU(Turion II Neo N40L)가 장착된 HP 서버가 있습니다. 주파수 스케일링은 Linux 커널 3.5가 설치된 FreeBSD 9 및 Ubuntu 12.04에서 사용할 수 있습니다. 그런데 우분투 위에 KVM 환경에 FreeBSD 9을 설치했더니 주파수 스케일링이 작동하지 않더군요. 게스트 시스템(예: FreeBSD)은 최소 및 최대 주파수를 감지하지 않으므로 CPU 사용량이 높아져도 조정이 이루어지지 않습니다. 호스트 시스템(예: Ubuntu)에서 KVM 프로세스는 CPU 리소스의 80% ~ 140%를 사용하지만 주파수 스케일링은 발생하지 않으며 동일한 Ubuntu 시스템에서 다른 프로세스를 실행할 때에도 주파수는 800MHz로 유지됩니다. 주문형 스케일링 속도 컨트롤러는 곧 주파수를 1500MHz로 확장할 예정입니다!
우려사항 및 질문:
CPU가 어떻게 가상화되는지, 게스트가 적절한 스케일링을 수행하는지 이해가 되지 않습니다. 제대로 작동하려면 게스트에 노출되어야 하는 특정 CPU 기능이 있습니까?
부록:
이것다음 Red Hat 릴리스 노트주파수 스케일링은 가상화된 환경에서도 작동한다고 제안하는 경향이 있으며(6.2.2장 및 6.2.3장 참조), 이 기술이 어떤 가상화 기술(kvm, xen 등?)에 적합한지 언급하지 못했다고 주장합니다.
자세한 내용은 cpufreq-infoUbuntu의 출력은 다음과 같습니다.
$ cpufreq-info
cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to [email protected], please.
analyzing CPU 0:
driver: powernow-k8
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 8.0 us.
hardware limits: 800 MHz - 1.50 GHz
available frequency steps: 1.50 GHz, 1.30 GHz, 1000 MHz, 800 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, performance
current policy: frequency should be within 800 MHz and 1.50 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 800 MHz.
cpufreq stats: 1.50 GHz:14.79%, 1.30 GHz:1.07%, 1000 MHz:0.71%, 800 MHz:83.43% (277433)
analyzing CPU 1:
driver: powernow-k8
CPUs which run at the same hardware frequency: 1
CPUs which need to have their frequency coordinated by software: 1
maximum transition latency: 8.0 us.
hardware limits: 800 MHz - 1.50 GHz
available frequency steps: 1.50 GHz, 1.30 GHz, 1000 MHz, 800 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, performance
current policy: frequency should be within 800 MHz and 1.50 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 800 MHz.
cpufreq stats: 1.50 GHz:14.56%, 1.30 GHz:1.06%, 1000 MHz:0.79%, 800 MHz:83.59% (384089)
이 기능이 작동했으면 하는 이유는 에너지 절약, 더 조용한 작동(덜 뜨겁음), 이 기능이 작동하지 않는 이유와 작동 방법을 더 잘 이해하려는 단순한 호기심 때문입니다.
답변1
알려주신 팁 덕분에 해결책을 찾았습니다나일스그리고좋은 기사.
조정주문형CPU DVFS 거버너
수요 조절기에는 동적 주파수 스케일링(또는 동적 전압 및 주파수 스케일링을 위한 DVFS)이 시작될 때 제어할 수 있는 매개변수 세트가 있습니다. 이러한 매개변수는 sysfs 트리 아래에 있습니다./sys/devices/system/cpu/cpufreq/ondemand/
매개 변수 중 하나 up_threshold는 이름에서 알 수 있듯이 주문형 거버너가 시작되어 주파수 변경을 시작하는 임계값(CPU의 백분율로 표시되지만 이것이 코어당인지 결합 코어인지 아직 파악하지 못함)입니다. 동적으로.
예를 들어 50%로 변경하는 것은 sudo를 사용하여 간단합니다.
sudo bash -c "echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold"
루트라면 더 간단한 명령을 사용할 수 있습니다:
echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
참고: 이러한 변경 사항은 다음에 호스트를 다시 시작할 때 손실됩니다. /etc/init.d/rc.localUbuntu에서 와 마찬가지로 시작 중에 읽는 구성 파일에 이를 추가해야 합니다 .
호스트에서 많은 CPU(80-140%)를 소비하는 게스트 VM이 두 코어에 로드를 분할하여 어느 코어도 95%를 초과하지 않는다는 사실을 발견했습니다. 그래서 짜증나게도 CPU는 800MHz로 유지되었습니다. . 이제 위의 패치를 사용하면 CPU가 각 코어의 주파수를 더 빠르게 동적으로 변경할 수 있어 내 요구 사항에 더 적합합니다. 게스트 사용량에 대해서는 50%가 더 나은 임계값인 것 같습니다. 마일리지는 다를 수 있습니다.
(선택 사항) HPET를 사용하고 있는지 확인
타이머를 잘못 구현하는 일부 응용 프로그램은 DVFS의 영향을 받을 수 있습니다. 호스트에는 이 문제를 최소화하기 위한 정교한 알고리즘이 있을 수 있지만 이는 호스트 및/또는 게스트 환경에서 문제가 될 수 있습니다. 그러나 최신 CPU에는 현재 CPU/코어 주파수와 무관한 최신 TSC(타임스탬프 카운터)가 있습니다. 즉, 상수(constant_tsc), 불변(invariant_tsc) 또는 논스톱(nonstop_tsc)입니다. 이 Chromium 기사를 참조하세요.TSC 재동기화각각에 대한 추가 정보. 따라서 CPU에 이러한 TSC 중 하나가 장착되어 있으면 HPET를 강제할 필요가 없습니다. 호스트 CPU가 이를 지원하는지 확인하려면 유사한 명령을 사용하십시오(grep 매개변수를 해당 CPU 기능으로 변경하십시오. 여기서는 상수 TSC를 테스트합니다).
$ grep constant_tsc /proc/cpuinfo
이 최신 TSC가 없는 경우 다음을 수행해야 합니다.
- 아래에 설명된 활성 HPET;
- 정확한 타이밍에 의존하는 가상 머신에 애플리케이션이 있는 경우 CPU DVFS를 사용하지 마십시오.레드햇에서 추천하는.
안전한 해결책은 HPET 타이머를 활성화하는 것입니다(자세한 내용은 아래 참조). TSC 타이머보다 쿼리 속도가 느리고(TSC는 CPU에 있고 HPET는 마더보드에 있음) 정확하지 않을 수 있습니다(HPET >10MHz, TSC는 일반적으로 최대 CPU 클럭), 특히 각 코어가 서로 다른 주파수를 가질 수 있는 DVFS 구성에서 더 안정적입니다. Linux는 사용 가능한 최고의 타이머를 사용할 만큼 똑똑합니다. 먼저 TSC에 의존하지만 너무 신뢰할 수 없다고 판단되면 HPET를 사용합니다. 이는 호스트(베어메탈) 시스템에서 잘 작동하지만 하이퍼바이저가 모든 정보를 올바르게 내보내지 않기 때문에 게스트 VM이 제대로 작동하지 않는 TSC를 감지하는 것이 더 어렵습니다. 게스트가 클록 소스를 사용할 수 있도록 하려면 하이퍼바이저가 필요하지만 비결은 게스트에서 HPET를 강제로 사용하도록 하는 것입니다.
아래에서는 Linux 및 FreeBSD에서 HPET를 구성 및/또는 활성화하는 방법을 확인할 수 있습니다.
리눅스 HPET 구성
HPET(High Precision Event Timer)는 2005년 이후 대부분의 상업용 PC에서 찾을 수 있는 하드웨어 타이머입니다. 최신 운영 체제는 이 타이머를 효과적으로 사용할 수 있습니다(Linux 커널은 2.6부터 지원합니다.최신 9.x부터 FreeBSD를 안정적으로 지원하지만 6.3에 도입됨)는 항상 CPU 전원 관리를 위한 일관된 타이밍을 제공합니다. 또한 건물을 허용합니다.더 간단한 틱리스 스케줄러 구현.
기본적으로 HPET는 보안 장벽처럼 작동하며 호스트에 DVFS가 활성화되어 있어도 호스트 및 게스트 타이밍 이벤트는 영향을 덜 받습니다.
하나 있다HPET 활성화에 관한 IBM의 좋은 기사, 커널이 사용하는 하드웨어 타이머와 사용 가능한 하드웨어 타이머를 확인하는 방법을 설명합니다. 여기에 간략한 요약을 제공하겠습니다.
사용 가능한 하드웨어 타이머를 확인하세요.
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
현재 활성 타이머를 확인하십시오.
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
HPET를 사용할 수 있는 경우 이를 강제로 사용하는 더 쉬운 방법은 활성화되도록 부트로더를 수정하는 것입니다(커널 2.6.16 기준). 이 구성은 배포판에 따라 다르므로 올바르게 설정하려면 배포판 설명서를 참조하세요. 커널 부팅 라인에서 hpet=enable또는 를 활성화해야 합니다 clocksource=hpet(이 역시 커널 버전이나 배포판에 따라 다르며 일관된 정보를 찾지 못했습니다).
이는 방문자가 HPET 타이머를 사용하고 있음을 보장합니다.
참고: 내 커널 3.5에서는 Linux가 hpet 타이머를 자동으로 선택하는 것 같습니다.
FreeBSD 게스트 HPET 구성
FreeBSD에서는 다음 명령을 실행하여 사용 가능한 타이머를 확인할 수 있습니다:
sysctl kern.timecounter.choice
현재 선택된 타이머는 다음을 통해 확인할 수 있습니다.
sysctl kern.timecounter.hardware
FreeBSD 9.1은 자동으로 다른 타이머 제공자보다 HPET를 선호하는 것 같습니다.
Todo: FreeBSD에서 HPET를 강제하는 방법.
하이퍼바이저 HPET 내보내기
KVM은 호스트가 HPET를 지원할 때 자동으로 HPET를 내보내는 것으로 보입니다. 그러나 Linux 게스트의 경우 자동으로 내보내지는 또 다른 시계인 kvm-clock(호스트 TSC의 반가상화 버전)을 선호합니다. 일부 사람들은 선호하는 시계에 문제가 있다고 보고했으며, 마일리지가 다를 수 있습니다. 게스트에서 HPET를 강제하려면 위 섹션을 참조하세요.
기본적으로 VirtualBox는 HPET 시계를 게스트로 내보내지 않으며 GUI에는 그렇게 하는 옵션이 없습니다. 명령줄을 사용하여 가상 머신이 종료되었는지 확인해야 합니다. 명령은 다음과 같습니다:
./VBoxManage modifyvm "VM NAME" --hpet on
위 변경 후에도 게스트가 HPET 이외의 클럭 소스를 계속 선택하는 경우 커널이 HPET 클럭을 클럭 소스로 사용하도록 강제하는 방법에 대한 위 섹션을 참조하세요.
답변2
고급화를 촉발하는 것은 게스트가 아니라 호스트가 해야 합니다. 따라서 호스트 컴퓨터에서 해당 트리거 레벨을 낮추어야 합니다.
답변3
호스트에서 kvm CPU는 프로세스처럼 보입니다. 확장 메커니즘은 프로세스를 관찰하지 않고 전체 CPU 소비만 관찰합니다.
일반적으로 모범 사례는 VM을 실행할 때 CPU 확장/제한 등을 비활성화하는 것입니다.