Mengapa rentang kebaikan berkisar antara -20 hingga 19?


22

The niceperintah memungkinkan Anda untuk mengatur prioritas penjadwalan ( "kebaikan") dari sebuah program. Pada semua sistem mirip Unix yang saya gunakan, kebaikan ditentukan oleh berbagai bilangan bulat, di mana -20 adalah prioritas penjadwalan yang paling menguntungkan, 0 adalah default, dan 19 adalah yang paling tidak menguntungkan.

Memiliki 0 sebagai standarnya sudah cukup intuitif, tetapi mengapa -20 dan 19 dipilih sebagai titik akhir kisaran? Mengapa tidak -128 dan 127, yang akan pas dengan byte 8-bit yang sudah ditandatangani? Atau mengapa tidak -100 hingga 100, yang lebih intuitif untuk manusia yang berpikiran desimal, atau serupa tetapi sedikit lebih ergonomis, -99 hingga 99? Apakah rentang -20 hingga 19 dipilih secara sewenang-wenang, atau apakah ada kaitannya dengan internal scheduler yang niceawalnya berinteraksi? (Saya mengerti bahwa tidak ada hubungan seperti itu hari ini, setidaknya untuk Linux, yang penjadwal menggunakan prioritas dalam kisaran 0 hingga 139. Namun, saya tertarik pada alasan historis kisaran -20 hingga 19).


4
Saya tidak dapat menemukan referensi yang menjelaskan mengapa rentang tertentu dipilih, tetapi perhatikan bahwa pada V7 prioritas masuk ke byte yang ditandatangani - lihat proc.h - dan fungsi setpri mengatur prioritas min(127, (recent CPU usage on a scale of 0 to 15) + 50 + pp->p_nice - 20), dan prioritas <25 dicadangkan untuk proses melakukan hal-hal yang tidak pernah terputus. Jadi kebaikan harus semacam jangkauan terbatas.
Mark Plotnick

Jawaban:


7

Tingkat kebaikan internal adalah 0-39, tetapi kenaikannya positif atau negatif. Sumber . Jadi jawabannya adalah bahwa angka-angka (positif dan negatif) yang diterima oleh niceperintah adalah apa yang membuat Anda dari 20, tingkat default, ke mana saja di kisaran 0-39.

Jadi mengapa 0-39? Kisaran spesifik adalah apa yang berhasil dalam implementasi asli desainer. Alasan nilai yang lebih positif lebih bagus adalah bahwa tingkat yang bagus ditambahkan ke penggunaan CPU baru-baru ini dalam menentukan prioritas. Untuk memberikan penjadwalan round-robin perkiraan, kernel melacak berapa banyak CPU setiap proses telah dibakar baru-baru ini dan beralih ke proses yang belum memiliki banyak. Semakin tinggi level yang bagus, semakin banyak waktu CPU sepertinya proses telah, dan semakin sering penjadwal akan menempatkan proses itu untuk tidur atau membiarkannya tertidur. Lihat Desain Sistem Operasi UNIX oleh Maurice J. Bach, Prentice-Hall 1986, detik. 8.1 (8.1.4 untuk kebaikan khususnya). ISBN 0-13-201799-7.


1
Anda salah ketika berasumsi bahwa penjadwal akan membuat proses tidur jika memiliki nilai bagus buruk. Sebagai gantinya, penjadwal tidak akan membangunkan proses tidur jika ada proses lain yang siap dijalankan dan proses ini memiliki tingkat yang lebih baik. Perhatikan bahwa suatu proses ditidurkan, ketika ia memanggil syscall yang memberlakukan sleep pada sumber daya atau ketika suatu proses menghabiskan itu kuantum CPU dan ada proses lebih istimewa lainnya menunggu CPU.
schily

-4

Anda salah: Jika Anda menggunakan UNIX di mana antarmuka nice () masih masuk akal, NZEROadalah nilai bagus default dan NZERO is 20.

Untuk membuatnya lebih jelas: Anda bertanya tentang perintah nicedan pada saat yang sama menyebutkan level absolut, tetapi perintah yang bagus tidak mengelola nilai absolut melainkan kenaikan relatif ke level saat ini. Dalam hal keadaan default, level yang bagus NZEROadalah 20.

Nilai yang bagus adalah 0..2 * NZERO-1 atau 0..39

Perhatikan bahwa sementara penjadwal UNIX default mungkin masih dapat melakukan sesuatu yang bermanfaat dengan nilai yang bagus, tidak ada artinya jika Anda menggunakan penjadwal khusus, misalnya penjadwal waktu nyata.


2
Anda tampaknya membingungkan antarmuka shell dan antarmuka C. Pertanyaan ini tentang niceperintah shell.
Gilles 'SO- stop being evil'

Nah, Andalah yang membingungkan segalanya. Perintah yang bagus hanya tahu tentang delta tetapi pertanyaannya menyebutkan nilai yang bagus. Pertanyaannya adalah tentang nilai-nilai yang bagus dan saya menjawab ini.
schily
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.