Perjalanan panjang untuk mewujudkan "preemption malas" di scheduler CPU Linux

 (lwn.net)
3 poin oleh GN⁺ 2024-10-20 | 1 komentar | Bagikan ke WhatsApp
  • Scheduler CPU di kernel menyediakan beberapa mode preemption yang mewujudkan kompromi antara throughput sistem dan waktu respons.
  • Pada September 2023, dalam diskusi tentang penjadwalan, konsep "preemption malas (lazy preemption)" diusulkan, yang dapat menyederhanakan penjadwalan kernel sekaligus memberikan hasil yang lebih baik.
  • Konsep ini sempat sunyi untuk sementara waktu, tetapi muncul kembali melalui rangkaian patch dari Peter Zijlstra.

Mode preemption kernel saat ini

  • PREEMPT_NONE: Preemption hanya diizinkan ketika tugas yang sedang berjalan menghabiskan jatah time slice-nya.
  • PREEMPT_VOLUNTARY: Menambahkan banyak titik di dalam kernel tempat preemption dapat terjadi bila diperlukan.
  • PREEMPT_FULL: Preemption dimungkinkan di hampir semua titik, kecuali ketika spinlock sedang dipegang.
  • PREEMPT_RT: Lebih memprioritaskan preemption daripada kebanyakan hal lain, dan membuat sebagian besar kode spinlock juga dapat dipreempt.

Pengenalan preemption malas

  • Patch preemption malas menambahkan flag baru TIF_NEED_RESCHED_LAZY untuk menunjukkan bahwa penjadwalan ulang diperlukan pada suatu saat, bukan harus segera.
  • Dalam mode preemption malas (PREEMPT_LAZY), sebagian besar event akan menetapkan flag baru ini, dan ketika kernel kembali ke ruang pengguna, pemanggilan scheduler akan dilakukan jika salah satu dari dua flag disetel.
  • Sebagai hasil dari perubahan ini, dalam mode preemption malas, sebagian besar event di kernel tidak lagi akan mempreempt tugas yang sedang berjalan.

Penghapusan cond_resched()

  • Tujuan akhir dari pekerjaan ini adalah menyisakan hanya dua mode non-real-time: PREEMPT_LAZY dan PREEMPT_FULL.
  • Mode malas akan menempati posisi di antara PREEMPT_NONE dan PREEMPT_VOLUNTARY, dan menggantikan kedua mode tersebut.
  • Saat ini, pemanggilan cond_resched() masih tersisa, dan tetap diperlukan selama mode PREEMPT_NONE dan PREEMPT_VOLUNTARY masih ada.

Ringkasan GN⁺

  • Preemption malas dapat berkontribusi pada penyederhanaan penjadwalan kernel dan memberikan latensi yang lebih dapat diprediksi.
  • Pekerjaan ini dapat membantu mengurangi ukuran kernel dan menyederhanakan kode.
  • Preemption malas menawarkan throughput yang mirip dengan PREEMPT_VOLUNTARY, tetapi masih memerlukan lebih banyak pengujian dan optimasi.
  • Proyek lain dengan fungsi serupa termasuk scheduler ULE milik FreeBSD.

Bacaan terkait

1 komentar

 
GN⁺ 2024-10-20
Komentar Hacker News

  • Hasil akhir dari upaya preemption malas adalah kernel menjadi lebih kecil dan sederhana sambil memberikan latensi yang dapat diprediksi. Ini tampak sebagai solusi yang lebih baik tanpa perlu menaburkan pemanggilan terkait scheduler di seluruh kode. Namun, untuk mencapainya akan memakan waktu.

    • Seperti EEVDF, ini menyederhanakan dan memperbaiki keadaan saat ini. Sepertinya tidak akan ada solusi yang lebih baik.

  • Tingkat preemption yang tinggi memungkinkan sistem merespons peristiwa lebih cepat. Respons cepat terhadap peristiwa seperti pergerakan mouse atau sinyal "kehancuran yang segera terjadi" dari reaktor terasa lebih memuaskan. Namun, tingkat preemption yang tinggi dapat memengaruhi throughput keseluruhan sistem. Beban kerja dengan banyak tugas intensif CPU diuntungkan jika gangguannya seminimal mungkin. Preemption yang lebih sering juga dapat menyebabkan contention lock yang lebih tinggi. Karena itu ada berbagai mode, dan mode preemption yang optimal kemungkinan bergantung pada beban kerja.

    • Saya penasaran mengapa tingkat preemption merupakan properti dari mode global, bukan properti dari peristiwa tertentu. Beberapa peristiwa seharusnya diproses dengan latensi lebih rendah daripada yang lain.

  • Kernel saat ini memiliki empat mode yang mengatur kapan satu tugas dapat dipreempt untuk tugas lain.

    • Saya penasaran apakah ini berkaitan dengan tugas kernel, tugas pengguna, atau keduanya.

  • Saya tidak dapat menemukan angka terkait patch di thread yang ditautkan. Mungkin sudah ada benchmarking awal yang dilakukan yang bisa menunjukkan potensi nyata dari perubahan ini.

  • Saya penasaran seberapa erat scheduler terikat dengan sisa kode kernel.

    • Misalnya, jika ingin sangat menyederhanakan scheduler untuk aplikasi ilmiah yang sama sekali tidak peduli pada preemption, apakah itu bisa dilakukan dengan bersih dan modular, dan manfaat apa yang akan didapat.

  • Akan bagus jika preemption bisa beradaptasi berdasarkan peristiwa, tetapi mengelolanya untuk setiap peristiwa dapat merusak stabilitas sistem. Ini mirip dengan menghasilkan lead menggunakan alat seperti Tomba Finder.

    • Presisi (lead yang ditargetkan) dan efisiensi harus dijaga tetap seimbang agar semuanya berjalan lancar secara keseluruhan.