আমি দেখতে পাচ্ছি আপনি কেন বিভ্রান্ত? চিত্রটি কিছুটা বিভ্রান্তিকর এবং প্রকৃতপক্ষে ভুল হতে পারে।
প্রথমে, কার্নেলের পৃষ্ঠাগুলির স্তরের নীচে মেমরি বরাদ্দকারী কেন প্রয়োজন তা নিয়ে ভাবা যাক। এটি সম্ভবত আপনি ইতিমধ্যে জানেন যে স্টাফ, কিন্তু আমি সম্পূর্ণতার জন্য এটি মাধ্যমে যাব।
পৃষ্ঠাগুলি মেমরি অপারেশনের সাধারণ "ইউনিট"। যখন কোনও ব্যবহারকারী-স্থান অ্যাপ্লিকেশন মেমরি বরাদ্দ করে, বা মেমরি-কোনও ফাইল বা এর মতো কিছু ম্যাপ করে, এটি সাধারণত মেশিন পৃষ্ঠা আকারের একাধিক পায়। উল্লেখযোগ্য কিছু ব্যতিক্রম আছে; উইন্ডোজ ভার্চুয়াল মেমরি বরাদ্দকরণ ইউনিট হিসাবে 64k ব্যবহার করে সিপিইউয়ের পৃষ্ঠার আকার যাই হোক না কেন। যাইহোক, আসুন এটি এইভাবে মনে করি।
একটি আধুনিক সিপিইউতে, ইউজার-স্পেস কোড হিসাবে, এটিতে একটি সমতল ঠিকানা স্থান রয়েছে। এটি প্রকৃতপক্ষে ভার্চুয়াল মেমরি সিস্টেম দ্বারা প্রদত্ত একটি বিভ্রম। ওএস র্যামের যে কোনও জায়গা থেকে পৃষ্ঠাগুলি সরবরাহ করে (বা সম্ভবত র্যামে নয়, অদলবদল মেমরি বা মেমরি-ম্যাপযুক্ত ফাইলগুলির ক্ষেত্রে) এবং এগুলি একটি নিখুঁত ভার্চুয়াল ঠিকানার জায়গাতে মানচিত্র করে।
এই সমস্ত বিষয় হ'ল অপারেটিং সিস্টেমের জন্য কয়েকটি বিশেষ কেস বাদে (সম্ভবত ডিএমএ বাফারস, সম্ভবত বুটের সময় কিছু বিশেষ ডেটা স্ট্রাকচার সেট করা হয়েছে, ওহ এবং কার্নেলের চিত্র নিজেই) অপারেটিং সিস্টেমের কার্নেলটি সম্ভবত কখনও করতে হয় নি পৃষ্ঠার চেয়ে বড় কোনও র্যামের ব্লক পরিচালনা করুন। এটি জিনিসগুলিকে প্রচুর পরিমাণে সরল করে, কারণ এর অর্থ হল পৃষ্ঠা যতদূর যায়, প্রতিটি বরাদ্দ এবং ক্ষয়ক্ষতি একই আকার। এটি কার্যকরভাবে ম্যাক্রো স্তরের বাহ্যিক খণ্ডনকেও দূর করে।
তবে, কার্নেলগুলি তাদের নিজস্ব কিছু ডেটা স্ট্রাকচার প্রয়োগ করতে হবে এবং তার জন্য তাদের বিভিন্ন ধরণের মেমরি বরাদ্দকরণকারী প্রয়োজন। এই ডেটা স্ট্রাকচারগুলি সাধারণত স্বতন্ত্র বস্তুর সংগ্রহ হিসাবে ভাবা যেতে পারে (উদাহরণস্বরূপ কোনও বস্তু একটি "থ্রেড" বা "মিটেক্স" হতে পারে)। এই অবজেক্টগুলির আকার সাধারণত আকারের পৃষ্ঠার চেয়ে অনেক ছোট।
সুতরাং, উদাহরণস্বরূপ, এমন কোনও বস্তু যা কোনও প্রক্রিয়াটির সুরক্ষার শংসাপত্রগুলি উপস্থাপন করে (পসিক্সের ব্যবহারকারী আইডি এবং গ্রুপ আইডির কথা ভাবেন, বলুন) কেবলমাত্র 16 বাইট বা তার বেশি হতে পারে, যেখানে একটি "প্রক্রিয়া" বা "থ্রেড" অবধি থাকতে পারে আকারে 1 কেবি। স্পষ্টতই আপনি এই ছোট রেকর্ডগুলির জন্য একটি পুরো পৃষ্ঠা ব্যবহার করতে চান না, তাই পৃষ্ঠাগুলির শীর্ষে একটি বরাদ্দকারীকে বাস্তবায়ন করার ধারণা।
নিম্ন-স্তরের বরাদ্দ সিস্টেমকে পৃষ্ঠা-স্তরের বরাদ্দকারীর মতো একই সমস্যাগুলির অনেকগুলি সন্তুষ্ট করতে হবে: এটি যুক্তিসঙ্গতভাবে দ্রুত হতে হবে (মাল্টিকোর সিস্টেমগুলি সহ), আপনি খণ্ডকে ছোট করতে চান, ইত্যাদি। তবে আরও বড় কথা, আপনি কোন ধরণের ডেটা স্ট্রাকচার সংরক্ষণ করছেন তার উপর নির্ভর করে এটি টিউনেবল এবং কনফিগারযোগ্য হওয়া উচিত।
কিছু ডেটা স্ট্রাকচার অন্তর্নিহিতভাবে "ক্যাশে-জাতীয়"। উদাহরণস্বরূপ, অনেক অপারেটিং সিস্টেম ডিরেক্টরি অনুসন্ধানের দীর্ঘ চেইনগুলি এড়ানোর জন্য ফাইল সিস্টেমের অবজেক্টগুলিতে পথের নামের একটি ক্যাশে বজায় রাখে (ইউনিক্স-স্পোকে "নাম ক্যাশে" বা "নামি ক্যাশে" বলে)। এই অবজেক্টগুলি কেবল পারফরম্যান্সের জন্য প্রয়োজন, সঠিকতা নয়, তাই আপনি (তত্ত্বের ভিত্তিতে) মেমরি শক্ত থাকলে এবং আপনাকে একটি পৃষ্ঠা ফ্রেম দ্রুত খালি করা প্রয়োজন যদি আপনি কেবলমাত্র প্রবেশের পূর্ণ একটি পৃষ্ঠা ভুলে যেতে পারেন।
স্মৃতি শক্ত থাকলে এবং শীঘ্রই আপনার এগুলির প্রয়োজন না হলে অন্যান্য ডেটা স্ট্রাকচারগুলি ডিস্কে সরিয়ে নেওয়া যেতে পারে। তবে আপনি এমন কোনও ডেটা স্ট্রাকচারের সাথে এটি করতে চান না যা স্ব্যাপিং বা ভার্চুয়াল মেমরি সিস্টেম নিয়ন্ত্রণ করে!
কিছু ডেটা স্ট্রাকচার মেমরিতে কোনও জরিমানা ছাড়াই চারপাশে স্থানান্তরিত হতে পারে (উদাহরণস্বরূপ যদি কেউ তাদেরকে পয়েন্টার হিসাবে উল্লেখ করে না), তাই প্রয়োজনে খণ্ডন এড়ানোর জন্য তারা নিজেরাই "কমপ্যাক্ট" করতে পারে।
সুতরাং স্ল্যাব বরাদ্দকারীটির মূল ধারণাটি হ'ল কোনও পৃষ্ঠায় কেবল একই "টাইপ" এর ডেটা স্ট্রাকচার সংরক্ষণ করা উচিত। এটি সমস্ত বাক্সে টিক দেয়: একটি পৃষ্ঠার প্রতিটি বস্তু একই আকারের, তাই কোনও বাহ্যিক বিভাজন নেই। একই "ধরণের" অবজেক্টগুলির একই কার্য সম্পাদনের প্রয়োজনীয়তা এবং একই শব্দার্থকতা রয়েছে।
ঘটনাচক্রে, এটি বরাদ্দ সহ একটি অনুরূপ গল্প। কিছু ধরণের অবজেক্টের জন্য অপেক্ষা করা ঠিক আছে ঠিক আছে যদি সেই অবজেক্টটি বরাদ্দ করার জন্য অবিলম্বে কোনও স্মৃতি উপলব্ধ না থাকে। একটি উন্মুক্ত ফাইল উপস্থাপন করে এমন একটি বস্তুর একটি উদাহরণ হতে পারে; একটি ফাইল খোলাই সেরা সময়ের মধ্যে ব্যয়বহুল ক্রিয়াকলাপ, তাই আরও কিছুক্ষণ অপেক্ষা করা এতটা ক্ষতি করে না।
অন্যান্য ধরণের অবজেক্টের জন্য (উদাহরণস্বরূপ এমন কোনও বস্তু যা রিয়েল-টাইম ইভেন্টের প্রতিনিধিত্ব করে যা এখন থেকে একটি নির্দিষ্ট সময় অবশ্যই ঘটবে), আপনি সত্যিই অপেক্ষা করতে চান না। সুতরাং কিছু ধরণের অবজেক্টকে অতিরিক্ত বরাদ্দ দেওয়ার জন্য এটি অর্থবোধ করে (বলে রাখুন, রিজার্ভে কয়েকটি বিনামূল্যে পৃষ্ঠা রয়েছে) যাতে অনুরোধগুলি অপেক্ষা না করেই সন্তুষ্ট হতে পারে।
আপনি মূলত যা করছেন তা হ'ল প্রতিটি ধরণের অবজেক্টের নিজস্ব বরাদ্দক রয়েছে যা সেই বস্তুর প্রয়োজনের জন্য কনফিগার করা যেতে পারে। এই প্রতি-বস্তু বরাদ্দকারীদের বিভ্রান্তিকরভাবে "ক্যাশে" বলা হয়। আপনি প্রতিটি ধরণের অবজেক্টে একটি ক্যাশে বরাদ্দ করেন। (হ্যাঁ, আপনি সাধারণত "ক্যাশেগুলির ক্যাশে" প্রয়োগও করতে পারেন)) প্রতিটি ক্যাশে কেবলমাত্র একই ধরণের জিনিসগুলি সঞ্চয় করে (যেমন কেবল থ্রেড স্ট্রাকচার, বা কেবলমাত্র স্থানের কাঠামোগত ঠিকানা)।
প্রতিটি ক্যাশে, ঘুরে, "স্ল্যাব" পরিচালনা করে। একটি স্ল্যাব একটি পৃষ্ঠার ফ্রেম যা একই ধরণের অবজেক্টের অ্যারে ধারণ করে। স্ল্যাবগুলি "পূর্ণ" (ব্যবহৃত সমস্ত অবজেক্ট), "খালি" (কোনও অবজেক্ট ব্যবহারযোগ্য নয়) বা "আংশিক" (কিছু বস্তু ব্যবহৃত হতে পারে) হতে পারে।
আংশিক স্ল্যাব সম্ভবত সবচেয়ে আকর্ষণীয়, যেহেতু স্ল্যাব বরাদ্দকারী প্রতিটি আংশিক স্ল্যাবের জন্য একটি বিনামূল্যে তালিকা বজায় রাখে। (পূর্ণ স্ল্যাব এবং খালি স্ল্যাবগুলির কোনও নিখরচায় তালিকা দরকার নেই)) প্রয়োজনীয় পৃষ্ঠাগুলি বরাদ্দ এড়াতে চেষ্টা করার জন্য প্রথমে আংশিক স্ল্যাবগুলি থেকে (এবং সম্ভবত "সবচেয়ে পূর্ণ" আংশিক স্ল্যাব থেকে) বরাদ্দ করা হয়।
স্ল্যাব বরাদ্দ সম্পর্কে দুর্দান্ত জিনিস হ'ল এই বরাদ্দ নীতি বিকল্পগুলি (সেইসাথে মেমরি শব্দার্থক) প্রতিটি ধরণের অবজেক্টের জন্য টিউন করা যেতে পারে। কিছু ক্যাশে খালি স্ল্যাবগুলির একটি পুল ধরে রাখতে পারে এবং কিছুগুলি নাও পারে। কিছু সম্ভবত দ্বিতীয় স্টোরেজ এ অদলবদল করতে সক্ষম হতে পারে এবং কিছু নাও পারে।
আপনার কমপ্যাক্টনেস, ক্যাশে-ফ্রেন্ডলিটি বা কাঁচা গতির প্রয়োজন হবে না তার উপর নির্ভর করে লিনাক্সের তিনটি ধরণের স্ল্যাব বরাদ্দ রয়েছে। কয়েক বছর আগে এটি সম্পর্কে একটি ভাল উপস্থাপনা ছিল যা ট্রেড অফগুলি ভালভাবে ব্যাখ্যা করে।
সোলারিস স্ল্যাব বরাদ্দকারী (বিশদটির জন্য কাগজটি দেখুন ) আরও বেশি কার্যকারিতা নিবারণের জন্য আরও কয়েকটি বিশদ রয়েছে। শুরু করার জন্য, সোলারিসে, সমস্ত কিছু পৃষ্ঠা ফ্রেম বরাদ্দ সহ স্ল্যাব বরাদ্দ দিয়ে সম্পন্ন হয়। (এটি আকারের অর্ধ পৃষ্ঠার চেয়ে বড় অবজেক্টগুলির বরাদ্দের জন্য সোলারিসের সমাধান)) এটি স্ল্যাব-বরাদ্দ স্থানে স্ল্যাব বরাদ্দকারীদের বাসা বেঁধে ছোট ছোট বস্তুগুলি পরিচালনা করে।
সোলারিসের কিছু বস্তুর জন্য জটিল এবং ব্যয়বহুল নির্মাণ এবং ধ্বংসের প্রয়োজন হয় (উদাঃ বস্তুগুলিতে যার মধ্যে কার্নেলের লক থাকে), এবং সুতরাং তারা "আংশিক মুক্ত" (যেমন নির্মিত তবে বরাদ্দ নয়) হতে পারে। সোলারিস প্রতি-সিপিইউ ভিত্তিতে ফ্রি তালিকা বজায় রেখে ফ্রি স্ল্যাব বরাদ্দকেও অনুকূলিত করে, কিছু অপারেশন পুরোপুরি অপেক্ষা-মুক্ত থাকে তা নিশ্চিত করে।
সাধারণ বরাদ্দ সমর্থন করার জন্য (যেমন অ্যারে যার আকার কম্পাইল-সময়ে জানা যায় না জন্য), সবচেয়ে macrokernel-টাইপ অপারেটিং সিস্টেম এছাড়াও ক্যাশে যা প্রতিনিধিত্ব বস্তু আছে মাপ বরং বস্তুর চেয়ে ধরনের । উদাহরণস্বরূপ, ফ্রিবিএসডি অজানা বস্তুর জন্য ক্যাচগুলি বজায় রাখে যার আকার 2 বাইটের 4 থেকে 256 পর্যন্ত।
আমি আশা করি আপনি যেটি দেখতে পাচ্ছেন তা হ'ল স্ল্যাব বরাদ্দকরণ একটি খুব নমনীয় কাঠামো যা বিভিন্ন ধরণের ডেটার প্রয়োজনের জন্য সুর করা যেতে পারে। এটি পেজিংয়ের সাথে প্রতিযোগিতা করে না, তবে এটি পরিপূরক করে (যদিও সোলারিসে পৃষ্ঠা ফ্রেমগুলি স্ল্যাব দিয়ে বরাদ্দ করা হয়)।
আশা করি এটা কাজে লাগবে. কোনও কিছুর স্পষ্টতা দরকার থাকলে আমাকে জানান।
