Quan sát:
Tôi có một máy chủ HP với CPU lõi kép AMD (Turion II Neo N40L) có thể mở rộng tần số từ 800 đến 1500 MHz. Thang đo tần số hoạt động theo FreeBSD 9 và dưới Ubuntu 12.04 với nhân Linux 3.5. Tuy nhiên, khi tôi đặt FreeBSD 9 trong môi trường KVM lên trên Ubuntu, thang đo tần số không hoạt động. Khách (do đó FreeBSD) không phát hiện tần số tối thiểu và tối đa và do đó không mở rộng bất cứ điều gì khi chiếm dụng CPU cao hơn. Trên máy chủ (như Ubuntu), quy trình KVM sử dụng từ 80 đến 140% tài nguyên CPU nhưng không xảy ra sự thay đổi tần số, tần số vẫn ở mức 800 MHz, mặc dù khi tôi chạy bất kỳ quy trình nào khác trên cùng một hộp Ubuntu, bộ điều khiển ondemand nhanh chóng quy mô tần số đến 1500 MHz!

Mối quan tâm và câu hỏi:
Tôi không hiểu làm thế nào CPU có thể được ảo hóa, và nếu nó là tùy thuộc vào khách để thực hiện việc chia tỷ lệ thích hợp. Nó có yêu cầu một số tính năng CPU được tiếp xúc với khách để làm việc này không?

Apendix:
Các sau Red Hat phát hành lưu ý có xu hướng đề nghị tần số đó nhân rộng ra để làm việc ngay cả trong một môi trường ảo hóa (xem chương 6.2.2 và 6.2.3), nghĩ lưu ý không để địa chỉ mà công nghệ ảo hóa công việc này với (KVM, Xen , Vân vân.?)

Để biết thông tin, cpufreq-infođầu ra trên Ubuntu là:

$ cpufreq-info
cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, 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)

Lý do tôi muốn tính năng này hoạt động là: tiết kiệm năng lượng, chạy êm hơn (ít nóng hơn) và cũng tò mò đơn giản để hiểu rõ hơn lý do tại sao điều này không hoạt động và làm thế nào để nó hoạt động.

Tôi đã tìm thấy giải pháp nhờ vào mẹo được đưa ra bởi Nils và một bài viết hay .

Điều chỉnh Mình làm thống đốc DVFS CPU

Bộ điều chỉnh ondemand có một bộ các tham số để điều khiển khi nó khởi động thang đo tần số động (hoặc DVFS cho điện áp động và thang đo tần số). Các tham số được đặt dưới cây sysfs:/sys/devices/system/cpu/cpufreq/ondemand/

Một trong những tham số này up_thresholdgiống như tên gợi ý là một ngưỡng (đơn vị là% của CPU, tôi không tìm ra mặc dù đây là lõi trên mỗi lõi hoặc được hợp nhất) ở trên mà thống đốc ondemand khởi động và bắt đầu thay đổi tần số một cách linh hoạt.

Để thay đổi nó thành 50% (ví dụ) bằng sudo rất đơn giản:
sudo bash -c "echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold"

Nếu bạn đã root, một lệnh thậm chí đơn giản hơn là có thể:
echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold

Lưu ý: những thay đổi đó sẽ bị mất sau lần khởi động lại máy chủ tiếp theo. Bạn nên thêm chúng vào một tệp cấu hình được đọc trong khi khởi động, như /etc/init.d/rc.localtrên Ubuntu.

Tôi đã phát hiện ra rằng máy khách VM của tôi, mặc dù tiêu thụ rất nhiều CPU (80-140%) trên máy chủ đã phân phối tải trên cả hai lõi, do đó, không có lõi đơn nào vượt quá 95%, do đó, với sự bực tức của tôi, là ở mức 800 MHz. Bây giờ với bản vá trên, CPU tự động thay đổi tần số trên mỗi lõi nhanh hơn nhiều, phù hợp với nhu cầu của tôi hơn, 50% dường như là ngưỡng tốt hơn cho việc sử dụng khách của tôi, số dặm của bạn có thể thay đổi.

Tùy chọn, xác minh nếu bạn đang sử dụng HPET

Có thể một số ứng dụng mà bộ định thời triển khai không chính xác có thể bị ảnh hưởng bởi DVFS. Đây có thể là một vấn đề trên máy chủ và / hoặc môi trường khách, mặc dù máy chủ có thể có một số thuật toán phức tạp để cố gắng giảm thiểu điều này. Tuy nhiên, CPU hiện đại có TSC (Bộ đếm thời gian) mới hơn, độc lập với tần số CPU / lõi hiện tại, đó là: hằng số (hằng_tsc), bất biến (invariant_tsc) hoặc không dừng (nonstop_tsc), hãy xem bài viết về Chromium này về đồng bộ hóa TSC để biết thêm thông tin về mỗi. Vì vậy, nếu CPU của bạn được trang bị một trong TSC này, bạn không cần phải ép HPET. Để xác minh xem CPU chủ của bạn có hỗ trợ chúng hay không, hãy sử dụng lệnh tương tự (thay đổi tham số grep thành tính năng CPU tương ứng, ở đây chúng tôi kiểm tra TSC không đổi):

$ grep constant_tsc /proc/cpuinfo

Nếu bạn không có một trong những TSC hiện đại này, bạn nên:

1. HPET hoạt động, điều này được mô tả ở đây sau;
2. Không sử dụng CPU DVFS nếu bạn có bất kỳ ứng dụng nào trong VM dựa trên thời gian chính xác, đây là ứng dụng được Red Hat khuyên dùng .

