लिनक्स संदर्भ-स्विच आवृत्ति कैसे बदलें?

Question

लिनक्स (लिनारो, ubuntu, debian) संदर्भ-स्विच आवृत्ति को बदलना कैसे संभव है?

मैं एक अधिक कुशल के लिए कम-उत्तरदायी प्रणाली का व्यापार करने के लिए ठीक हूं।

EDIT1: मेरे पास एक मुख्य प्रक्रिया है जिसे मैं यथासंभव तेज (अधिकतम घड़ी चक्र प्रति सेकंड) चलाना चाहता हूं, इसलिए मैंने संदर्भ-स्विच आवृत्ति (= टाइमलाइन को बढ़ाना) को कम करने के बारे में सोचा। सवाल यह है कि यह कैसे करना है, और क्या कोई महत्वपूर्ण प्रभाव होगा। क्या मैं संदर्भ स्विच की लागत की गणना कर सकता हूं? मतलब, क्या मैं अनुमान लगा सकता हूं कि यदि मैं दो बार टाइमलाइन को बढ़ाता हूं, तो मेरे द्वारा की जाने वाली मुख्य प्रक्रिया के लिए मेरा प्रदर्शन% में क्या होगा?

Comments

मुझे उम्मीद है कि इस सेटिंग का प्रभाव कम से कम, और प्रासंगिक तभी होगा जब आपके पास सीपीयू कोर की तुलना में अधिक प्रक्रियाएं हों। यदि कोई अन्य कार्य किसी विशेष CPU की प्रतीक्षा नहीं कर रहे हैं, तो कम समय के टास्क स्विच टाइमर को भी सेट करने की कोई आवश्यकता नहीं है, क्योंकि कोई भी चीज़ जो किसी अन्य कार्य को चलाने योग्य बना सकती है, वह सिस्टम कॉल या हार्डवेयर व्यवधान होगा, दोनों CPU को कर्नेल पर लौटाएगा।

— साइमन रिक्टर

क्षमा करें कि यहाँ क्या हुआ, लेकिन क्या कोई समझा सकता है कि इस संदर्भ के संदर्भ में 'संदर्भ-स्विच आवृत्ति' का क्या अर्थ है?

— user1717828

@sourcejedi मेरे EDIT1 देखें - क्या मैं संदर्भ स्विच आवृत्ति को कम करने पर% में थ्रूपुट सुधार का अनुमान लगा सकता हूं?

— नादव बी

@ एनएडीबीबी मैंने अपने उत्तर को उसी के अनुसार संपादित किया है। अनुकूलन करते समय विशिष्ट माप सबसे अच्छे होते हैं। हालांकि, आपको ब्लैक बॉक्स के रूप में इसका इलाज करने की आवश्यकता नहीं है, उदाहरण के लिए, यदि आप अपना सीपीयू अच्छा है, तो कैश मिस को मापने के लिए आप परफेक्ट का उपयोग कर सकते हैं। AIUI, विभिन्न प्रकार के CPU कैश मिस (TLB मिस सहित) संदर्भ स्विचिंग की सबसे महत्वपूर्ण व्यक्तिगत लागत हैं।

— sourcejedi

Answer 1

यदि आपका कार्य विशिष्ट CPU पर समय का अनुरोध करने वाली एकमात्र प्रक्रिया है, तो कार्यों के बीच कोई संदर्भ स्विच नहीं होगा :-)। लेकिन सीपीयू अभी भी बाधित हो सकता है, जिससे एक संदर्भ कर्नेल और बैक में बदल सकता है। और एक संभावित कारण प्री-एमिशन टाइमर है, यह जांचने के लिए कि क्या इस सीपीयू पर चलने के लिए कोई अन्य कार्य है ...

लिनक्स सीपीयू पर किसी भी पूर्व-उत्सर्जन टाइमर इंटरप्ट को उत्पन्न करने से बच सकता है जब ऐसा करने का कोई कारण नहीं होगा। देखते हैं CONFIG_NO_HZ_FULL। इस सुविधा का उपयोग करने के लिए, इसे कर्नेल के निर्माण के समय सक्षम किया जाना चाहिए, और बूट विकल्प का उपयोग करके इसे सक्षम किया जाना चाहिए।

• https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt
• https://lwn.net/Articles/549580/ "(लगभग) 3.10 में पूर्ण टिक्लेस ऑपरेशन"

