3 puan yazan GN⁺ 2024-10-20 | 1 yorum | WhatsApp'ta paylaş
  • Çekirdeğin CPU zamanlayıcısı, sistem throughput’u ile yanıt süresi arasındaki ödünleşimi hayata geçiren çeşitli preemption modları sunuyor.
  • Eylül 2023’te zamanlama üzerine yapılan bir tartışmada, çekirdeğin zamanlamasını basitleştirirken daha iyi sonuçlar verebilecek bir kavram olarak "tembel preemption (lazy preemption)" önerildi.
  • Bu kavram bir süre sessiz kaldı, ancak Peter Zijlstra’nın yama serisiyle yeniden gündeme geldi.

Mevcut çekirdekteki preemption modları

  • PREEMPT_NONE: Yalnızca çalışan görev zaman dilimini tükettiğinde preemption’a izin verilir.
  • PREEMPT_VOLUNTARY: Gerektiğinde çekirdek içinde preemption’ın mümkün olduğu çok sayıda nokta ekler.
  • PREEMPT_FULL: Spinlock tutulduğu durumlar dışında, neredeyse her noktada preemption mümkündür.
  • PREEMPT_RT: Preemption’ı çoğu şeyden daha öncelikli hale getirir ve spinlock kodunun büyük bölümünü de preempt edilebilir yapar.

Tembel preemption’ın eklenmesi

  • Tembel preemption yaması, hemen değil ama bir noktada yeniden zamanlama gerektiğini göstermek için yeni bir TIF_NEED_RESCHED_LAZY bayrağı ekliyor.
  • Tembel preemption modunda (PREEMPT_LAZY), çoğu olay bu yeni bayrağı ayarlar; çekirdekten kullanıcı alanına dönülürken iki bayraktan biri ayarlıysa zamanlayıcı çağrılır.
  • Bu değişikliğin sonucu olarak, tembel preemption modunda çekirdekteki çoğu olay mevcut görevi preempt etmez.

cond_resched() kaldırılması

  • Bu çalışmanın nihai hedefi, yalnızca iki gerçek zamanlı olmayan mod bırakmaktır: PREEMPT_LAZY ve PREEMPT_FULL.
  • Tembel mod, PREEMPT_NONE ile PREEMPT_VOLUNTARY arasındaki konumu alır ve bu iki modun yerini alır.
  • Şu anda cond_resched() çağrıları hâlâ mevcut ve PREEMPT_NONE ile PREEMPT_VOLUNTARY modları var oldukça gerekli olmaya devam ediyor.

GN⁺ Özeti

  • Tembel preemption, çekirdeğin zamanlamasını basitleştirmeye ve öngörülebilir gecikme süreleri sağlamaya katkıda bulunabilir.
  • Bu çalışma, çekirdeğin boyutunu küçültmeye ve kodu sadeleştirmeye yardımcı olabilir.
  • Tembel preemption, PREEMPT_VOLUNTARY’ye benzer throughput sağlar; ancak daha fazla test ve optimizasyon gerektirir.
  • Benzer işlev sunan diğer projeler arasında FreeBSD’nin ULE zamanlayıcısı da bulunuyor.

1 yorum

 
GN⁺ 2024-10-20
Hacker News yorumu
  • Tembel preemption çalışmasının nihai sonucu, çekirdeğin daha küçük ve daha basit hale gelirken öngörülebilir gecikme süreleri sunmasıdır. Bu, kod tabanının her yerine scheduler ile ilgili çağrılar serpiştirmeye gerek kalmadan daha iyi bir çözüm gibi görünüyor. Ancak bunun gerçekleşmesi zaman alacaktır.

    • EEVDF gibi, mevcut durumu basitleştirip iyileştiriyor. Bundan daha iyi bir çözüm olmayabilir.
  • Yüksek düzeyde preemption, sistemin olaylara daha hızlı tepki vermesini sağlar. Fare hareketi ya da bir reaktörün "yaklaşan çöküş" sinyali gibi olaylara hızlı tepki vermek daha tatmin edicidir. Ancak yüksek düzeyde preemption, sistemin toplam throughput'unu etkileyebilir. CPU yoğun işlerin fazla olduğu iş yüklerinde mümkün olduğunca az kesintiye uğramak avantajlıdır. Daha sık preemption, daha yüksek lock contention'a yol açabilir. Bu yüzden farklı modlar vardır ve en uygun preemption modu iş yüküne göre değişecektir.

    • Preemption düzeyinin neden belirli bir olayın özelliği değil de küresel bir modun özelliği olduğunu merak ediyorum. Bazı olayların diğerlerine göre daha düşük gecikmeyle işlenmesi gerekir.
  • Mevcut çekirdek, bir görevin başka bir görev lehine ne zaman preempt edilebileceğini kontrol eden dört moda sahip.

    • Bunun çekirdek görevleriyle mi, kullanıcı görevleriyle mi, yoksa her ikisiyle mi ilgili olduğunu merak ediyorum.
  • Bağlantısı verilen başlıkta patch ile ilgili sayıları bulamıyorum. Değişikliğin gerçek potansiyelini gösterebilecek ön kıyaslamalar yapılmış olmalı.

  • Scheduler'ın çekirdeğin geri kalan koduyla ne kadar sıkı bağlandığını merak ediyorum.

    • Örneğin, preemption'ı hiç umursamayan bilimsel uygulamalar için scheduler'ı ciddi ölçüde basitleştirmek istesek, bunun temiz ve modüler biçimde yapılıp yapılamayacağını ve ne gibi faydalar sağlayacağını merak ediyorum.
  • Preemption'ın olaylara göre uyarlanabilmesi iyi olurdu, ancak bunu tüm olaylar için yönetmek sistem kararlılığına zarar verebilir. Bu, Tomba Finder gibi araçlarla lead üretmeye benziyor.

    • Hassasiyet (hedef lead'ler) ile verimliliği dengede tutarak genel olarak sorunsuz çalışması gerekir.