GNU/Linux >> Belajar Linux >  >> Linux

CPU host tidak menskalakan frekuensi saat tamu KVM membutuhkannya

Saya telah menemukan solusinya berkat tip yang diberikan oleh Nils dan artikel yang bagus.

Menyetel ondemand Pengatur CPU DVFS

Gubernur ondemand memiliki seperangkat parameter untuk dikontrol saat memulai penskalaan frekuensi dinamis (atau DVFS untuk penskalaan tegangan dan frekuensi dinamis). Parameter tersebut terletak di bawah pohon sysfs:/sys/devices/system/cpu/cpufreq/ondemand/

Salah satu parameter ini adalah up_threshold yang seperti namanya adalah ambang (unit adalah% dari CPU, saya belum tahu apakah ini per inti atau gabungan inti) di atas mana gubernur ondemand masuk dan mulai mengubah frekuensi secara dinamis.

Untuk mengubahnya menjadi 50% (misalnya) menggunakan sudo itu sederhana:
sudo bash -c "echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold"

Jika Anda root, perintah yang lebih sederhana dimungkinkan:
echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold

Catatan:perubahan tersebut akan hilang setelah host reboot berikutnya. Anda harus menambahkannya ke file konfigurasi yang dibaca saat boot, seperti /etc/init.d/rc.local di Ubuntu.

Saya telah menemukan bahwa VM tamu saya, meskipun mengkonsumsi banyak CPU (80-140%) pada host mendistribusikan beban pada kedua core, jadi tidak ada satu core di atas 95%, sehingga CPU, yang membuat saya jengkel, adalah tetap di 800 MHz. Sekarang dengan tambalan di atas, CPU secara dinamis mengubah frekuensi per inti jauh lebih cepat, yang lebih sesuai dengan kebutuhan saya, 50% tampaknya merupakan ambang batas yang lebih baik untuk penggunaan tamu saya, jarak tempuh Anda mungkin berbeda.

Secara opsional, verifikasi apakah Anda menggunakan HPET

Ada kemungkinan bahwa beberapa pengatur waktu yang salah menerapkan mungkin terpengaruh oleh DVFS. Ini bisa menjadi masalah pada lingkungan host dan/atau tamu, meskipun host dapat memiliki beberapa algoritme yang berbelit-belit untuk mencoba meminimalkannya. Namun, CPU modern memiliki TSC (Time Stamp Counter) yang lebih baru yang tidak tergantung pada frekuensi CPU/inti saat ini, yaitu:konstan (constant_tsc), invarian (invariant_tsc) atau nonstop (nonstop_tsc), lihat artikel Chromium ini tentang sinkronisasi ulang TSC untuk informasi lebih lanjut tentang masing-masing. Jadi jika CPU Anda dilengkapi dengan salah satu TSC ini, Anda tidak perlu memaksakan HPET. Untuk memverifikasi apakah CPU host Anda mendukungnya, gunakan perintah serupa (ubah parameter grep ke fitur CPU yang sesuai, di sini kami menguji TSC konstan):

$ grep constant_tsc /proc/cpuinfo

Jika Anda tidak memiliki salah satu dari TSC modern ini, Anda harus:

  1. HPET aktif, ini dijelaskan di sini setelah;
  2. Jangan gunakan CPU DVFS jika Anda memiliki aplikasi apa pun di VM yang mengandalkan pengaturan waktu yang tepat, yang direkomendasikan oleh Red Hat.

Solusi yang aman adalah mengaktifkan penghitung waktu HPET (lihat di bawah untuk detail lebih lanjut), penghitung waktu lebih lambat untuk melakukan kueri daripada yang TSC (TSC ada di CPU, vs. HPET ada di motherboard) dan mungkin tidak tepat (HPET>10MHz; TSC seringkali jam CPU maks) tetapi mereka jauh lebih andal terutama dalam konfigurasi DVFS di mana setiap inti dapat memiliki frekuensi yang berbeda. Linux cukup pintar untuk menggunakan pengatur waktu terbaik yang tersedia, pertama-tama ia akan mengandalkan TSC, tetapi jika ditemukan terlalu tidak dapat diandalkan, ia akan menggunakan yang HPET. Ini berfungsi baik pada sistem host (bare metal), tetapi karena tidak semua informasi diekspor dengan benar oleh hypervisor, ini lebih merupakan tantangan bagi VM tamu untuk mendeteksi TSC yang berperilaku buruk. Triknya adalah dengan memaksa untuk menggunakan HPET di tamu, meskipun Anda memerlukan hypervisor untuk membuat sumber jam ini tersedia untuk tamu!

Di bawah ini Anda dapat menemukan cara mengonfigurasi dan/atau mengaktifkan HPET di Linux dan FreeBSD.

Konfigurasi HPET Linux

