Linux CPU scheduler में "lazy preemption" को लागू करने की लंबी यात्रा

 (lwn.net)
3 पॉइंट द्वारा GN⁺ 2024-10-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • kernel का CPU scheduler सिस्टम throughput और response time के बीच संतुलन लागू करने के लिए कई preemption modes प्रदान करता है.
  • सितंबर 2023 में scheduling पर चर्चा के दौरान "lazy preemption" की अवधारणा प्रस्तावित की गई थी, जो kernel scheduling को सरल बनाते हुए बेहतर परिणाम दे सकती है.
  • यह अवधारणा कुछ समय तक शांत रही, लेकिन Peter Zijlstra की patch series के साथ फिर सामने आई.

मौजूदा kernel के preemption modes

  • PREEMPT_NONE: preemption केवल तब अनुमति है जब चल रहा task अपना time slice समाप्त कर दे.
  • PREEMPT_VOLUNTARY: जरूरत पड़ने पर kernel के भीतर कई ऐसे बिंदु जोड़ता है जहां preemption संभव हो.
  • PREEMPT_FULL: spinlock लगे होने की स्थिति को छोड़कर लगभग हर बिंदु पर preemption संभव है.
  • PREEMPT_RT: अधिकांश अन्य बातों की तुलना में preemption को प्राथमिकता देता है, और अधिकांश spinlock code को भी preemptible बनाता है.

lazy preemption का परिचय

  • lazy-preemption patch एक नया flag TIF_NEED_RESCHED_LAZY जोड़ता है, जो यह दर्शाता है कि तुरंत नहीं बल्कि किसी समय rescheduling की आवश्यकता है.
  • lazy preemption mode (PREEMPT_LAZY) में अधिकांश events यही नया flag सेट करते हैं, और जब kernel से user space में वापसी होती है तो यदि दोनों में से कोई एक flag सेट हो, scheduler call किया जाता है.
  • इस बदलाव के परिणामस्वरूप lazy preemption mode में kernel की अधिकांश events मौजूदा task को preempt नहीं करतीं.

cond_resched() को हटाना

  • इस काम का अंतिम लक्ष्य केवल दो non-real-time modes, PREEMPT_LAZY और PREEMPT_FULL, को बचाए रखना है.
  • lazy mode, PREEMPT_NONE और PREEMPT_VOLUNTARY के बीच की स्थिति लेता है और इन दोनों modes को प्रतिस्थापित करता है.
  • फिलहाल cond_resched() calls अभी भी मौजूद हैं, और जब तक PREEMPT_NONE तथा PREEMPT_VOLUNTARY modes मौजूद हैं, उनकी जरूरत रहेगी.

GN⁺ का सार

  • lazy preemption kernel scheduling को सरल बनाने और अधिक predictable latency देने में योगदान कर सकता है.
  • यह काम kernel का आकार घटाने और code को सरल बनाने में मदद कर सकता है.
  • lazy preemption, PREEMPT_VOLUNTARY जैसा throughput देता है, लेकिन इसके लिए और अधिक testing तथा optimization की आवश्यकता है.
  • समान कार्यक्षमता वाले अन्य projects में FreeBSD का ULE scheduler शामिल है.

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-10-20
Hacker News टिप्पणी

  • lazy preemption पर काम का अंतिम नतीजा यह है कि kernel छोटा और सरल हो जाता है, साथ ही अनुमानित latency देता है। यह पूरे codebase में scheduler-संबंधित calls बिखेरने की ज़रूरत के बिना एक बेहतर समाधान लगता है। हालांकि, इसे हासिल करने में समय लगेगा.

    • EEVDF की तरह, यह मौजूदा स्थिति को सरल और बेहतर बनाता है। इससे बेहतर समाधान शायद नहीं होगा.

  • preemption का उच्च स्तर system को events पर अधिक तेज़ी से प्रतिक्रिया देने देता है। mouse movement या reactor के "आसन्न meltdown" signal जैसे events पर तेज़ प्रतिक्रिया ज़्यादा संतोषजनक होती है। लेकिन preemption का उच्च स्तर system के कुल throughput को प्रभावित कर सकता है। CPU-intensive tasks वाले workloads के लिए जितना संभव हो उतना कम बाधित होना फायदेमंद है। अधिक बार होने वाला preemption ज़्यादा lock contention पैदा कर सकता है। इसलिए अलग-अलग modes मौजूद हैं, और सबसे उपयुक्त preemption mode workload पर निर्भर करेगा.

    • यह सोचने वाली बात है कि preemption level किसी खास event की property होने के बजाय global mode की property क्यों है। कुछ events को दूसरों की तुलना में कम latency के साथ संभाला जाना चाहिए.

  • मौजूदा kernel में चार modes हैं जो यह नियंत्रित करते हैं कि एक task को दूसरे task के लिए कब preempt किया जा सकता है.

    • यह जानना दिलचस्प होगा कि क्या यह kernel tasks, user tasks, या दोनों पर लागू होता है.

  • linked thread में patch से जुड़े कोई numbers नहीं मिल रहे। बदलाव की असली क्षमता बताने वाला कुछ शुरुआती benchmarking किया गया होगा.

  • यह जानने की उत्सुकता है कि scheduler बाकी kernel code के साथ कितनी क़रीबी से जुड़ा हुआ है.

    • उदाहरण के लिए, अगर उन scientific applications के लिए scheduler को काफ़ी सरल बनाना हो जिन्हें preemption की बिल्कुल परवाह नहीं है, तो क्या यह साफ़-सुथरे और modular तरीके से किया जा सकता है, और इससे क्या फायदे होंगे.

  • अच्छा होगा अगर preemption events के हिसाब से अनुकूलित हो सके, लेकिन हर event के लिए इसे manage करना system stability को नुकसान पहुँचा सकता है। यह कुछ-कुछ Tomba Finder जैसे tools से lead generation करने जैसा है.

    • precision (target leads) और efficiency के बीच संतुलन रखना होगा ताकि पूरी व्यवस्था सुचारु रूप से चल सके.