खोज…


परिचय

इतिहास

पहला कंप्यूटर

प्रारंभिक कंप्यूटर में मेमोरी का एक ब्लॉक था जिसे प्रोग्रामर ने कोड और डेटा में डाल दिया था, और सीपीयू को इस वातावरण में निष्पादित किया गया था। यह देखते हुए कि कंप्यूटर तब बहुत महंगे थे, यह दुर्भाग्यपूर्ण था कि यह एक काम करेगा, रुक जाएगा और अगली नौकरी के लिए इसमें लोड होने की प्रतीक्षा करेगा, और फिर उस प्रक्रिया को करेगा।

मल्टी-यूजर, मल्टी-प्रोसेसिंग

इसलिए कंप्यूटर जल्दी से अधिक परिष्कृत हो गए और एक साथ कई उपयोगकर्ताओं और / या कार्यक्रमों का समर्थन किया - लेकिन जब समस्याएँ "स्मृति के एक ब्लॉक" विचार के साथ उत्पन्न होने लगीं। यदि कोई कंप्यूटर एक साथ दो प्रोग्राम चला रहा था, या कई उपयोगकर्ताओं के लिए एक ही प्रोग्राम चला रहा था - तो निश्चित रूप से प्रत्येक उपयोगकर्ता के लिए अलग-अलग डेटा की आवश्यकता होगी - फिर उस मेमोरी का प्रबंधन महत्वपूर्ण हो गया।

उदाहरण

उदाहरण के लिए: यदि एक प्रोग्राम मेमोरी एड्रेस 1000 पर काम करने के लिए लिखा गया था, लेकिन एक अन्य प्रोग्राम पहले से ही वहां लोड था, तो नया प्रोग्राम लोड नहीं किया जा सकता है। इसे हल करने का एक तरीका प्रोग्राम को "सापेक्ष पते" के साथ काम करना होगा - इससे कोई फर्क नहीं पड़ता था कि प्रोग्राम कहां लोड किया गया था, यह सिर्फ मेमोरी एड्रेस के सापेक्ष सब कुछ करता था जो इसे लोड किया गया था। लेकिन इसके लिए हार्डवेयर समर्थन की आवश्यकता थी।

मिलावट

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

समाधान

क्या जरूरत थी एक ऐसे तंत्र की जिसने स्मृति के ब्लॉक को गतिशील पते दिए। इस तरह एक कार्यक्रम को अपने पते पर यादों के अपने ब्लॉक के साथ काम करने के लिए लिखा जा सकता है, जो इसे मान्यता देता है - और अन्य कार्यक्रमों के लिए अन्य ब्लॉकों तक पहुंचने में सक्षम नहीं है (जब तक कि कुछ सहयोग ने इसे अनुमति नहीं दी)।

विभाजन

इसे लागू करने वाला एक तंत्र सेगमेंटेशन था। यह स्मृति के ब्लॉक को सभी विभिन्न आकारों में परिभाषित करने की अनुमति देता है, और कार्यक्रम को परिभाषित करने की आवश्यकता होगी कि वह किस सेगमेंट को हर समय एक्सेस करना चाहता था।

समस्या

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

पेजिंग

एक अलग तकनीक ने सभी मेमोरी को समान-आकार के ब्लॉक में विभाजित किया, जिसे "पेज" कहा जाता है, जिसने आवंटन और डील्लोकेशन रूटीन को बहुत सरल बना दिया, और बढ़ते, सिकुड़ते और विखंडन के साथ दूर किया (आंतरिक विखंडन को छोड़कर, जो केवल एक समस्या है अपव्यय)।

वर्चुअल एड्रेसिंग

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

हार्डवेयर और OS समर्थन

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

पेजिंग सुविधाएँ

एक बार हार्डवेयर यह रीमैपिंग कर सकता है, तो उसने क्या अनुमति दी? मुख्य ड्राइवर मल्टीप्रोसेसिंग था - एक-दूसरे से संरक्षित, कई कार्यक्रमों को चलाने की क्षमता, प्रत्येक अपनी "अपनी" मेमोरी के साथ। लेकिन दो अन्य विकल्पों में "विरल डेटा", और "वर्चुअल मेमोरी" शामिल थे।

बहु

