Skip to content

emka.web.id

Menu
  • Home
  • Indeks Artikel
  • Tutorial
  • Tentang Kami
Menu

AMD Memiliki Optimasi Kinerja Yang Bagus Dengan Linux 6.8

Mengantri ke cabang x86/cpu tip/tip.git sebelum jendela penggabungan Linux 6.8 dibuka dalam sebulan adalah pengoptimalan yang terbukti berguna dalam skenario cloud/VM. Perubahan yang dijadwalkan untuk diperkenalkan di Linux 6.8 adalah untuk tidak membuat serialisasi akses register khusus model (MSR) pada prosesor AMD (dan Hygon turunan Zen 1). CPU Intel perlu membuat serial akses MSR untuk tenggat waktu Time Stamp Counter (TSC) (IA32_TSC_DEADLINE) dan MSR X2APIC sehingga hal tersebut menjadi perilaku default untuk penggunaan Linux x86_64. Perilaku tersebut sebelumnya dijelaskan oleh seorang insinyur Intel Linux sebagai: "Alasan mengapa kernel menggunakan semantik yang berbeda adalah karena SDM berubah (kira-kira pada akhir tahun 2017). SDM berubah karena orang-orang di Intel mengaudit semua pagar yang direkomendasikan di SDM dan menyadari bahwa pagar x2apic tidak mencukupi. Mengapa nyeri MFENCE dinilai kurang? WRMSR sendiri biasanya merupakan instruksi serialisasi. Tidak diperlukan pagar karena instruksinya sendiri yang membuat serial semuanya. Namun, ada pengecualian eksplisit untuk perilaku serialisasi ini yang ditulis ke dalam dokumentasi instruksi WRMSR untuk dua kelas MSR: IA32_TSC_DEADLINE dan MSR X2APIC. Kembali ke x2apic: WRMSR *tidak* membuat serial dalam kasus khusus ini. Namun mengapa MFENCE tidak mencukupi? MFENCE membuat penulisan terlihat, tetapi hanya memengaruhi instruksi pemuatan/penyimpanan. Sayangnya WRMSR bukanlah instruksi memuat/menyimpan dan tidak terpengaruh oleh MFENCE. Ini berarti bahwa WRMSR non-serial dapat disusun ulang oleh CPU untuk dieksekusi bahkan sebelum penulisan yang dibuat oleh MFENCE terjadi. Ini berarti bahwa IPI x2apic secara teoritis dapat dipicu sebelum ada data (yang terlihat) untuk diproses. Apakah ini mempengaruhi sesuatu dalam praktiknya? Sejujurnya saya tidak tahu. Tampaknya sangat mungkin bahwa pada saat interupsi menggunakan data (yang belum) MFENCE, data tersebut telah terlihat, sebagian besar secara tidak sengaja. Agar aman, tambahkan pagar yang direkomendasikan SDM untuk semua WRMSR x2apic. Hal ini juga membuka pertanyaan tentang WRMSR _lainnya yang diurutkan dengan lemah: MSR_IA32_TSC_DEADLINE. Meskipun memiliki arsitektur pengurutan yang sama dengan MSR x2APIC, dalam praktiknya tampaknya hal ini jauh lebih kecil kemungkinannya menjadi masalah. Sementara penulisan ke Tabel Vektor Lokal (LVT) di dalam memori mungkin secara teori disusun ulang sehubungan dengan WRMSR dengan urutan lemah seperti TSC_DEADLINE." Jadi, kernel Linux x86/x86_64 telah ditetapkan secara default ke MFENCE dan LFENCE tetapi tanpa pemeriksaan khusus CPU apa pun Ternyata CPU AMD tidak memerlukan ini dan menghindari akses MSR serial untuk TSC_DEADLINE/X2APIC dapat membantu kinerja.

