2014-09-24 7 views
6

मेरे पास लिनक्स कर्नेल और एमएमयू के बीच संबंधों के बारे में एक सवाल है। अब मुझे एक बिंदु मिला है कि लिनक्स कर्नेल वर्चुअल मेमोरी पतों और भौतिक मेमोरी पतों के बीच पृष्ठ तालिका का प्रबंधन करता है। उसी समय x86 आर्किटेक्चर में MMU है जो वर्चुअल मेमोरी पतों और भौतिक मेमोरी पतों के बीच पृष्ठ तालिका प्रबंधित करता है। यदि एमएमयू सीपीयू के पास प्रस्तुत करता है, तो कर्नेल को अभी भी पृष्ठ तालिका का ख्याल रखने की आवश्यकता है?लिनक्स पेज टेबल मैनेजमेंट और एमएमयू

यह सवाल बेवकूफ हो सकता है लेकिन अन्य सवाल है, अगर MMU स्मृति स्थान, जो उच्च स्मृति और कम स्मृति का प्रबंधन करता है का ख्याल रखता है? मेरा मानना ​​है कि कर्नेल को एमएमयू (32 बिट में 4 जीबी) से वर्चुअल मेमोरी का आकार प्राप्त होगा, तो कर्नेल वर्चुअल एड्रेस में यूजर स्पेस और कर्नेल स्पेस के बीच अंतर करेगा। क्या मैं सही हूँ? या पूरी तरह से गलत?

बहुत पहले से धन्यवाद!

+0

लिनक्स कोई MMU के साथ हार्डवेयर पर चल सकते हैं, तो गिरी पता करने के लिए, कैसे अनुवाद करने के लिए है, लेकिन 86 पर, मेरा मानना ​​है, यह सिर्फ MMU इसके लिए इस्तेमाल करते हैं। –

+0

मैं गेनाडी की टिप्पणी के लिए दूसरा। X86 आर्किटेक्चर पर एमएमयू वर्चुअल पतों को भौतिक पतों में अनुवाद करने का ख्याल रखता है, लेकिन कर्नेल अभी भी ट्रैक रखेगा कि कौन से पेज कर्नेल से संबंधित हैं और कौन से पेज उपयोगकर्ता प्रक्रियाओं से संबंधित हैं। मेरा मानना ​​है कि [यह] (http://www.tldp.org/LDP/tlk/mm/memory.html) कुछ प्रकाश डालने में मदद कर सकता है कि चीजें कैसे काम करती हैं। –

उत्तर

5

ओएस और MMU पेज प्रबंधन जिम्मेदारियों उसी तंत्र, कि वास्तुकला और माइक्रो-संरचना के बीच सीमा पर रहता है के 2 पहलू हैं।

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

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

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

+1

कर्नेल और उपयोगकर्ता स्थान को अलग करने के बारे में प्रश्न के हिस्से को विशेष रूप से संबोधित करना उचित लगता है। (मुझे लगता है * लिनक्स कर्नेल स्पेस के लिए (वैश्विक) नकारात्मक पते का उपयोग करता है और x86 के लिए इसे पदानुक्रमित पृष्ठ तालिका (प्रति पता स्थान) के शीर्ष पर एक पृष्ठ की आवश्यकता होती है जिसमें ऊपरी (ऋणात्मक) आधा नक्शा कर्नेल सबटेबल्स हैं। मुझे लगता है कि एआरएम एक अलग वैश्विक पृष्ठ तालिका का समर्थन करता है, जिसका संभवतः लिनक्स कर्नेल द्वारा उपयोग किया जाता है। पावर की हैश पेज तालिका मुख्य तालिका के लिए लिनक्स द्वारा उपयोग नहीं की जाती है; नई निर्देशिका प्रविष्टि कैशिंग प्रणाली लिनक्स के मुख्य तालिका प्रारूप के साथ फिट होती है। –

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