मैं ऑपरेटिंग सिस्टम में एक परिचयात्मक पाठ्यक्रम का अध्ययन कर रहा हूं और मैं एक शेड्यूलर विकसित करने की कोशिश कर रहा था जो एक प्रक्रिया के टर्न-अराउंड समय और प्रतिक्रिया समय के बीच एक अच्छा व्यापार दे सके।

मैं सोच रहा हूं कि मैं टाइमर-इंटरप्ट के अंतराल को बदल सकता हूं या नहीं। अगर मैं ऐसा कर सकता था, तो शायद मैं अलग-अलग टाइमर अंतराल के बीच स्विच कर सकता था, जो कि किसी दिए गए बड़े अंतराल में पूरी की गई प्रक्रियाओं की संख्या के संबंध में था। उदाहरण के लिए, यदि मैंने पिछले 10 एमएस में 7 प्रक्रियाएं पूरी की हैं, तो टाइमर अंतराल को 10 एमएस से 15 एमएस पर स्विच करें और इसलिए, एक उत्तरदायी शेड्यूलर के बीच एक शेड्यूलर में स्विच करना जो टर्न-अराउंड समय को कम करता है और इसलिए दोनों के लिए बेहतर औसत प्राप्त करता है।

धन्यवाद।

-1
Arslan Murad 4 फरवरी 2019, 17:32

1 उत्तर

सबसे बढ़िया उत्तर

आइए इसे कई टुकड़ों में विभाजित करें ..

टाइमर

बहुत सारे आधुनिक गुठली "गुदगुदी" हैं। इसका क्या मतलब है (एक निश्चित आवृत्ति पर एक आईआरक्यू उत्पन्न करने वाला टाइमर होने के बजाय) टाइमर "एक शॉट" मोड में काम करता है (अनुरोधित समय समाप्त होने पर उत्पन्न एक आईआरक्यू) और कर्नेल निर्धारित करता है कि अगली बार घटना कब होनी चाहिए होता है और अगली बार घटना होने पर IRQ उत्पन्न करने का समय निर्धारित करता है। इस दृष्टिकोण में बिजली प्रबंधन के लिए लाभ हैं (कोई अनावश्यक आईआरक्यू नहीं है अन्यथा निष्क्रिय सीपीयू/बिजली बचत राज्यों से बाहर है) और परिशुद्धता के लिए लाभ (उदाहरण के लिए यदि टाइमर 1 मेगाहर्ट्ज घड़ी से बाहर निकलता है, तो कर्नेल आईआरक्यू के लिए टाइमर पूछ सकता है 1 मिलियन IRQ के ओवरहेड के बिना 1 माइक्रोसेकंड ग्रैन्युलैरिटी के साथ यह एक निश्चित आवृत्ति के साथ समान ग्रैन्युलैरिटी प्राप्त करने के लिए ले जाएगा)। बेशक टाइमर (नेटवर्किंग टाइम-आउट, स्लीप (), आदि) के लिए कई उपयोग हैं, इसलिए "जल्द से जल्द समय की घटना" का इससे कोई लेना-देना नहीं है जब वर्तमान कार्य ने अपना समय टुकड़ा खा लिया है।

नोट: आधुनिक हार्डवेयर में सीपीयू की आवृत्ति पर चलने वाले टाइमर भी हो सकते हैं (उदाहरण के लिए हाल के 80x86 चिप्स के स्थानीय एपीआईसी टाइमर में "टीएससी डेडलाइन मोड") जहां "टिकलेस" का मतलब है कि आप आमतौर पर "1 नैनोसेकंड से बेहतर" प्राप्त कर सकते हैं। सटीक।

बेशक "टिकलेस" के लिए, क्योंकि कर्नेल टाइमर के लिए एक नई गिनती सेट करता है (नए "जल्द ही" समय की घटना के लिए) हर बार आईआरक्यू होता है, शेड्यूलर के लिए किसी भी समय स्लाइस लंबाई का उपयोग करना बेहद आसान होता है, जो भी कारण से इसे पसंद करता है को यह पसंद है।

