Software lockout

Dalam multiprosesor sistem komputer, software lockout adalah masalah penurunan kinerja karena menunggu kali menganggur dihabiskan oleh CPU dalam kernel -level bagian kritis . Software lockout adalah penyebab utama dari skalabilitas degradasi dalam sistem multiprosesor, berpose batas pada jumlah maksimum yang berguna prosesor. Untuk mengurangi fenomena tersebut, kernel harus dirancang untuk memiliki nya bagian penting sesingkat mungkin, karena itu membusuk setiap struktur data dalam substruktur yang lebih kecil.

Kernel-level bagian kritis

Pada kebanyakan sistem multiprosesor, masing-masing jadwal prosesor dan kontrol itu sendiri, oleh karena itu tidak ada "pengawas" prosesor, dan kernel struktur data secara global bersama, bagian dari kode yang mengakses struktur-struktur data bersama adalah bagian penting . Pilihan desain ini dibuat untuk meningkatkan scaling, keandalan dan modularitas. Contoh struktur data kernel tersebut siap daftar dan saluran komunikasi .

"Konflik" terjadi ketika lebih dari satu prosesor sedang mencoba untuk mengakses sumber daya yang sama (sebagian memori) pada waktu yang sama. Untuk mencegah ras kritis dan inkonsistensi , hanya satu prosesor ( CPU ) pada waktu tertentu diperbolehkan untuk mengakses tertentu struktur data (sebagian memori), sementara CPU lain mencoba untuk mengakses pada saat yang sama adalah terkunci-out , menunggu dalam status siaga .

Tiga kasus dapat dibedakan saat ini menunggu idle (1) yang diperlukan (2) nyaman dan (3) tidak nyaman. The menganggur menunggu diperlukan ketika akses adalah untuk daftar siap untuk tingkat rendah penjadwalan operasi. The menganggur menunggu tidak diperlukan tapi nyaman dalam hal bagian kritis untuk sinkronisasi / IPC operasi, yang membutuhkan waktu kurang dari satu context switch (executing lain proses untuk menghindari menganggur menunggu). Menganggur menunggu bukannya tidak nyaman dalam kasus bagian kritis kernel untuk manajemen perangkat , hadir dalam kernel monolitik saja. Sebuah mikrokernel bukan jatuh pada hanya dua yang pertama dari kasus di atas.

Dalam sistem multiprosesor, sebagian besar konflik adalah kernel konflik-tingkat, karena akses ke bagian level kernel kritis, dan dengan demikian periode menunggu menganggur yang dihasilkan oleh mereka memiliki dampak yang besar dalam penurunan kinerja. Kali ini menunggu menganggur meningkatkan jumlah rata-rata prosesor menganggur dan dengan demikian menurunkan skalabilitas dan efisiensi relatif .

Studi analitis

Mengambil sebagai parameter rata-rata selang waktu yang dihabiskan oleh processor di level kernel bagian kritis (L, untuk waktu dalam keadaan terkunci), dan rata-rata selang waktu yang dihabiskan oleh prosesor dalam tugas-tugas di luar bagian kritis (E), rasio L / E sangat penting dalam mengevaluasi software lockout.

Nilai-nilai khas untuk L / E berkisar 0,01-0,1. Dalam sistem dengan rasio L / E 0,05, misalnya, jika ada 15 CPU, diharapkan bahwa rata-rata 1 CPU akan selalu idle, dengan 21 CPU, 2,8 akan menganggur, dengan 40 CPU, 19 akan menganggur, dengan 41 CPU, 20 akan menganggur. Oleh karena itu menambahkan lebih dari 40 CPU untuk sistem yang akan sia-sia. Secara umum, untuk setiap nilai L / E, ada ambang batas untuk jumlah maksimum CPU yang berguna.

Mitigasi Software lockout

Untuk mengurangi degradasi kinerja perangkat lunak lockout ke tingkat yang wajar (L / E antara 0,05 dan 0,1), kernel dan / atau sistem operasi harus dirancang sesuai. Secara konseptual, solusi yang paling valid adalah untuk menguraikan setiap struktur data kernel di substruktur independen yang lebih kecil, masing-masing memiliki waktu elaborasi lebih pendek. Hal ini memungkinkan lebih dari satu CPU untuk mengakses struktur data asli.

Banyak uniprocessor sistem dengan domain perlindungan hirarkis , telah diperkirakan menghabiskan sampai 50% dari waktu melakukan "mode supervisor" operasi. Jika sistem seperti ini diadaptasi untuk multiprocessing dengan menetapkan kunci pada setiap akses ke "negara pengawas", L / E akan mudah lebih besar dari 1, sehingga sistem dengan bandwidth yang sama dari uniprocessor meskipun jumlah CPU.