सिंगल विंडोज कर्नेल

विंडोज सबसे बहुमुखी और लचीले ओएस में से एक है, यह पूरी तरह से अलग आर्किटेक्चर पर काम करता है और विभिन्न संस्करणों में उपलब्ध है। आज यह x86, x64, ARM और ARM64 आर्किटेक्चर को सपोर्ट करता है। एक समय में विंडोज ने इटेनियम, पावरपीसी, डीईसी अल्फा और एमआइपीएस का समर्थन किया। इसके अलावा, विंडोज विभिन्न स्थितियों में संचालित SKUs की एक विस्तृत श्रृंखला का समर्थन करता है; डेटा सेंटर, लैपटॉप, एक्सबॉक्स और फोन से लेकर चीजों के इंटरनेट के एम्बेडेड संस्करणों तक, उदाहरण के लिए, एटीएम में।

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

इस लेख में, मैं विंडोज कर्नेल के प्रमुख भागों के विकास के बारे में बात करूंगा जो इसे सतह आरटी 2012 पर चलने वाले कम-शक्ति एनवीडिया तेग्रा चिप से Azure डेटा केंद्रों में काम करने वाले विशालकाय राक्षसों के लिए पारदर्शी रूप से स्केल करने में सक्षम बनाते हैं।


एक Windows कार्य प्रबंधक Windows DataCenter prerelease मशीन पर चल रहा है, जिसमें 896 कोर 1792 तार्किक प्रोसेसर और 2 टीबी मेमोरी का समर्थन करते हैं।

एकल कोर विकास

विंडोज कर्नेल के विवरण पर चर्चा करने से पहले, आइए थोड़ा सा रिफैक्टरिंग की ओर जाएं। विभिन्न एसकेयू और प्लेटफार्मों (उदाहरण के लिए, क्लाइंट, सर्वर और फोन) पर ओएस घटकों के पुन: उपयोग को बढ़ाने में रिफैक्टरिंग एक महत्वपूर्ण भूमिका निभाता है। Refactoring का मूल विचार आपको अलग-अलग SKU पर समान DLL का पुन: उपयोग करने की अनुमति देना है, विशेष रूप से वांछित SKU के लिए किए गए छोटे संशोधनों का समर्थन करते हुए, DLL का नाम लिए बिना और अनुप्रयोगों के काम को तोड़े बिना।

विंडोज रीफैक्टरिंग की मुख्य तकनीक एक छोटी-सी दस्तावेज तकनीक है जिसे एपीआई सेट कहा जाता है । एपीआई सूट एक तंत्र है जो ओएस को डीएलएल और इसके उपयोग की जगह को अलग करने की अनुमति देता है। उदाहरण के लिए, एपीआई सेट win32 के लिए कर्नेल 32.dll का उपयोग जारी रखने की अनुमति देता है, इस तथ्य के बावजूद कि सभी एपीआई का कार्यान्वयन दूसरे DLL में लिखा गया है। ये कार्यान्वयन DLL SKU के बीच भिन्न हो सकते हैं। आप पारंपरिक Windows DLL पर निर्भरता ट्रैवर्सल चलाकर API सेट को एक्शन में देख सकते हैं, उदाहरण के लिए, कर्नेल 32.ll।


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

कर्नेल घटक

विंडोज एनटी, वास्तव में, एक माइक्रोकर्नल है , इस अर्थ में कि सभी उच्च-स्तरीय नीतियों को निष्पादित करने के लिए निष्पादन योग्य परत (कार्यकारी परत, पूर्व) का उपयोग करके सीमित कार्यों के साथ इसकी अपनी कोर कर्नेल (KE) है। EX अभी भी कर्नेल मोड है, इसलिए यह वास्तव में एक माइक्रोकर्नेल नहीं है। कर्नेल थ्रेड शेड्यूल करने, प्रोसेसर के बीच सिंक्रोनाइज़ करने, हार्डवेयर-स्तर के अपवादों को संभालने और निम्न-स्तरीय हार्डवेयर-निर्भर कार्यों को लागू करने के लिए जिम्मेदार है। EX लेयर में विभिन्न सबसिस्टम होते हैं जो कार्यक्षमता का एक सेट प्रदान करते हैं जिसे आमतौर पर कोर माना जाता है - IO, ऑब्जेक्ट मैनेजर, मेमोरी मैनेजर, प्रोसेस सबसिस्टम, आदि।