प्रत्येक कार्यक्रम को अपना खुद का, आभासी "एड्रेस स्पेस" दिया गया था - उन पते की एक सीमा जो उन्हें भौतिक मेमोरी में मैप की जा सकती थी, जो भी पते वांछित थे। जब तक चारों ओर जाने के लिए पर्याप्त भौतिक स्मृति थी (हालांकि नीचे "वर्चुअल मेमोरी" देखें), कई कार्यक्रमों को एक साथ समर्थन किया जा सकता है।

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

विरल डेटा

एक विशाल वर्चुअल एड्रेस स्पेस की अनुमति (4 जीबी विशिष्ट है, जो कि इन प्रोसेसर के 32-बिट रजिस्टरों के साथ मेल खाने के लिए है) अपने आप में और मेमोरी की बर्बादी नहीं करता है, अगर उस एड्रेस स्पेस के बड़े क्षेत्र अनमैप हो जाते हैं। यह विशाल डेटा संरचनाओं के निर्माण की अनुमति देता है जहां केवल कुछ भागों को किसी एक समय में मैप किया जाता है। प्रत्येक दिशा में 1,000 बाइट्स के 3-आयामी सरणी की कल्पना करें: जो आम तौर पर एक बिलियन बाइट्स लेता है! लेकिन एक प्रोग्राम इस डेटा को "होल्ड" करने के लिए अपने वर्चुअल एड्रेस स्पेस के एक ब्लॉक को आरक्षित कर सकता है, लेकिन केवल छोटे वर्गों को मैप करते हैं क्योंकि वे आबाद थे। यह कुशल प्रोग्रामिंग के लिए बनाता है, जबकि डेटा के लिए मेमोरी बर्बाद नहीं करता है जिसकी अभी तक आवश्यकता नहीं है।

अप्रत्यक्ष स्मृति

ऊपर मैंने हार्डवेयर द्वारा प्रदर्शित वर्चुअल-टू-फिजिकल एड्रेसिंग का वर्णन करने के लिए "वर्चुअल एड्रेसिंग" शब्द का इस्तेमाल किया। इसे अक्सर "वर्चुअल मेमोरी" कहा जाता है - लेकिन यह शब्द अधिक सही रूप से उपलब्ध होने की तुलना में अधिक मेमोरी का भ्रम प्रदान करने के लिए वर्चुअल एड्रेसिंग का उपयोग करने की तकनीक से मेल खाता है।

यह इस तरह काम करता है:

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

    नोटिस करने के लिए महत्वपूर्ण बिंदु यह है कि चूंकि किसी भी पेज को किसी भी पते पर मैप किया जा सकता है, और प्रत्येक पृष्ठ समान आकार का है, तो एक पेज किसी भी अन्य के रूप में अच्छा है - जब तक सामग्री समान रहती है!

  • यदि कोई प्रोग्राम अनमैप्ड मेमोरी लोकेशन एक्सेस करता है, तो हार्डवेयर पहले की तरह OS को सूचित करता है। इस बार, OS नोट करता है कि यह एक ऐसा पृष्ठ नहीं था जिसे बचा लिया गया था, इसलिए इसे कार्यक्रम में बग के रूप में मान्यता देता है, और इसे समाप्त कर देता है!

    यह वास्तव में क्या होता है जब आपका ऐप रहस्यमय तरीके से आप पर गायब हो जाता है - शायद ओएस से एक मैसेजबॉक्स के साथ। यह भी क्या (अक्सर) एक बदनाम ब्लू स्क्रीन या सैड मैक का कारण बनता है - छोटी गाड़ी का कार्यक्रम वास्तव में एक ओएस चालक था जो मेमोरी तक पहुंच गया था कि यह नहीं होना चाहिए!

पेजिंग के फैसले

पेजिंग के बारे में कुछ बड़े निर्णय लेने के लिए हार्डवेयर आर्किटेक्ट की जरूरत होती है, क्योंकि डिजाइन सीधे सीपीयू के डिजाइन को प्रभावित करेगा! एक बहुत ही लचीली प्रणाली में एक उच्च ओवरहेड होगा, जिसमें बड़ी मात्रा में मेमोरी की आवश्यकता होती है, बस पेजिंग बुनियादी ढांचे का प्रबंधन करने के लिए।

पेज कितना बड़ा होना चाहिए?