HPET, atau pengatur waktu peristiwa presisi tinggi, adalah pengatur waktu perangkat keras yang dapat Anda temukan di sebagian besar komoditas PC sejak tahun 2005. Penghitung waktu ini dapat digunakan secara efisien oleh OS modern (kernel Linux mendukungnya sejak 2.6, dukungan stabil di FreeBSD sejak 9.x terbaru tetapi diperkenalkan pada 6.3) untuk menyediakan pengaturan waktu yang konsisten untuk manajemen daya CPU. Hal ini juga memungkinkan untuk membangun implementasi penjadwalan tick-less yang lebih mudah.

Pada dasarnya HPET seperti penghalang keamanan yang bahkan jika host memiliki DVFS aktif, tuan rumah dan acara pengaturan waktu tamu tidak akan terlalu terpengaruh.

Ada artikel bagus dari IBM mengenai pengaktifan HPET, ini menjelaskan cara memverifikasi timer perangkat keras mana yang digunakan kernel Anda, dan mana yang tersedia. Saya berikan di sini ringkasan singkat:

Memeriksa timer perangkat keras yang tersedia:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource

Memeriksa timer aktif saat ini:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource

Cara yang lebih sederhana untuk memaksa penggunaan HPET jika Anda memilikinya adalah dengan memodifikasi boot loader Anda untuk meminta untuk mengaktifkannya (sejak kernel 2.6.16). Konfigurasi ini bergantung pada distribusi, jadi silakan lihat dokumentasi distribusi Anda sendiri untuk menyetelnya dengan benar. Anda harus mengaktifkan hpet=enable atau clocksource=hpet pada baris boot kernel (sekali lagi ini bergantung pada versi atau distribusi kernel, saya tidak menemukan informasi yang koheren).
Ini memastikan bahwa tamu menggunakan timer HPET.

Catatan:pada kernel 3.5 saya, Linux tampaknya mengambil timer hpet secara otomatis.

Konfigurasi HPET tamu FreeBSD

Di FreeBSD seseorang dapat memeriksa penghitung waktu mana yang tersedia dengan menjalankan:
sysctl kern.timecounter.choice

Timer yang dipilih saat ini dapat diverifikasi dengan:
sysctl kern.timecounter.hardware

FreeBSD 9.1 tampaknya secara otomatis lebih memilih HPET daripada penyedia pengatur waktu lainnya.

Yang harus dilakukan:cara memaksa HPET di FreeBSD.

Ekspor HPET hypervisor

KVM tampaknya mengekspor HPET secara otomatis ketika host memiliki dukungan untuk itu. Namun, untuk tamu Linux mereka akan lebih memilih jam lain yang diekspor secara otomatis yaitu kvm-clock (versi paravirtualisasi dari host TSC). Beberapa orang melaporkan masalah dengan jam pilihan, jarak tempuh Anda mungkin berbeda. Jika Anda ingin memaksa HPET di tamu, lihat bagian di atas.

VirtualBox tidak mengekspor jam HPET ke tamu secara default, dan tidak ada opsi untuk melakukannya di GUI. Anda perlu menggunakan baris perintah dan memastikan VM dimatikan. perintahnya adalah:

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

Jika tamu tetap memilih sumber lain selain HPET setelah perubahan di atas, silakan merujuk ke bagian di atas tentang cara memaksa kernel untuk menggunakan jam HPET sebagai sumber.


Bukan tamu yang memicu kelas atas - tuan rumah harus melakukan ini. Jadi, Anda harus menurunkan tingkat pemicu yang sesuai pada host.


di host, cpu kvm terlihat seperti proses. Mekanisme penskalaan tidak memantau proses, hanya konsumsi cpu secara keseluruhan.

dan umumnya praktik terbaik untuk menonaktifkan cpu scaling/throttling/etc saat menjalankan VM


Linux
  1. Mengapa OpenStack melaporkan tipe Hypervisor sebagai QEMU ketika libvirt_type adalah KVM?

  2. .bash_profile Tidak Bersumber Saat Menjalankan Su?

  3. Linux – Arch Linux :Pacman Tidak Berfungsi Saat Chroot?

  1. Mengapa Pelengkapan Otomatis Tidak Berfungsi Saat Mengetik Nama Perintah Setelah `sumber`?

  2. Masalah “File Metadata Tidak Cocok dengan Checksum” Saat Yum Menginstal atau Memperbarui Paket

  3. Bash:Mengapa skrip induk tidak berhenti di SIGINT saat skrip anak menjebak SIGINT?

  1. Kapan Seseorang Mendapatkan Pesan Kesalahan "pekerjaan:Tidak Ditemukan"?

  2. Driver untuk GTX 1080 tidak berfungsi pada tamu saat menggunakan KVM PCI Passthrough

  3. Konfigurasikan IPTables pada host KVM untuk memblokir lalu lintas jembatan tamu