कार्य स्विच के कारण

एक वास्तविक ओएस के लिए, अधिकांश कार्य स्विच इसलिए होते हैं क्योंकि वर्तमान में चल रहे कार्य को कुछ इंतजार करना पड़ता है (फ़ाइल या स्वैप स्थान से डेटा की प्रतीक्षा करें, नेटवर्क से एक पैकेट की प्रतीक्षा करें, बफर के "पूर्ण नहीं" बनने की प्रतीक्षा करें, इसलिए यह इसमें अधिक डेटा डाल सकते हैं, किसी अन्य प्रक्रिया से डेटा के आने की प्रतीक्षा कर सकते हैं। एक पाइप या संदेश, एक म्यूटेक्स जारी होने की प्रतीक्षा करें, आदि); या क्योंकि कुछ ऐसा हुआ जिसके लिए कोई कार्य प्रतीक्षा कर रहा था। शेड्यूलर का टाइमर केवल दुर्भावनापूर्ण CPU हॉग और दुर्लभ CPU बाध्य कार्यों के लिए ऊपरी सीमा प्रदान करने के लिए है, जिन्हें किसी भी चीज़ की प्रतीक्षा करने की आवश्यकता नहीं है।

ध्यान दें कि (निश्चित आवृत्ति टाइमर का उपयोग करके राउंड रॉबिन शेड्यूलर जैसी किसी चीज़ के लिए) यह समस्याओं का कारण बनता है। उदाहरण के लिए, यदि प्रत्येक कार्य को 10 ms समय टुकड़ा दिया जाता है, लेकिन 4.321 ms के बाद एक कार्य स्विच होना है क्योंकि कार्य को किसी चीज़ की प्रतीक्षा करनी है, तो आप 5.679 ms CPU समय को अगले की प्रतीक्षा में बर्बाद नहीं करना चाहते हैं। टाइमर आईआरक्यू, लेकिन आप अगले कार्य को 5.679 एमएस के बजाय 10 एमएस के बजाय देना नहीं चाहते हैं। इसके बजाय, आप प्रत्येक 1 एमएस में आईआरक्यू उत्पन्न करने के लिए टाइमर को कॉन्फ़िगर कर सकते हैं ताकि अगला कार्य दिया जाने वाला समय निकटतम तक गोल किया जा सके (उदाहरण के लिए 5.679 एमएस के बजाय 5.679 एमएस और 10 एमएस के बजाय अगला कार्य दें)। हालांकि, यह अनावश्यक IRQs को संभालने के ओवरहेड को बढ़ाता है और प्रदर्शन को नुकसान पहुंचाता है, और "टिकलेस" (अनावश्यक IRQ से छुटकारा पाने के लिए और "गोल से निकटतम" त्रुटि को कम करने के लिए) का उपयोग करने के कारणों में से एक है।

राउंड रॉबिन में विलंबता

राउंड रॉबिन शेड्यूलर के लिए "लोड के तहत विलंबता" एक अपंग मजाक है, और इसका टाइमर से कोई लेना-देना नहीं है। समस्या यह है कि जिस कार्य को कम विलंबता की आवश्यकता होती है, उसे अपनी बारी आने के लिए अज्ञात संख्या में अन्य कार्यों की प्रतीक्षा करनी पड़ती है। उदाहरण के लिए, यदि 200 कार्य हैं जो प्रत्येक में 10 ms तक CPU समय प्राप्त करने वाले हैं, और उन 200 कार्यों में से प्रत्येक वास्तव में औसतन 5 ms CPU समय का उपभोग करता है (क्योंकि अधिकांश ब्लॉक/अपने समय के टुकड़े से पहले किसी चीज़ की प्रतीक्षा करते हैं) समाप्त होता है); तो एक "कम विलंबता" कार्य को CPU समय मिलने से पहले 1000 ms तक प्रतीक्षा करनी पड़ सकती है। टाइमर के अंतराल को 10 एमएस से 5 एमएस में बदलने का मतलब यह हो सकता है कि उन 200 कार्यों में से प्रत्येक में औसतन 4 एमएस सीपीयू समय लगता है और "कम विलंबता" कार्य को अभी भी 800 एमएस तक इंतजार करना पड़ता है।

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