हार्डवेयर में, पेजिंग का सबसे आसान कार्यान्वयन एक एड्रेस लेना और इसे दो भागों में विभाजित करना होगा। ऊपरी भाग किस पृष्ठ तक पहुँचने का सूचक होगा, जबकि निचला भाग आवश्यक बाइट के लिए पृष्ठ में सूचकांक होगा:

+-----------------+------------+
| Page index      | Byte index |
+-----------------+------------+

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

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

+-----------+------------+------------+
| Dir index | Page index | Byte index |
+-----------+------------+------------+

इसका मतलब है कि कई पेज इंडेक्स की आवश्यकता के बिना एक निर्देशिका सूचकांक पता स्थान के एक विशाल हिस्से के लिए "मैप नहीं किया गया" इंगित कर सकता है।

पेज टेबल्स के उपयोग का अनुकूलन कैसे करें?

सीपीयू द्वारा किए जाने वाले हर पते का उपयोग मैप करना होगा - वर्चुअल-टू-फिजिकल प्रक्रिया इसलिए यथासंभव कुशल होनी चाहिए। यदि ऊपर वर्णित त्रि-स्तरीय प्रणाली को लागू किया जाना था, तो इसका मतलब यह होगा कि प्रत्येक मेमोरी एक्सेस वास्तव में तीन एक्सेस होगी: डायरेक्टरी में एक; पृष्ठ तालिका में एक; और फिर अंत में वांछित डेटा ही। और यदि सीपीयू को हाउसकीपिंग करने की आवश्यकता होती है, जैसे कि यह इंगित करना कि यह पृष्ठ अब एक्सेस किया गया है या लिखा गया है, तो खेतों को अपडेट करने के लिए अभी और एक्सेस की आवश्यकता होगी।

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

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

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

80386 पेजिंग

उच्च स्तरीय डिजाइन

80386 एक 32-बिट प्रोसेसर है, जिसमें 32-बिट पता योग्य मेमोरी स्पेस है। पेजिंग सबसिस्टम के डिजाइनरों ने उल्लेख किया कि एक 4K पेज डिज़ाइन उन 32 बिट्स में काफी साफ-सुथरे तरीके से मैप किया गया है - 10 बिट्स, 10 बिट्स और 12 बिट्स:

+-----------+------------+------------+
| Dir index | Page index | Byte index |
+-----------+------------+------------+
 3         2 2          1 1          0  Bit
 1         2 1          2 1          0  number

इसका मतलब था कि बाइट इंडेक्स 12 बिट्स चौड़ा था, जो कि 4K पेज में इंडेक्स होगा। डायरेक्टरी और पेज इंडेक्स 10 बिट्स थे, जो प्रत्येक मैप को 1,024-एंट्री टेबल में डालते थे - और यदि उन टेबल एंट्रीज में प्रत्येक 4 बाइट्स होते हैं, तो यह 4K प्रति टेबल होगी: एक पेज भी!

इसलिए उन्होंने यही किया:

  • प्रत्येक कार्यक्रम की अपनी एक निर्देशिका होगी, 1,024 पृष्ठ प्रविष्टियों वाला एक पृष्ठ जिसमें प्रत्येक परिभाषित होता है कि अगला स्तर पृष्ठ तालिका कहाँ था - यदि कोई था।
  • यदि वहाँ था, तो उस पृष्ठ तालिका में 1,024 पृष्ठ प्रविष्टियाँ होंगी जिनमें से प्रत्येक में परिभाषित किया गया था कि अंतिम स्तर पृष्ठ कहाँ था - यदि कोई था।
  • अगर वहाँ था, तो वह पेज सीधे अपनी बाइट को पढ़ सकता था।

पृष्ठ प्रविष्टि

शीर्ष-स्तरीय निर्देशिका और अगले-स्तरीय पृष्ठ तालिका दोनों में 1,024 पृष्ठ प्रविष्टियाँ शामिल हैं। इन प्रविष्टियों का सबसे महत्वपूर्ण हिस्सा यह है कि यह किसका अनुक्रमण है: एक पृष्ठ तालिका या वास्तविक पृष्ठ। ध्यान दें कि इस पते को पूर्ण 32 बिट्स की आवश्यकता नहीं है - चूंकि सब कुछ एक पृष्ठ है, केवल शीर्ष 20 बिट्स महत्वपूर्ण हैं। इस प्रकार पृष्ठ प्रविष्टि में अन्य 12 बिट्स का उपयोग अन्य चीजों के लिए किया जा सकता है: चाहे अगला स्तर भी मौजूद हो; हाउसकीपिंग के रूप में कि क्या पृष्ठ तक पहुँचा या लिखा गया है; और यहां तक कि क्या लिखने की भी अनुमति दी जानी चाहिए!

