2010-10-27 16 views
18

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

+0

वर्चुअल स्पेस आकार/पृष्ठ आकार के कारण 2^28 प्रविष्टियां। 4 बाइट प्रति प्रविष्टि (वीपी संख्याओं को संबोधित करने के लिए 28 बिट्स, + 4 बिट्स = 32 बिट्स) 2^28 * 4 = 1024 एमबी, जो भौतिक स्मृति से बड़ा है। समझ में नहीं आता है, मैं स्कूल में विफल रहता हूं। यह मेरा अनुमान है, असली जवाब नहीं। अग्रिम धन्यवाद। –

+0

मुझे प्रश्न में कहीं भी सभी पेज टेबल भौतिक स्मृति में होने की आवश्यकता नहीं दिख रही है। – paxdiablo

+0

भौतिक स्मृति क्यों दी जाएगी और फिर यह बताएगी कि तालिका में संग्रहीत कोई डिस्क पता नहीं है? यह इंगित करेगा कि आपको केवल 512 एमबी भौतिक स्मृति को संबोधित करने की आवश्यकता है .. जब तक कि मैं गलत नहीं हूं। फिर से धन्यवाद। –

उत्तर

29

अच्छा, यदि प्रश्न बस "पृष्ठ तालिका का आकार क्या है?" भले ही यह भौतिक स्मृति में फिट होगा, इस प्रकार उत्तर की गणना की जा सकती है:

पहली भौतिक स्मृति। भौतिक स्मृति के 512 के पृष्ठ हैं (512 एम/1 के)। प्रत्येक पृष्ठ का प्रतिनिधित्व करने के लिए इसमें 1 9 बिट्स की आवश्यकता होती है। इसे लेखांकन जानकारी के 4 बिट्स में जोड़ें और आपको 23 बिट मिलते हैं।

अब वर्चुअल मेमोरी। 38-बिट पता स्थान और 10-बिट (1 के) पृष्ठ आकार के साथ, आपको अपनी पृष्ठ तालिका में 2 प्रविष्टियों की आवश्यकता है।

इसलिए 2 23 बिट्स पर पृष्ठ तालिका प्रविष्टियां प्रत्येक 6,174,015,488 बिट्स या 736 मीटर है।

प्रत्येक प्रक्रिया के लिए एकल स्तर के वीएम उपप्रणाली के लिए आवश्यक अधिकतम आकार है।

अब स्पष्ट रूप से यह काम नहीं करेगा यदि आपके पास केवल 512 एम भौतिक रैम है तो आपके पास कुछ विकल्प हैं।

  1. आप भौतिक पृष्ठों की संख्या को कम कर सकते हैं। उदाहरण के लिए, केवल आधे स्मृति को पेजिंग के अधीन होने दें, अन्य आधा निवासी को हर समय रखें। यह प्रति प्रविष्टि एक बिट बचाएगा, वास्तव में कोई फर्क नहीं पड़ता।

  2. पृष्ठ आकार बढ़ाएं, यदि संभव हो तो। एक 38-बिट एड्रेस स्पेस पर 1K पृष्ठ बहुत चंचल पेज टेबल का कारण है। उदाहरण के लिए, मुझे लगता है कि '386, इसकी 32-बिट एड्रेस स्पेस के साथ, 4 के पेज का उपयोग करता है। इसके परिणामस्वरूप लाखों पेज टेबल प्रविष्टियां होंगी, जो यहां आवश्यक 260 मिलियन से कम थीं।

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


की अगर हम प्राथमिक पेजिंग तालिका के लिए 32M अनुमति देने के विकल्प 3.

पर एक छोटे से करीब नजर डालते हैं और प्रत्येक प्रविष्टि 4 बाइट (32 बिट दे: केवल 23 की जरूरत है, लेकिन हम गोल कर सकते हैं यहां दक्षता के लिए), यह माध्यमिक पृष्ठ तालिका के लिए 8,388,608 पृष्ठों की अनुमति देगा।

