IKM pasti dapat terjadi selama operasi normal. Desktop rumah saya memiliki SMI yang digerakkan oleh chipset setiap satu setengah detik yang diaktifkan di chipset. Saya juga melihat beberapa server yang memilikinya dua kali per detik karena skema penskalaan frekuensi CPU yang digerakkan oleh BIOS. Namun, beberapa sistem dapat berjalan dalam jangka waktu yang lama tanpa terjadi SMI sehingga sangat tergantung.
Pertanyaan #1:hwlatdetect adalah salah satu opsi untuk mendeteksi latensi SMI yang terjadi di sistem Anda. BIOSBITS adalah opsi lain yang merupakan CD yang dapat di-boot yang dapat mengidentifikasi apakah SMI sedang terjadi. Anda juga dapat menulis pengujian Anda sendiri dengan membuat modul kernel yang berputar dalam satu lingkaran dan mengambil stempel waktu (menggunakan RDTSC). Jika Anda melihat celah panjang antara dua pembacaan stempel waktu, Anda dapat berkonsultasi dengan CPU MSR 0x34 untuk melihat apakah penghitung SMI bertambah yang menunjukkan bahwa SMI terjadi.
Jika Anda ingin membuat SMI, Anda dapat membuat modul kernel yang menjalankan instruksi OUT CPU ke port 0xb2, mis. tulis nilai 0 ke port ini. (Anda juga dapat mengatur waktu SMI ini dengan mengumpulkan stempel waktu tepat sebelum dan sesudah penulisan ke port 0xB2).
Pertanyaan #2, IKM beroperasi pada lapisan di bawah OS sehingga OS mana yang Anda pilih, tidak akan berdampak apa pun.
Pertanyaan #3:BIOSBITS merekomendasikan agar latensi SMI disimpan di bawah 150 mikrodetik.
SMI akan menempatkan sistem Anda ke mode SMM (System Management Mode), yang akan menunda eksekusi normal kernel selama periode waktu penanganan SMI. Dengan kata lain, SMMi bukanlah mode nyata atau mode terproteksi seperti yang kita ketahui tentang operasi normal kernel, melainkan menjalankan beberapa instruksi khusus yang disimpan di SMRAM (disimpan di Firmware Bios). Untuk mendeteksi latensinya, Anda dapat mencoba memicu SMI (dapat dihasilkan oleh perangkat lunak) dan mencoba mengetahui total waktu yang dihabiskan dalam mode SMM. Untuk melakukannya, Anda dapat menulis modul kernel Linux, karena Anda memerlukan beberapa hak khusus untuk menerbitkan SMI (menurut saya).
Untuk sistem waktu nyata, menurut saya bagus jika Anda dapat menghindari gangguan seperti ini seperti SMI.
Anda dapat memeriksa apakah Interupsi Manajemen Sistem (SMI) diservis atau tidak dengan turbostat. Misalnya:
# turbostat sleep 120
[check column SMI for value greater than 0]
Tentu saja, dari situ Anda juga dapat menghitung frekuensi SMI.
Mengetahui bahwa IKM benar-benar terjadi pada tingkat tertentu merupakan informasi penting. Tetapi Anda juga ingin tahu berapa banyak waktu yang dihabiskan System Management Mode (SMM) dalam interupsi tersebut. Misalnya, jika gangguan SMI hanya sangat singkat, mungkin tidak relevan untuk aplikasi waktu nyata Anda. Di sisi lain, jika Anda memiliki hardware dengan interupsi SMI yang lama, Anda mungkin ingin berbicara dengan vendor, mengonfigurasi firmware secara berbeda (jika memungkinkan) dan atau beralih ke hardware lain dengan SMM yang tidak terlalu mengganggu.
Alat perf memiliki mode yang mengukur berapa banyak siklus yang dihabiskan di SMM selama SMI (menggunakan informasi yang disediakan oleh penghitung CPU tertentu). Contoh:
# perf stat -a -A --smi-cost -- sleep 120
Performance counter stats for 'system wide':
SMI cycles% SMI#
CPU0 0.0% 0
CPU1 0.0% 0
CPU2 0.0% 0
CPU3 0.0% 0
120.002927948 seconds time elapsed
Anda juga dapat melihat nilai mentah dengan:
# perf stat -a -A --smi-cost --metric-only -- sleep 120
Dari situ Anda dapat menghitung berapa banyak waktu rata-rata yang dibutuhkan SMI pada mesin Anda. (bagi perbedaan siklus dengan jumlah siklus per satuan waktu).
Sangat masuk akal untuk memeriksa ulang hasil berbasis penghitung CPU dengan yang empiris.
Anda dapat menggunakan Detektor Latensi Perangkat Keras Linux yang terintegrasi dalam Kernel Linux. Contoh penggunaan:
# echo hwlat > /sys/kernel/debug/tracing/current_tracer
# echo 1 > /sys/kernel/debug/tracing/tracing_thresh
# watch -d -n 5 cat /sys/kernel/debug/tracing/tracing_max_latency
# echo "Don't forget to disable it again"
# echo nop > /sys/kernel/debug/tracing/current_tracer
Alat tersebut tersedia di CentOS/RHEL 7 dan seharusnya juga tersedia di distribusi lain.
Mengenai angka rata-rata:Baru-baru ini saya menemukan server ProLiant Gen8 Xeon HP 2011-ish yang menembakkan 504 SMI per menit. Perf menghitung laju 0,1 % dalam SMM, dan berdasarkan nilai penghitung, waktu rata-rata yang dihabiskan dalam SMI setinggi beberapa mikrodetik - tetapi pendeteksi hwlat Linux tidak mendeteksi gangguan setinggi itu pada sistem tersebut.
Nilai SMI tersebut sesuai dengan dokumen HP dalam panduan Konfigurasi dan penyetelan Server ProLiant HPE untuk aplikasi latensi rendah (Oktober, 2017):
Menonaktifkan Interupsi Manajemen Sistem ke prosesor memberikan salah satu manfaat terbesar untuk lingkungan latensi rendah. Menonaktifkan Daya Prosesor dan Pemantauan Pemanfaatan SMI memiliki efek terbesar karena menghasilkan interupsi prosesor delapan kali per detik di G6 dan server yang lebih baru.
(tekankan pada saya; dan panduan itu juga mendokumentasikan sumber SMI lainnya)
Di papan Supermicro dengan Intel Atom C3758 dan sistem Intel NUC (i5-4250U) milik saya, tidak ada SMI yang dihitung.
Pada laptop Dell berbasis Intel i7-6600U, sistem melaporkan 8 SMI per menit, tetapi penghitung aperf lebih rendah daripada penghitung siklus (tanpa henti) yang seharusnya tidak terjadi.