+--------------+----+------+-----+---+---+
| Page Address | OS | Used | Sup | W | P |
+--------------+----+------+-----+---+---+
Page Address = Top 20 bits of Page Table or Page address
OS           = Available for OS use
Used         = Whether this page has been accessed or written to
Sup          = Whether this page is Supervisory - only accessible by the OS
W            = Whether this page is allowed to be Written
P            = Whether this page is even Present

ध्यान दें कि यदि P बिट 0 है, तो बाकी एंट्री को कुछ भी करने की अनुमति है जो OS वहां डालना चाहता है - जैसे कि पेज की सामग्री हार्ड डिस्क पर होना चाहिए!

पेज डायरेक्टरी बेस रजिस्टर ( PDBR )

यदि प्रत्येक प्रोग्राम की अपनी निर्देशिका है, तो हार्डवेयर कैसे जानता है कि मैपिंग कहां से शुरू करें? चूंकि सीपीयू एक बार में केवल एक प्रोग्राम चला रहा है, इसलिए इसमें वर्तमान प्रोग्राम की डायरेक्टरी का पता रखने के लिए एक सिंगल कंट्रोल रजिस्टर है। यह पेज डायरेक्टरी बेस रजिस्टर ( CR3 ) है। जैसे ही ओएस विभिन्न कार्यक्रमों के बीच स्वैप होता है, यह प्रोग्राम के लिए प्रासंगिक पेज डायरेक्टरी के साथ PDBR को अपडेट करता है।

पृष्ठ दोष

हर बार सीपीयू मेमोरी तक पहुँच जाता है, उसे संकेतित आभासी पते को उपयुक्त भौतिक पते में मैप करना पड़ता है। यह तीन-चरणीय प्रक्रिया है:

  1. उचित पृष्ठ तालिका का पता प्राप्त करने के लिए PDBR द्वारा इंगित पृष्ठ में पते के शीर्ष 10 बिट्स को PDBR करें;
  2. उचित पृष्ठ का पता प्राप्त करने के लिए निर्देशिका द्वारा इंगित पृष्ठ में पते के अगले 10 बिट्स को अनुक्रमित करें;
  3. उस पृष्ठ से डेटा प्राप्त करने के लिए पते के अंतिम 12 बिट्स को अनुक्रमित करें।

क्योंकि दोनों चरण 1 और 2 से ऊपर पृष्ठ प्रविष्टियों का उपयोग करते हैं, प्रत्येक प्रविष्टि समस्या का संकेत दे सकती है:

  • अगले स्तर को "नॉट प्रेजेंट" के रूप में चिह्नित किया जा सकता है;
  • अगले स्तर को "केवल पढ़ने के लिए" के रूप में चिह्नित किया जा सकता है - और ऑपरेशन एक लिखें है;
  • अगले स्तर को "पर्यवेक्षक" के रूप में चिह्नित किया जा सकता है - और यह मेमोरी तक पहुंचने वाला कार्यक्रम है, न कि ओएस।

जब इस तरह की समस्या को हार्डवेयर द्वारा नोट किया जाता है, तो एक्सेस पूरा करने के बजाय यह एक फॉल्ट उठाता है: इंटरप्ट # 14, पेज फाल्ट। यह कुछ विशिष्ट नियंत्रण रजिस्टरों में भी भरता है कि फॉल्ट क्यों हुआ था, इस बात की जानकारी के साथ: पता संदर्भित; चाहे वह पर्यवेक्षक की पहुँच हो; और क्या यह एक लिखने का प्रयास था।