घटकों के आकार को बेहतर ढंग से समझने के लिए, कर्नेल स्रोत ट्री (टिप्पणियों सहित) की कई प्रमुख निर्देशिकाओं में कोड की लाइनों की संख्या का लगभग एक टूटना है। तालिका में अभी तक कर्नेल से संबंधित बहुत कुछ शामिल नहीं है।

कर्नेल सबसिस्टम	कोड की लाइनें
मेमोरी मैनेजर	501, 000
रजिस्ट्री	211,000
शक्ति	238,000
कार्यकारी	157,000
सुरक्षा	135,000
गुठली	339,000
प्रक्रिया उप-प्रणाली	116,000

विंडोज आर्किटेक्चर के बारे में अधिक जानकारी के लिए, विंडोज इंटर्नल बुक सीरीज देखें।

योजनाकार

इस तरह से जमीन तैयार करने के बाद, चलो शेड्यूलर, इसके विकास और विंडोज कर्नेल के बारे में थोड़ी बात कर सकते हैं कि इतने सारे प्रोसेसर के साथ इस तरह के कई अलग-अलग आर्किटेक्चर हो सकते हैं।

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

काम करने के बाद क्वांटम समय (न्यूनतम समय जो एक थ्रेड काम कर सकता है), थ्रेड गतिशील प्राथमिकता में कमी का अनुभव करता है ताकि उच्च प्राथमिकता वाले धागे हमेशा के लिए काम न कर सकें, बाकी सभी की आत्मा। जब एक और धागा काम करने के लिए उठता है, तो उसे प्राथमिकता दी जाती है, उस घटना के महत्व के आधार पर गणना की जाती है जो प्रतीक्षा का कारण बनती है (उदाहरण के लिए, फ्रंट-एंड उपयोगकर्ता इंटरफ़ेस के लिए प्राथमिकता बहुत बढ़ जाती है, और बहुत अधिक नहीं - I / O संचालन पूरा करने के लिए)। इसलिए, एक धागा उच्च प्राथमिकता के साथ काम करता है जबकि यह इंटरैक्टिव रहता है। जब यह मुख्य रूप से संगणना (सीपीयू-बाउंड) से जुड़ा हो जाता है, तो इसकी प्राथमिकता कम हो जाती है, और उच्च प्राथमिकता वाले अन्य थ्रेड के बाद उनके प्रोसेसर समय होने पर वे वापस लौट जाते हैं। इसके अलावा, कर्नेल मनमाने ढंग से तैयार किए गए थ्रेड्स की प्राथमिकता को बढ़ाता है, जिन्हें एक निश्चित अवधि के लिए प्रोसेसर समय नहीं मिला है ताकि उनके कम्प्यूटेशनल भुखमरी को रोका जा सके और प्राथमिकता उलटा को सही किया जा सके।

विंडोज शेड्यूलर में शुरू में एक तत्परता कतार थी, जिसमें से इसे चलाने के लिए अगले, सर्वोच्च प्राथमिकता वाले धागे का चयन किया गया था। हालांकि, प्रोसेसर की बढ़ती संख्या के लिए समर्थन की शुरुआत के साथ, एकमात्र कतार एक अड़चन में बदल गई, और अनुसूचक ने विंडोज सर्वर 2003 रिलीज क्षेत्र के आसपास काम बदल दिया और प्रति प्रोसेसर एक तत्परता कतार का आयोजन किया। जब एक प्रोसेसर के लिए कई अनुरोधों का समर्थन करने के लिए स्विच किया जाता है, तो उन्होंने सभी कतारों की रक्षा करने वाला एक भी वैश्विक लॉक नहीं किया, और अनुसूचक को स्थानीय ऑप्टिमा के आधार पर निर्णय लेने की अनुमति दी। इसका मतलब यह है कि सिस्टम में किसी भी क्षण में सर्वोच्च प्राथमिकता वाला एक धागा होता है, लेकिन यह जरूरी नहीं है कि सूची में सर्वोच्च प्राथमिकता के धागे (जहां एन प्रोसेसर की संख्या है) सिस्टम में काम करते हैं। इस दृष्टिकोण ने तब तक भुगतान किया जब तक कि विंडोज ने लैपटॉप और टैबलेट जैसे कम-शक्ति वाले सीपीयू पर स्विच करना शुरू नहीं किया। जब सर्वोच्च प्राथमिकताओं वाला थ्रेड ऐसे सिस्टम पर काम नहीं करता था (उदाहरण के लिए, उपयोगकर्ता इंटरफ़ेस का फ्रंट-एंड थ्रेड), तो यह ध्यान देने योग्य इंटरफ़ेस ग्लिट्स का कारण बना। इसलिए, विंडोज 8.1 में, शेड्यूलर को हाइब्रिड मॉडल में स्थानांतरित किया गया था, इस प्रोसेसर से जुड़े थ्रेड्स के लिए प्रत्येक प्रोसेसर के लिए कतारों और सभी प्रोसेसर के लिए तैयार प्रक्रियाओं की एक साझा कतार थी। शेड्यूलर आर्किटेक्चर में अन्य परिवर्तनों के कारण यह प्रदर्शन को प्रभावित नहीं करता है, उदाहरण के लिए, एक डिस्पैचर डेटाबेस लॉक को फिर से भरना।