चूंकि इनमें से प्रत्येक द्वितीयक पृष्ठ तालिका पृष्ठ 1K लंबा है (हमें 256 माध्यमिक पृष्ठ तालिका प्रविष्टियों को प्रत्येक 4 बाइट्स पर स्टोर करने की इजाजत देता है), हम कुल 2,147,483,648 आभासी पृष्ठों को संबोधित कर सकते हैं।

यह 8,192 पूरी तरह से लोड (यानी, अपनी पूरी 28-बिट एड्रेस स्पेस का उपयोग करके) प्रक्रियाओं को तरफ से चलाने की अनुमति देगा, मान लीजिए कि आपके पास अनिवासी पृष्ठों को स्टोर करने के लिए डिस्क स्पेस का उचित हिस्सा है।

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

लेकिन प्राथमिक पेजिंग तालिका के लिए 512 एम के केवल 32 एम की निवासी लागत है, 736 एम के (न्यूनतम, एक पूरी तरह से लोड की गई प्रक्रिया के लिए) से काफी बेहतर है। पृष्ठ सारणी = की

+0

महान प्रतिक्रिया के लिए धन्यवाद! एक बात - जब तक कि मैं अपना गणित गलत टाइप नहीं कर रहा हूं, 2^28 * 32 = 6,174,015,488 बिट्स = 771,751,936 बाइट्स = 738 एमबी नहीं होना चाहिए? और हाँ, मुझे पूरा यकीन है कि आप एक 4 केबी पेज आकार को लागू करेंगे, शायद 8 या 16 ... –

+1

हां, आपकी गणना सही है लेकिन ऐसा इसलिए है क्योंकि आप 32-बिट पेज एंट्री का उपयोग कर रहे हैं जबकि मेरा 23-बिट था एक वास्तविक प्रणाली में, आप इसमें कम से कम 24 बिट्स तक पहुंच सकते हैं, और शायद 32 जैसा आपने किया है, लेकिन यही कारण है कि आंकड़े अलग हैं। चाहे आप 23 या 32 बिट्स का उपयोग करते हैं, केवल प्रश्न यह है कि कम से कम 4 बिट्स की आवश्यकता थी। अगर मैं असाइनमेंट कर रहा था, तो मैं प्रत्येक के कारणों के साथ कई विकल्प पेश करता। लेकिन फिर शायद मुझे स्मार्ट होने के लिए चिह्नित किया जाएगा- *** :-) – paxdiablo

+0

ओह, यह मेरे हिस्से पर एक टाइपो था। वास्तव में यह 2^28 * 23 बिट्स = 6174015488 या 736 एमबी के लिए गणना है .. –

8

आकार पेज तालिका प्रविष्टियों की कुल संख्या * पेज तालिका प्रविष्टि के आकार

कदम 1:

no of page table entries=virtual address space/page size 

=2^38/2^10=2^28 

तो वहाँ 2 हैं: पृष्ठ तालिका में प्रविष्टियों की कोई खोज^पेज तालिका में 28 प्रविष्टियों

चरण 2: NO भौतिक स्मृति के फ्रेम की:

no of frames in the physical memory=(512*1024*1024)/(1*1024)=524288=2^19

तो हम 19 bits और अतिरिक्त 4 bits वैध, सुरक्षा के लिए, गंदे जरूरत है और बिट का उपयोग पूरी तरह से 23 बिट = 2.875 बाइट्स

size of the page table=(2^28)*2.875=771751936B=736MB 
-2

1KB पृष्ठों = 2^10, 512MB = 2^29 => ऑफसेट = 29 - 10 = 1 9 बिट।

वर्चुअल में दो भाग शामिल हैं: पृष्ठ फ्रेम + ऑफ़सेट => पृष्ठ फ्रेम + गंदे बिट = 38 - 1 9 = 2 9 बिट। 2 9 बिट में वास्तविक बिट फ्रेम के लिए 4 बिट गंदे (ऊपर) => 25 बिट शामिल है, प्रत्येक पृष्ठ फ्रेम में 10 बिट लंबा होता है।

तो, पृष्ठ तालिका का आकार: 2^25 * 10 = 320 एम।

यह सही आशा है।

संबंधित मुद्दे