डिफ़ॉल्ट रूप से, कोई सीपीयू एक अनुकूली-टिक सीपीयू नहीं होगा। "Nohz_full =" बूट पैरामीटर अनुकूली-टिक CPUs को निर्दिष्ट करता है। उदाहरण के लिए, "nohz_full = 1,6-8" का कहना है कि सीपीयू 1, 6, 7, और 8 अनुकूली-टिक सीपीयू होने चाहिए। ध्यान दें कि आप सभी सीपीयू को अनुकूली-टिक सीपीयू के रूप में चिह्नित करने से प्रतिबंधित हैं [...]

LWN.net का कहना है "Ingo Molnar के अनुसार, CPU के समय का 1% बचाया जाएगा" अनुकूली-टिक CPUs के लिए। कर्नेल दस्तावेज़ कहता है कि इसकी छह अलग-अलग लागतें हैं, और "KNOWN ISSUES" की एक सूची भी है।

यह लाभ अपेक्षाकृत छोटा है, विशेष रूप से कई कार्यों के बीच संदर्भ-स्विच की आवृत्ति को कम करने के संभावित थ्रूपुट लाभ की तुलना में, जैसा कि इस उत्तर में संदर्भित है: लिनक्स सीपीयू अनुसूचक द्वारा उपयोग किए जाने वाले समय-स्लाइस की लंबाई कैसे बदलें?

छोटा प्रिंट: ये माप पूर्व-तारीख स्पेक्टर, मेल्टडाउन, KPTI और x86 ASID समर्थन :-( और मुझे लगता है कि वे कुछ पुराने हार्डवेयर पर भी लागू होते हैं। एक कर्नेल विशेषज्ञ से पूछें या संदर्भ-स्विच की लागत कैसे होती है, इस पर अपने स्वयं के माप चलाएं। आपके विशिष्ट कर्नेल संस्करण और हार्डवेयर में परिवर्तन ... पीटीआई को बहुत हद तक एएसआईडी द्वारा शमन किया जाना चाहिए, सॉफ्टवेयर के अलावा जो कर्नेल में बहुत बार कॉल करता है, मुख्य उदाहरण डेटाबेस। लेकिन मुझे संख्याओं पर अच्छा पकड़ नहीं है। ।

मूल आरएफसी पैच में मोलनार की उम्मीद यह थी कि समय के साथ, यह "अधिकांश लिनक्स डिस्ट्रोस द्वारा सक्षम किया जाएगा"। मैंने देखा कि फेडोरा 28 NO_HZ_FULLसमर्थन के साथ बनाया गया एक डिफ़ॉल्ट कर्नेल प्रदान करता है । डेबियन 9, हालांकि नहीं है।

---

हाल ही में, लिनक्स v4.17 सीपीयू से एक अवशिष्ट 1 हर्ट्ज टाइमर टिक हटाता हैnohz_full । मुझे लगता है कि थ्रूपुट पर प्रभाव काफी छोटा है :-), लेकिन मैं NO_HZ_FULLलाभ की स्थिति का पालन करने की कोशिश कर रहा हूं जब एक सीपीयू पर कई रन करने योग्य प्रक्रियाएं होती हैं -

एक बार जब हम 0 हर्ट्ज तक पहुंच जाते हैं, तो हम [तो] nr_running> = 2 से आवधिक टिक धारणा को हटा सकते हैं, साथ ही साथ व्यस्त कार्यों को अनिवार्य रूप से केवल बार-बार रोकते हैं, क्योंकि शेड्यूल_लैटेंसी की कमी के कारण हमें ऐसा करने की आवश्यकता होती है - एक बार 4-40 msecs, nr_running पर निर्भर करता है। ।

यह थोड़ा सा भ्रामक है क्योंकि पहले से ही v2.6.25-rc1 में एक अलग, अधिक सटीक टिक बैक का उपयोग करते हुए पूर्व-उत्सर्जन शुरू हो गया था, 8f4d37ec073c, "शेड्यूल: हाई-रिस प्रीमेशन टिक" । इसी LWN.net लेख पर इस टिप्पणी के माध्यम से मिला: https://lwn.net/Articles/549754/ )।

Comments

kernel.sched_rr_timeslice_ms के बारे में क्या?

— नादव बी

@ एनएडीबीबी यदि आप रीयलटाइम शेड्यूल_आरआर कार्यों का उपयोग कर रहे हैं, तो कहें। यह एक विशेषज्ञ विषय है। यदि आप नहीं हैं, तो कोई :-)।

— sourcejedi