विंडोज 7 ने डायनेमिक फेयर शेयर शेड्यूलर (डायनेमिक फेयर शेयर शेड्यूलर, डीएफएसएस) के रूप में ऐसी चीज पेश की; यह मुख्य रूप से संबंधित टर्मिनल सर्वर है। इस सुविधा ने इस समस्या को हल करने का प्रयास किया कि उच्च सीपीयू लोड वाला एक टर्मिनल सत्र अन्य टर्मिनल सत्रों में थ्रेड्स को प्रभावित कर सकता है। चूंकि शेड्यूलर ने सत्र सत्रों को ध्यान में नहीं रखा है और केवल प्रवाह को वितरित करने के लिए प्राथमिकता का उपयोग किया है, इसलिए विभिन्न सत्रों में उपयोगकर्ता अपने प्रवाह का गला घोंटकर अन्य सत्रों में उपयोगकर्ताओं के काम को प्रभावित कर सकते हैं। इसने बड़ी संख्या में थ्रेड्स के साथ सत्रों (और उपयोगकर्ताओं) को एक अनुचित लाभ दिया, क्योंकि बड़ी संख्या में थ्रेड्स वाले सत्र में प्रोसेसर समय प्राप्त करने के अधिक अवसर थे। शेड्यूलर में एक नियम जोड़ने का प्रयास किया गया था, जिसके अनुसार प्रत्येक सत्र को प्रोसेसर समय के मामले में दूसरों के साथ एक समान पायदान पर माना जाता था। लिनक्स में समान कार्यक्षमता उनके पूरी तरह से ईमानदार अनुसूचक ( पूरी तरह से उचित समयबद्धक ) के साथ मौजूद है। विंडोज 8 में, इस अवधारणा को एक अनुसूचक समूह के रूप में सामान्यीकृत किया गया और अनुसूचक में जोड़ा गया, जिसके परिणामस्वरूप प्रत्येक सत्र एक स्वतंत्र समूह में गिर गया। थ्रेड्स के लिए प्राथमिकताओं के अलावा, शेड्यूलर शेड्यूलर समूहों का उपयोग दूसरे स्तर के इंडेक्स के रूप में करता है, जो यह तय करता है कि कौन सा धागा आगे शुरू करना है। टर्मिनल सर्वर में, सभी अनुसूचक समूहों का वजन एक समान होता है, इसलिए सभी सत्रों में प्रोसेसर समय का एक ही मात्रा प्राप्त होता है, चाहे अनुसूचक समूहों के भीतर थ्रेड्स की संख्या या प्राथमिकता हो। इसके अलावा, ऐसे समूहों का उपयोग प्रक्रियाओं पर अधिक सटीक नियंत्रण के लिए भी किया जाता है। विंडोज 8 में, प्रोसेसर समय प्रबंधन का समर्थन करने के लिए जॉब ऑब्जेक्ट्स को बढ़ाया गया है। एक विशेष एपीआई का उपयोग करके, आप यह तय कर सकते हैं कि प्रक्रिया कितनी प्रोसेसर समय का उपयोग कर सकती है, क्या यह एक नरम या कठोर सीमा होनी चाहिए, और जब प्रक्रिया इन सीमाओं तक पहुंच जाती है, तो सूचनाएं प्राप्त करें। यह लिनक्स पर cgroups में संसाधन प्रबंधन के समान है।

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

