मैं देख सकता हूं कि आप भ्रमित क्यों हैं। आरेख थोड़ा भ्रामक है, और वास्तव में गलत हो सकता है।
सबसे पहले, आइए इस बारे में सोचें कि एक कर्नेल को पृष्ठों के स्तर के नीचे एक मेमोरी एलोकेटर की आवश्यकता क्यों है। यह शायद पहले से ही सामान है जो आप ज्यादातर जानते हैं, लेकिन मैं इसे पूर्णता के माध्यम से ले जाऊंगा।
पृष्ठ मेमोरी ऑपरेशन के विशिष्ट "यूनिट" हैं। जब कोई उपयोगकर्ता-स्पेस एप्लिकेशन मेमोरी आवंटित करता है, या मेमोरी-मैप्स फ़ाइल, या ऐसा कुछ करता है, तो यह आमतौर पर मशीन पेज आकार का एक मल्टीपल मिलता है। कुछ अपवाद उल्लेखनीय हैं; विंडोज 64k का उपयोग वर्चुअल मेमोरी आवंटन इकाई के रूप में करता है, चाहे सीपीयू का पृष्ठ आकार कोई भी हो। बहरहाल, इसे इस तरह समझते हैं।
एक आधुनिक सीपीयू पर, जहाँ तक उपयोगकर्ता-स्पेस कोड का सवाल है, इसमें एक फ्लैट एड्रेस स्पेस है। यह वास्तव में वर्चुअल मेमोरी सिस्टम द्वारा प्रदान किया गया एक भ्रम है। OS RAM में कहीं से भी पृष्ठ प्रदान करता है (या संभवत: RAM में स्वैप की गई मेमोरी या मेमोरी मैप्ड फ़ाइलों के मामले में) और उन्हें एक सन्निहित आभासी पता स्थान में मैप करता है।
इन सबके बीच यह है कि ऑपरेटिंग सिस्टम के लिए कुछ विशेष मामलों के अलावा (शायद DMA बफ़र्स, शायद कुछ विशेष डेटा संरचना बूट समय पर सेट हो, ओह और कर्नेल छवि ही), ऑपरेटिंग सिस्टम कर्नेल शायद कभी नहीं है किसी पेज से बड़े RAM के किसी भी ब्लॉक को प्रबंधित करें। यह चीजों को बहुत सरल करता है, क्योंकि इसका मतलब है कि जहां तक पृष्ठ चलते हैं, प्रत्येक आवंटन और डीलक्लाइजेशन समान आकार है। यह मैक्रो स्तर पर बाहरी विखंडन को भी प्रभावी ढंग से समाप्त करता है।
हालांकि, गुठली को अपने स्वयं के कुछ डेटा संरचनाओं को लागू करने की आवश्यकता होती है, और इसके लिए उन्हें एक अलग तरह के मेमोरी एलोकेटर की आवश्यकता होती है। इन डेटा संरचनाओं को आमतौर पर व्यक्तिगत वस्तुओं के संग्रह के रूप में माना जा सकता है (उदाहरण के लिए एक वस्तु "थ्रेड" या "म्यूटेक्स" हो सकती है)। इन वस्तुओं का आकार आम तौर पर एक पृष्ठ के आकार से बहुत छोटा होता है।
इसलिए, उदाहरण के लिए, एक वस्तु जो एक प्रक्रिया की सुरक्षा साख का प्रतिनिधित्व करती है (POSIX में उपयोगकर्ता आईडी और समूह आईडी के बारे में सोचें,) केवल 16 बाइट्स या ऐसा हो सकता है, जबकि "प्रक्रिया" या "थ्रेड" हो सकता है। आकार में 1kb। स्पष्ट रूप से आप इन छोटे रिकॉर्डों के लिए एक पूरे पृष्ठ का उपयोग नहीं करना चाहते हैं, इसलिए यह विचार पृष्ठों के शीर्ष पर एक आवंटनकर्ता को लागू करना है।
निम्न-स्तरीय आवंटन प्रणाली को पृष्ठ-स्तरीय आवंटनकर्ता के समान कई मुद्दों को पूरा करना पड़ता है: इसे यथोचित रूप से तेज़ करना होगा (जिसमें मल्टीकोर सिस्टम भी शामिल है), आप विखंडन को कम करना चाहते हैं, और इसी तरह। लेकिन इससे भी महत्वपूर्ण बात यह है कि यह किस प्रकार की डेटा संरचना आप स्टोर कर रहे हैं, इसके आधार पर इसे ट्यून करने योग्य और कॉन्फ़िगर किया जाना चाहिए।
कुछ डेटा संरचनाएं स्वाभाविक रूप से "कैश-लाइक" हैं। उदाहरण के लिए, कई ऑपरेटिंग सिस्टम डायरेक्टरी लुकअप की लंबी श्रृंखला (जिसे यूनिक्स-स्पीक में "नाम कैश" या "नेमी कैश" कहा जाता है) से बचने के लिए फाइल सिस्टम ऑब्जेक्ट के लिए पथ नामों का एक कैश बनाए रखता है। ये ऑब्जेक्ट केवल प्रदर्शन के लिए आवश्यक हैं, न कि शुद्धता के लिए, इसलिए आप (सिद्धांत रूप में) केवल प्रविष्टियों से भरा एक पूरा पृष्ठ भूल सकते हैं यदि मेमोरी तंग है और आपको पृष्ठ फ़्रेम को जल्दी से मुक्त करना होगा।
अन्य डेटा संरचनाओं को डिस्क पर स्वैप किया जा सकता है यदि मेमोरी तंग है और आपको जल्द ही उनकी आवश्यकता नहीं है। लेकिन आप डेटा संरचनाओं के साथ ऐसा नहीं करना चाहते हैं जो स्वैपिंग या वर्चुअल मेमोरी सिस्टम को नियंत्रित करते हैं!
कुछ डेटा संरचनाओं को बिना किसी दंड के स्मृति में इधर-उधर ले जाया जा सकता है (जैसे अगर कोई उन्हें पॉइंटर से संदर्भित नहीं करता है), तो ज़रूरत पड़ने पर विखंडन से बचने के लिए खुद को "कॉम्पैक्ट" कर सकता है।
तो स्लैब आवंटन का मुख्य विचार यह है कि एक पृष्ठ को केवल "प्रकार" के डेटा संरचनाओं को संग्रहीत करना चाहिए। यह सभी बक्से को टिक कर देता है: एक पृष्ठ में प्रत्येक वस्तु समान आकार है, इसलिए कोई बाहरी विखंडन नहीं है। समान "प्रकार" की वस्तुओं में समान प्रदर्शन आवश्यकताएं और समान शब्दार्थ हैं।
संयोग से, यह आवंटन के साथ एक समान कहानी है। कुछ प्रकार की वस्तु के लिए यह प्रतीक्षा करना ठीक है कि क्या उस वस्तु को आवंटित करने के लिए तुरंत कोई स्मृति उपलब्ध नहीं है। एक वस्तु जो एक खुली फ़ाइल का प्रतिनिधित्व करती है वह एक उदाहरण हो सकती है; एक फ़ाइल को खोलना सबसे अच्छा समय पर एक महंगा ऑपरेशन है, इसलिए थोड़ी देर इंतजार करने से इतना नुकसान नहीं होगा।
अन्य प्रकार की वस्तु के लिए (उदाहरण के लिए एक वस्तु जो एक वास्तविक समय की घटना का प्रतिनिधित्व करती है जो अब से एक निश्चित समय होनी चाहिए), आप वास्तव में इंतजार नहीं करना चाहते हैं। तो यह कुछ प्रकार के ऑब्जेक्ट के लिए ओवर-आबंटित करने के लिए समझ में आता है (कहते हैं, रिजर्व में कुछ मुक्त पृष्ठ हैं) ताकि अनुरोध को प्रतीक्षा के बिना संतुष्ट किया जा सके।
आप जो मूल रूप से कर रहे हैं वह प्रत्येक प्रकार की वस्तु को अपने स्वयं के आवंटनकर्ता के लिए अनुमति देता है, जिसे उस वस्तु की जरूरतों के लिए कॉन्फ़िगर किया जा सकता है। ये प्रति-ऑब्जेक्ट एलोकेटर भ्रमित करने वाले "कैश" कहलाते हैं। आप प्रत्येक प्रकार की वस्तु पर एक कैश आवंटित करते हैं। (हां, आप आमतौर पर "कैश ऑफ कैश" को लागू करेंगे।) प्रत्येक कैश केवल एक ही प्रकार की वस्तुओं (जैसे केवल थ्रेड संरचनाएं, या केवल स्थान संरचनाएं) को संग्रहीत करता है।
प्रत्येक कैश, बदले में, "स्लैब" का प्रबंधन करता है। एक स्लैब एक पृष्ठ फ़्रेम है जिसमें समान प्रकार की वस्तुओं की एक सरणी होती है। स्लैब "पूर्ण" (उपयोग में सभी वस्तुएं), "खाली" (उपयोग में कोई वस्तु नहीं), या "आंशिक" (उपयोग में कुछ वस्तुएं) हो सकते हैं।
आंशिक स्लैब संभवतः सबसे दिलचस्प हैं, क्योंकि स्लैब आवंटन हर आंशिक स्लैब के लिए एक निशुल्क सूची रखता है। (पूर्ण स्लैब और खाली स्लैब के लिए कोई मुफ्त सूची की आवश्यकता नहीं है।) वस्तुओं को पहले आंशिक स्लैब से आवंटित किया जाता है (और शायद "सबसे पूर्ण" आंशिक स्लैब पहले) उन पृष्ठों को आवंटित करने से बचने की कोशिश करने के लिए जिन्हें ज़रूरत नहीं है।
स्लैब आवंटन के बारे में अच्छी बात यह है कि ये सभी आवंटन नीति विकल्प (साथ ही मेमोरी शब्दार्थ) को प्रत्येक प्रकार की वस्तु के लिए ट्यून किया जा सकता है। कुछ कैश खाली स्लैब के पूल को बनाए रख सकते हैं और कुछ को नहीं। कुछ को माध्यमिक भंडारण में स्वैप किया जा सकता है और कुछ नहीं हो सकता है।
लिनक्स में तीन अलग-अलग प्रकार के स्लैब एलोकेटर हैं, जो इस बात पर निर्भर करता है कि आपको कॉम्पैक्टनेस, कैश-फ्रेंडली या कच्ची गति की आवश्यकता है या नहीं। था यह कुछ साल पहले पर एक अच्छी प्रस्तुति जो समझौतों से अच्छी तरह से बताते हैं।
सोलारिस स्लैब आवंटन ( विवरण के लिए कागज देखें ) और भी अधिक प्रदर्शन निचोड़ने के लिए कुछ और विवरण हैं। एक शुरुआत के लिए, सोलारिस में, सब कुछ स्लैब आवंटन के साथ किया जाता है, जिसमें पेज फ्रेम आवंटन भी शामिल है। (यह उन वस्तुओं को आवंटित करने के लिए सोलारिस का समाधान है जो आकार में आधे पृष्ठ से बड़े हैं।) यह स्लैब-आवंटित स्थान में स्लैब आवंटनकर्ताओं को घोंसले द्वारा छोटी वस्तुओं का प्रबंधन करता है।
सोलारिस में कुछ वस्तुओं को जटिल और महंगे निर्माण और विनाश की आवश्यकता होती है (जैसे कि जिन वस्तुओं में कर्नेल लॉक होता है), और इसलिए वे "आंशिक रूप से मुक्त" हो सकते हैं (अर्थात निर्माण किए गए लेकिन आवंटित नहीं)। सोलारिस प्रति-सीपीयू आधार पर मुफ्त सूचियों को बनाए रखने के द्वारा मुक्त स्लैब आवंटन का भी अनुकूलन करता है, यह सुनिश्चित करता है कि कुछ संचालन पूरी तरह से प्रतीक्षा-मुक्त हैं।
सामान्य-उद्देश्य आवंटन (उदाहरण के लिए, जिसका आकार संकलन-समय पर ज्ञात नहीं है) का समर्थन करने के लिए, अधिकांश मैक्रोकर्नल-प्रकार के ऑपरेटिंग सिस्टम में भी कैश होते हैं जो ऑब्जेक्ट प्रकारों के बजाय ऑब्जेक्ट आकार का प्रतिनिधित्व करते हैं । FreeBSD, उदाहरण के लिए, अज्ञात वस्तुओं के लिए कैश बनाए रखता है जिनके आकार 2 बाइट्स की शक्तियां हैं, 4 से 256 तक।
मुझे आशा है कि आप देख सकते हैं कि स्लैब आवंटन एक बहुत ही लचीला ढांचा है जिसे विभिन्न प्रकार के डेटा की जरूरतों के लिए तैयार किया जा सकता है। यह पेजिंग के साथ प्रतिस्पर्धा नहीं करता है, लेकिन इसे पूरक करता है (हालांकि सोलारिस में, पृष्ठ फ़्रेम स्लैब के साथ आवंटित किए गए हैं)।
आशा है कि ये आपकी मदद करेगा। अगर कुछ स्पष्टीकरण की जरूरत है तो मुझे बताएं।