Patch yang dijadwalkan untuk Linux 6.8 tidak akan lagi membuat serial akses MSR pada prosesor AMD. Patch ini menguraikan manfaat kinerja dari perubahan ini: "AMD tidak memerlukan penghalang sinkronisasi saat mengakses kelompok MSR tertentu. Jangan dikenakan penalti yang tidak perlu di sana. ... Pada sistem AMD Zen4 dengan 96 inti, ipi-bench yang dimodifikasi pada VM menunjukkan tingkat IPI x2AVIC 3% hingga 4% lebih rendah daripada tingkat IPI AVIC. ipi-bench dimodifikasi sehingga IPI dikirim antara dua vCPU di CCX yang sama. Ini juga memerlukan penyematan vCPU ke inti fisik mencegah latensi apa pun. Ini menyimulasikan kasus penggunaan menyematkan vCPU ke thread CCX tunggal untuk menghindari latensi interupsi IPI. ... Dengan konfigurasi di atas: *) Performa diukur menggunakan ipi-bench untuk AVIC: Latensi Rata-rata: 1124.98ns [Waktunya mengirim IPI dari satu vCPU ke vCPU lain] Throughput kumulatif: 42,6759M/s [Jumlah total IPI yang dikirim dalam satu detik dari 48 vCPU secara bersamaan] *) Performa diukur menggunakan ipi-bench untuk x2AVIC: Latensi Rata-rata: 1172.42ns [Waktunya mengirim IPI dari satu vCPU ke vCPU lain] Throughput kumulatif: 40,9432M/s [Jumlah total IPI yang dikirim dalam satu detik dari 48 vCPU secara bersamaan] Dari atas, latensi x2AVIC ~4% lebih tinggi daripada AVIC. Namun yang diharapkan adalah performa x2AVIC lebih baik atau setara dengan AVIC. Setelah menganalisis tangkapan kinerja, diamati bahwa banyak waktu yang dihabiskan di lemah_wrmsr_fence() dipanggil oleh x2apic_send_IPI(). Dengan perbaikan untuk melewati lemah_wrmsr_fence() *) Performa diukur menggunakan ipi-bench untuk x2AVIC: Latensi Rata-rata: 1117.44ns [Waktunya mengirim IPI dari satu vCPU ke vCPU lain] Throughput kumulatif: 42,9608M/s [Jumlah total IPI yang dikirim dalam satu detik dari 48 vCPU secara bersamaan] Membandingkan kinerja x2AVIC dengan dan tanpa perbaikan, terlihat peningkatan kinerja sebesar ~4%. Performa yang ditangkap menggunakan ipi-bench yang tidak dimodifikasi menggunakan opsi `mesh-ipi` dengan dan tanpaweak_wrmsr_fence() pada sistem Zen4 juga menunjukkan peningkatan performa yang signifikan tanpaweak_wrmsr_fence(). Opsi `mesh-ipi` mengabaikan CCX atau CCD dan hanya memilih vCPU acak. Throughput rata-rata (10 iterasi) denganweak_wrmsr_fence(), Throughput kumulatif: 4933374 IPI/dtk Throughput rata-rata (10 iterasi) tanpaweak_wrmsr_fence(), Throughput kumulatif: 6355156 IPI/s"Dengan perilaku akses MSR ini yang telah menjadi perilaku default kernel Linux x86_64 selama beberapa tahun, agak mengejutkan bahwa hal ini tidak diketahui lebih awal oleh AMD atau mitra mereka untuk pengoptimalan. Kecuali jika ada masalah yang muncul pada patch tersebut, karena patch tersebut merupakan bagian dari cabang TIP, patch tersebut juga akan menjadi bagian dari perubahan kernel Linux 6.8 untuk awal tahun 2024.

Itulah berita seputar AMD Memiliki Optimasi Kinerja Yang Bagus Dengan Linux 6.8, semoga bermanfaat. Disadur dari Phoronix.com.Artikel Diperbarui pada: November 27, 2023
Kontributor: Syauqi Wiryahasana
Model: Haifa Manik Intani
Seedbacklink

Recent Posts

TENTANG EMKA.WEB>ID

EMKA.WEB.ID adalah blog seputar teknologi informasi, edukasi dan ke-NU-an yang hadir sejak tahun 2011. Kontak: kontak@emka.web.id.

©2024 emka.web.id Proudly powered by wpStatically