OS से यह उम्मीद की जाती है कि वह Fault, Control Registers को डिकोड करेगा और तय करेगा कि उसे क्या करना है। यदि यह एक अमान्य एक्सेस है, तो यह फ़ॉल्टिंग प्रोग्राम को समाप्त कर सकता है। यदि यह एक वर्चुअल मेमोरी एक्सेस है, तो ओएस को एक नया पेज आवंटित करना चाहिए (जो पहले से उपयोग में आने वाले पेज को खाली करने की आवश्यकता हो सकती है!), इसे आवश्यक सामग्री (या तो सभी शून्य, या पिछली सामग्री डिस्क से लोड करके भरें) ), नए पेज को उचित पेज टेबल में मैप करें, इसे वर्तमान के रूप में चिह्नित करें, फिर फॉल्टिंग निर्देश को फिर से शुरू करें। इस बार पहुंच सफलतापूर्वक प्रगति करेगी, और कार्यक्रम बिना किसी ज्ञान के आगे बढ़ेगा कि कुछ भी विशेष नहीं हुआ (जब तक कि यह घड़ी पर एक नज़र न लगे!)

80486 पेजिंग

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

अन्य सभी मामलों में, "80386 पेजिंग" उदाहरण लागू है।

पेंटियम पेजिंग

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

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

एड्रेस लेआउट

+-----------+----------------------+
| Dir Index | 4MB Byte Index       |
+-----------+----------------------+
 3         2 2                    0   Bit
 1         2 1                    0   number

निर्देशिका प्रविष्टि लेआउट

+-----------+----+---+------+-----+---+---+
| Page Addr | OS | S | Used | Sup | W | P |
+-----------+----+---+------+-----+---+---+
Page Addr = Top 20 bits of Page Table or Page address
OS        = Available for OS use
S         = Size of Next Level: 0 = Page Table, 1 = 4 MB Page
Used      = Whether this page has been accessed or written to
Sup       = Whether this page is Supervisory - onlly accessible by the OS
W         = Whether this page is allowed to be Written
P         = Whether this page is even Present

बेशक, कि कुछ प्रभाव था:

  • 4 एमबी पेज को 4 एमबी एड्रेस सीमा पर शुरू करना था, ठीक उसी तरह जैसे 4K पेज को 4K एड्रेस सीमा पर शुरू करना था।
  • सभी 4 एमबी को एक कार्यक्रम से संबंधित होना चाहिए - या कई लोगों द्वारा साझा किया जाना चाहिए।

यह बड़े-मेमोरी बाह्य उपकरणों के लिए उपयोग के लिए एकदम सही था, जैसे कि ग्राफिक्स एडेप्टर, जिसमें बड़ी एड्रेस स्पेस विंडो थीं, जिन्हें उपयोग करने के लिए ओएस के लिए मैप करने की आवश्यकता थी।

भौतिक पता एक्सटेंशन (PAE)

परिचय

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

अधिक रैम

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

डिज़ाइन

मौजूदा सिस्टम अधिकतम 32 बिट्स भौतिक पते तक पहुँच सकता है। इसे बढ़ाने से पृष्ठ प्रविष्टि संरचना के पूर्ण परिवर्तन की आवश्यकता होती है, 32 से 64 बिट्स तक। 4K पन्नों पर न्यूनतम ग्रैन्युलैरिटी रखने का निर्णय लिया गया था, इसलिए 64-बिट एंट्री में 52 बिट्स ऑफ एड्रेस और 12 बिट्स ऑफ कंट्रोल होंगे (जैसे पिछली एंट्री में 20 बिट्स ऑफ एड्रेस और 12 बिट्स ऑफ कंट्रोल)।

64-बिट प्रविष्टि, लेकिन एक पृष्ठ आकार (अभी भी) 4K होने का मतलब है कि पिछले 1,024 के बजाय प्रति पृष्ठ तालिका या निर्देशिका में केवल 512 प्रविष्टियाँ होंगी। इसका मतलब है कि 32-बिट वर्चुअल एड्रेस को पहले की तुलना में अलग तरीके से विभाजित किया जाएगा:

+-----+-----------+------------+------------+
| DPI | Dir Index | Page Index | Byte Index |
+-----+-----------+------------+------------+
 3   3 2         2 2          1 1          0   Bit
 1   0 9         1 0          2 1          0   number

 DPI        = 2-bit index into Directory Pointer Table
 Dir Index  = 9-bit index into Directory
 Page Index = 9-bit index into Page Table
 Byte Index = 12-bit index into Page (as before)