लेकिन उन मशीनों पर जहां सीपीयू कोर की संख्या 64 से अधिक है, विंडोज ने नई अड़चनें दिखानी शुरू कर दीं, जो प्रोसेसर कोर की बढ़ती संख्या के साथ रेखीय रूप से स्केल किए गए SQL सर्वर जैसे अनुप्रयोगों की मांग को रोकती हैं। इसलिए, नए कोर और मेमोरी के अलावा, गति माप में भी उल्लेखनीय वृद्धि नहीं दिखाई दी। इससे जुड़ी मुख्य समस्याओं में से एक डिस्पैचर बेस को ब्लॉक करने पर विवाद था। डिस्पैचर डेटाबेस को लॉक करना उन वस्तुओं तक पहुंच को संरक्षित करता है जिनके काम की योजना बनाई जानी थी। इन ऑब्जेक्ट्स में थ्रेड्स, टाइमर, इनपुट / आउटपुट पोर्ट्स, अन्य कर्नेल ऑब्जेक्ट्स जो वेटिंग (ईवेंट्स, सेमाफोर्स, म्यूटेक्स) के अधीन हैं। ऐसी समस्याओं को हल करने की आवश्यकता के दबाव में, विंडोज 7 में, डिस्पैचर डेटाबेस को अवरुद्ध करने और इसे अधिक सटीक समायोजन के साथ बदलने के लिए काम किया गया था, उदाहरण के लिए, ऑब्जेक्ट-बाय-ब्लॉक लॉकिंग। कुछ कॉन्फ़िगरेशन पर पिछले स्कीमा की तुलना में SQL TPC-C में गति में 290% वृद्धि प्रदर्शित करने के लिए इसने प्रदर्शन माप की अनुमति दी। यह विंडोज इतिहास में सबसे बड़ी प्रदर्शन अप में से एक था जो एक एकल फीचर में बदलाव के कारण हुआ।

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

अंत में, हम ARM64 के लिए समर्थन करने के लिए आते हैं, जो विंडोज 10 में दिखाई दिया । एआरएम वास्तुकला बड़े.लिटेल आर्किटेक्चर का समर्थन करता है, जो प्रकृति में विषम है - "बड़े" कोर तेज है और बहुत अधिक ऊर्जा खपत करता है, और "छोटा" कोर धीमा है और कम खपत करता है। विचार यह है कि तुच्छ कार्यों को एक छोटे से कोर पर किया जा सकता है, इस प्रकार बैटरी की बचत होती है। ARM पर विंडोज 10 चलाने पर बिग.लिटल आर्किटेक्चर का समर्थन करने और बैटरी जीवन को बढ़ाने के लिए, शेड्यूलर में एक विषम लेआउट समर्थन जोड़ा गया था, जो बड़े.लीटल आर्किटेक्चर के साथ काम करने वाले एप्लिकेशन की इच्छाओं को ध्यान में रखता है।

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

किसी और की ओर से काम करें [काम पर काम]: विंडोज में, अग्रभूमि में बहुत सारा काम अन्य सेवाओं द्वारा किया जाता है जो पृष्ठभूमि में काम करते हैं। उदाहरण के लिए, जब आउटलुक में खोज की जाती है, तो खोज इंडेक्सर पृष्ठभूमि सेवा द्वारा की जाती है। यदि हम बस एक छोटी सी कोर पर सभी सेवाओं को चलाते हैं, तो अग्रभूमि में अनुप्रयोगों की गुणवत्ता और गति को नुकसान होगा। ऐसे कार्य परिदृश्यों के तहत बड़े.लिटेल आर्किटेक्चर पर इसे धीमा करने से रोकने के लिए, विंडोज अपनी ओर से काम करने के लिए अन्य प्रक्रियाओं पर आने वाले एप्लिकेशन कॉल की निगरानी करता है। इस मामले में, हम सेवा से संबंधित थ्रेड को अग्रभूमि प्राथमिकता देते हैं और इसे बड़े कोर पर चलाने के लिए मजबूर करते हैं।

मुझे विंडोज कर्नेल पर यह पहला लेख खत्म करने दें, जो अनुसूचक का अवलोकन करता है। ओएस के आंतरिक कामकाज के बारे में समान तकनीकी विवरण वाले लेख बाद में अनुसरण करेंगे।