कार्य प्राथमिकताएं

क्या होगा यदि आपने प्रत्येक कार्य को प्राथमिकता दी है, ताकि अनुसूचक को पता चले कि कार्य कितना महत्वपूर्ण है?

इस मामले में, यदि किसी कार्य को कम विलंबता की आवश्यकता है, तो आप शेड्यूलर को बता सकते हैं कि इसकी उच्च प्राथमिकता है, और जब कार्य किसी चीज़ की प्रतीक्षा करना बंद कर देता है (उदाहरण के लिए उपयोगकर्ता द्वारा एक कुंजी दबाए जाने की प्रतीक्षा करना, नेटवर्क पैकेट आने की प्रतीक्षा करना, आदि) शेड्यूलर कार्य की प्राथमिकता की तुलना वर्तमान में चल रहे कार्य की प्राथमिकता से कर सकते हैं, यह महसूस कर सकते हैं कि "कम विलंबता" कार्य की उच्च प्राथमिकता है, और तुरंत कार्य स्विच करें (200 अन्य कार्यों के लिए अपनी बारी की प्रतीक्षा किए बिना)। इस मामले में, विलंबता "लगभग शून्य" हो सकती है, तब भी जब ओएस भारी भार में हो।

यह एक संभावित समस्या (उच्च प्राथमिकता सीपीयू हॉग) बनाता है, लेकिन वह समस्या अन्य तरीकों से ठीक करने के लिए तुच्छ है (उदाहरण के लिए यदि उच्च प्राथमिकता वाले कार्य में बिना कुछ किए बहुत अधिक CPU समय लगता है जो इसे अवरुद्ध/प्रतीक्षा करने का कारण बन सकता है, या तो इसे कम करें प्राथमिकता दें या इसे "अनुत्तरदायी" के रूप में समाप्त करें)।

यदि आप आधुनिक ऑपरेटिंग सिस्टम में अनुसूचकों को देखें तो आप पाएंगे कि उनमें से कोई भी अपने आप में राउंड रॉबिन का उपयोग नहीं करता है। अक्सर "राउंड रॉबिन" का उपयोग केवल तब किया जाता है जब 2 या अधिक कार्यों की प्राथमिकता समान होती है (लेकिन यह वास्तव में एक अच्छा विचार नहीं है और मैं आपको बताऊंगा कि अगले भाग में क्यों)। साथ ही, अधिकांश ऑपरेटिंग सिस्टम कई शेड्यूलिंग नीतियां प्रदान करते हैं (उदाहरण के लिए शायद एक ओएस एक सॉफ्ट रीयल-टाइम शेड्यूलिंग नीति प्रदान कर सकता है जो "सबसे पहले समय सीमा पहले" का उपयोग करता है, साथ ही एक "कम विलंबता" शेड्यूलिंग नीति जो "उच्चतम प्राथमिकता जीत" का उपयोग करती है, साथ ही एक " सामान्य उपयोग" नीति जो उपयोग कर सकती है "प्राथमिकता निर्धारित करती है कि कितने समय स्लाइस", साथ ही एक "निष्क्रिय कार्य" नीति जो "प्राथमिकता समय स्लाइस का आकार निर्धारित करती है" का उपयोग कर सकती है); जहां अनुसूचक सर्वोत्तम नीति वाले कार्यों के लिए CPU समय देता है (उदाहरण के लिए यदि कोई वास्तविक समय कार्य है जो CPU चाहता है, तो निष्क्रिय कार्यों पर भी विचार नहीं किया जाएगा) और प्रत्येक नीति के लिए अलग-अलग नियम हैं।