डायरेक्टरी इंडेक्स और पेज इंडेक्स दोनों में से एक बिट को काटते हुए मैपिंग के तीसरे टियर के लिए दो बिट्स दिए गए: उन्होंने इसे पेज डाइरेक्टरी पॉइंटर टेबल (PDPT) कहा, ठीक चार 64-बिट एंट्रीज की एक टेबल, जिसने पिछले के बजाय चार डिरेक्ट्रीज़ को संबोधित किया था। एक। PDBR ( CR3 ) ने अब PDPT की ओर संकेत किया - जो, चूंकि CR3 केवल 32 बिट्स था, इसलिए एक्सेसिबिलिटी के लिए पहले 4 GB RAM में स्टोर किया जाना आवश्यक था। ध्यान दें कि चूंकि CR3 के कम बिट्स का उपयोग नियंत्रण के लिए किया जाता है, PDPT को 32-बाइट सीमा पर शुरू करना होगा।

पृष्ठ आकार विस्तार (PSE)

और, चूंकि पिछले 4 एमबी पृष्ठ इतने अच्छे विचार थे, इसलिए वे फिर से बड़े पृष्ठों का समर्थन करने में सक्षम होना चाहते थे। हालांकि इस बार, टियर सिस्टम की अंतिम परत को हटाने से 10 + 12 बिट 4MB पेज नहीं बने, बल्कि 9 + 12 बिट 2 एमबी पेज बने।

PSE-32 (और PSE-40)

चूंकि पेंटियम प्रो (और पेंटम एम) में पेश किए गए भौतिक पता एक्सटेंशन (पीएई) मोड ऑपरेटिंग सिस्टम मेमोरी मैनेजमेंट सबसिस्टम के लिए एक ऐसा बदलाव था, जब इंटेल ने पेंटियम II डिजाइन किया था जो उन्होंने "सामान्य" पेज मोड को बढ़ाने का फैसला किया था। पहले से परिभाषित 32-बिट प्रविष्टियों के भीतर प्रोसेसर के नए भौतिक पता बिट्स का समर्थन करें।

उन्होंने महसूस किया कि जब 4MB पेज का उपयोग किया जाता था, तो डायरेक्टरी एंट्री इस तरह दिखती थी:

+-----------+------------+---------+
| Dir Index |  Unused    | Control |
+-----------+------------+---------+

एंट्री के डर इंडेक्स और कंट्रोल क्षेत्र समान थे, लेकिन उनके बीच अप्रयुक्त बिट्स का ब्लॉक - जो पेज इंडेक्स द्वारा उपयोग किया जाएगा यदि यह अस्तित्व में था - व्यर्थ। इसलिए उन्होंने 31 से ऊपर के ऊपरी भौतिक पता बिट्स को परिभाषित करने के लिए उस क्षेत्र का उपयोग करने का फैसला किया!

+-----------+------+-----+---------+
| Dir Index |Unused|Upper| Control |
+-----------+------+-----+---------+

इसने 4 जीबी से ऊपर की रैम को उन OSes के लिए एक्सेस करने की अनुमति दी जो PAE मोड को नहीं अपनाते थे - थोड़े अतिरिक्त तर्क के साथ, वे सिस्टम को बड़ी मात्रा में अतिरिक्त RAM प्रदान कर सकते थे, भले ही प्रत्येक प्रोग्राम में सामान्य 4GB से अधिक न हो। पहले केवल 4 बिट्स जोड़े गए थे, जो 36-बिट फिजिकल एड्रेसिंग के लिए अनुमति देते थे, इसलिए इस मोड को पेज साइज़ एक्सटेंशन 36 (PSE-36) कहा जाता था। यह वास्तव में पृष्ठ का आकार नहीं बदला था, केवल संबोधित हालांकि।

हालांकि इसकी सीमा यह थी कि 4GB से ऊपर केवल 4MB पेज ही निश्चित थे - 4K पेज की अनुमति नहीं थी। इस मोड को अपनाना व्यापक नहीं था - यह कथित तौर पर PAE का उपयोग करने की तुलना में धीमा था, और लिनक्स ने कभी भी इसका उपयोग नहीं किया।

फिर भी, बाद के प्रोसेसरों में, जिसमें भौतिक पते बिट्स भी अधिक थे, AMD और Intel दोनों ने PSE क्षेत्र को 8 बिट तक चौड़ा कर दिया, जिसे कुछ लोगों ने "PSE-40" करार दिया



Modified text is an extract of the original Stack Overflow Documentation
के तहत लाइसेंस प्राप्त है CC BY-SA 3.0
से संबद्ध नहीं है Stack Overflow