Một giải pháp an toàn là kích hoạt bộ hẹn giờ HPET (xem bên dưới để biết thêm chi tiết), chúng truy vấn chậm hơn so với TSC (TSC nằm trong CPU, so với HPET trong bo mạch chủ) và có lẽ không chính xác (HPET> 10 MHz; TSC thường là xung nhịp CPU tối đa) nhưng chúng đáng tin cậy hơn nhiều, đặc biệt là trong cấu hình DVFS nơi mỗi lõi có thể có tần số khác nhau. Linux đủ thông minh để sử dụng bộ đếm thời gian tốt nhất hiện có, nó sẽ dựa vào TSC đầu tiên, nhưng nếu thấy không đáng tin cậy, nó sẽ sử dụng bộ HPET. Điều này hoạt động tốt trên các hệ thống máy chủ (kim loại trần), nhưng do không phải tất cả thông tin được xuất khẩu đúng bởi trình ảo hóa, đây là một thách thức đối với VM khách để phát hiện TSC hoạt động kém. Bí quyết sau đó là buộc phải sử dụng HPET trong máy khách, mặc dù bạn sẽ cần nhà cung cấp dịch vụ ảo hóa để cung cấp nguồn đồng hồ này cho khách!

Dưới đây bạn có thể tìm cách định cấu hình và / hoặc kích hoạt HPET trên Linux và FreeBSD.

Cấu hình HPET Linux

HPET, hay bộ hẹn giờ sự kiện có độ chính xác cao, là bộ hẹn giờ phần cứng mà bạn có thể tìm thấy trong hầu hết các PC hàng hóa kể từ năm 2005. Bộ hẹn giờ này có thể được sử dụng hiệu quả bởi HĐH hiện đại (nhân Linux hỗ trợ nó từ 2.6, hỗ trợ ổn định trên FreeBSD kể từ 9.x mới nhất nhưng được giới thiệu trong 6.3 ) để cung cấp thời gian nhất quán cho quản lý năng lượng CPU. Nó cho phép xây dựng các triển khai lập lịch trình tích tắc dễ dàng hơn .

Về cơ bản HPET giống như một rào cản an toàn mà ngay cả khi máy chủ có DVFS hoạt động, các sự kiện thời gian của máy chủ và khách sẽ ít bị ảnh hưởng.

Có một bài viết hay của IBM về việc kích hoạt HPET , nó giải thích cách xác minh bộ đếm thời gian phần cứng nào mà kernel của bạn đang sử dụng và có sẵn. Tôi cung cấp ở đây một bản tóm tắt ngắn gọn:

Kiểm tra (các) bộ hẹn giờ phần cứng khả dụng:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource

Kiểm tra bộ hẹn giờ hoạt động hiện tại:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource

Cách đơn giản hơn để buộc sử dụng HPET nếu bạn có sẵn là sửa đổi bộ tải khởi động của bạn để yêu cầu kích hoạt nó (kể từ kernel 2.6.16). Cấu hình này phụ thuộc vào phân phối, vì vậy vui lòng tham khảo tài liệu phân phối của riêng bạn để đặt đúng. Bạn nên kích hoạt hpet=enablehoặc clocksource=hpettrên dòng khởi động kernel (điều này một lần nữa phụ thuộc vào phiên bản kernel hoặc phân phối, tôi không tìm thấy bất kỳ thông tin mạch lạc nào).
Điều này đảm bảo rằng khách đang sử dụng bộ hẹn giờ HPET.

Lưu ý: trên kernel 3.5 của tôi, Linux dường như tự động nhận bộ đếm thời gian hpet.

Cấu hình HPET của khách FreeBSD

Trên FreeBSD, người ta có thể kiểm tra bộ định thời nào có sẵn bằng cách chạy:
sysctl kern.timecounter.choice

Bộ đếm thời gian hiện được chọn có thể được xác minh bằng:
sysctl kern.timecounter.hardware

FreeBSD 9.1 dường như tự động thích HPET hơn nhà cung cấp hẹn giờ khác.

Todo: cách buộc HPET trên FreeBSD.

Xuất khẩu HPET

KVM dường như tự động xuất HPET khi máy chủ có hỗ trợ cho nó. Tuy nhiên, đối với khách Linux, họ sẽ thích đồng hồ được xuất tự động khác là đồng hồ kvm (phiên bản ảo hóa của máy chủ TSC). Một số người báo cáo sự cố với đồng hồ ưa thích, số dặm của bạn có thể thay đổi. Nếu bạn muốn buộc HPET trong khách, hãy tham khảo phần trên.

VirtualBox không xuất đồng hồ HPET cho khách theo mặc định và không có tùy chọn nào để làm như vậy trong GUI. Bạn cần sử dụng dòng lệnh và đảm bảo VM được tắt. lệnh là:

./VBoxManage modifyvm "VM NAME" --hpet on

Nếu khách tiếp tục chọn một nguồn khác ngoài HPET sau khi thay đổi ở trên, vui lòng tham khảo phần bên trên về cách buộc kernel sử dụng đồng hồ HPET làm nguồn.

Nó không phải là khách kích hoạt cao cấp - chủ nhà phải làm điều này. Vì vậy, bạn phải hạ mức kích hoạt theo máy chủ.

trên máy chủ, một cpu kvm trông giống như một quá trình. Cơ chế mở rộng không theo dõi các quy trình, chỉ có mức tiêu thụ cpu tổng thể.

và nói chung cách tốt nhất là vô hiệu hóa cpu / throttling / etc khi chạy VM