औसत कार्य समाप्ति समय

आइए मान लें कि केवल एक सीपीयू है; कि एक कार्य एक नेटवर्क पैकेट को संसाधित करना चाहता है और एक प्रतिक्रिया भेजना चाहता है और इस प्रसंस्करण में 50 ms CPU समय लगेगा; और साथ ही एक अन्य प्रक्रिया उपयोगकर्ता से एक कुंजी प्रेस को संभालना चाहती है और इसमें शामिल प्रसंस्करण में भी 50 एमएस लगेगा। यदि शेड्यूलर प्रत्येक 1 एमएस में कार्यों के बीच स्विच करता है तो पहला कार्य 99 एमएस के बाद समाप्त हो जाएगा और दूसरा कार्य 100 एमएस के बाद समाप्त हो जाएगा, और किसी कार्य को पूरा करने में लगने वाला औसत समय 99.5 एमएस होगा। हालांकि, यदि शेड्यूलर किसी भी समय के बाद कार्यों के बीच स्विच नहीं करता है (उदाहरण के लिए वर्तमान में चल रहे कार्य को तब तक चलने देता है जब तक कि वह अपना काम पूरा नहीं कर लेता है और अगले काम के लिए प्रतीक्षा करता है) तो पहला कार्य 50 एमएस के बाद समाप्त हो जाएगा और दूसरा कार्य 100 ms के बाद समाप्त होगा, और किसी कार्य को पूरा करने में लगने वाला औसत समय 75 ms (99.5 ms के बजाय) होगा।

दूसरे शब्दों में, घटना संचालित कार्यों के लिए (उदाहरण के लिए जहां कुछ होता है और कार्य इसे संभालने के दौरान चलता है, फिर अगली घटना की प्रतीक्षा करता है), एक राउंड रॉबिन शेड्यूलर (निश्चित आवृत्ति पर कार्यों को स्विच करना) औसत पूरा होने का समय लगभग 50% खराब कर सकता है अधिकांश अन्य शेड्यूलिंग एल्गोरिदम की तुलना में (उदाहरण के लिए "जल्द से जल्द प्रारंभ समय पहले", "उच्चतम प्राथमिकता जीत", ...)।

निष्कर्ष

ए) हां, समय स्लाइस की लंबाई को समायोजित करना पूरी तरह से संभव है, या तो एक टिकलेस डिज़ाइन का उपयोग करके, या एक निश्चित आवृत्ति टाइमर डिज़ाइन के "आईआरक्यू प्रति टाइम स्लाइस" के लिए अलग-अलग मानों का उपयोग करके।

बी) राउंड रॉबिन शेड्यूलर के लिए, समय स्लाइस की लंबाई को समायोजित करने से विलंबता (विशेष रूप से लोड के तहत) में बहुत मदद नहीं मिलेगी।

ग) परिचयात्मक पाठ्यक्रम एक परिचय हैं - उनका उद्देश्य ऐसी जानकारी प्रदान करना है जो (भविष्य में किसी बिंदु पर) आपको अधिक उन्नत अवधारणाओं को सीखने में मदद करेगी (और ऐसी जानकारी प्रदान करने का इरादा नहीं है जो व्यवहार में "जैसा है" का उपयोग किया जाता है)। राउंड रॉबिन शेड्यूलिंग उन चीजों में से एक है जिसे अक्सर एक परिचय में रखा जाता है, आंशिक रूप से क्योंकि वे सरल होते हैं, लेकिन आंशिक रूप से क्योंकि वे स्वाभाविक रूप से चर्चा करते हैं कि वे क्यों चूसते हैं और समस्याओं से कैसे बचें (जो कि अधिकांश की शुरुआत है उन्नत अवधारणाएं)।

0
Brendan 4 फरवरी 2019, 22:46