تحديد حجم جدول الصفحة للذاكرة الافتراضية

Question

ضع في اعتبارك نظام ذاكرة افتراضية مع عنوان بايت افتراضي 38 بت ، صفحات 1 كيلو بايت و 512 ميغابايت من الذاكرة الفعلية. ما هو الحجم الإجمالي لجدول الصفحة لكل عملية على هذا الجهاز ، على افتراض أن البتات الصالحة والحماية والقذرة والاستخدام تأخذ ما مجموعه 4 بت ، وأن جميع الصفحات الافتراضية قيد الاستخدام؟ (افترض أن عناوين القرص لا يتم تخزينها في جدول الصفحة.)

Answer 1

حسنًا ، إذا كان السؤال هو ببساطة "ما هو حجم جدول الصفحة؟" بغض النظر عما إذا كانت ستناسب الذاكرة الفعلية ، يمكن حساب الإجابة هكذا:

الذاكرة الفعلية الأولى. هناك 512 كيلو بير من الذاكرة الفعلية (512 م / 1K). هذا يتطلب 19 بت لتمثيل كل صفحة. أضف ذلك إلى 4 بتات من المعلومات المحاسبية وستحصل على 23 بت.

الآن الذاكرة الافتراضية. مع مساحة عنوان 38 بت وحجم صفحة 10 بت (1K) ، تحتاج إلى 2²⁸ إدخالات في جدول صفحتك.

لذلك 2²⁸ إدخالات جدول الصفحة عند 23 بت لكل منها 6،174،015،488 بت أو 736 متر.

هذا هو الحد الأقصى للحجم اللازم لنظام فرعي VM على مستوى واحد لكل عملية.

من الواضح الآن أن هذا لن يعمل إذا كان لديك 512 مترًا فقط من ذاكرة الوصول العشوائي المادية ، لذا لديك خياران.

1. يمكنك تقليل عدد الصفحات المادية. على سبيل المثال ، السماح لنصف الذاكرة فقط أن يخضعوا للترحيل ، مع الحفاظ على النصف الآخر المقيم في جميع الأوقات. سيؤدي هذا إلى توفير بت واحد لكل إدخال ، وليس بما يكفي لإحداث فرق.

2. زيادة حجم الصفحة ، اذا كان ممكنا. صفحة 1K على مساحة عنوان 38 بت هي سبب لجداول الصفحة المكتنزة للغاية. على سبيل المثال ، أعتقد أن '386 ، مع مساحة عنوان 32 بت ، يستخدم صفحات 4K. قد يؤدي ذلك إلى إدخالات جدول صفحات مليون صفحة ، أقل بكثير من 260 مليون المطلوب هنا.

3. اذهب متعددة المستويات. أكثر تقدمًا قليلاً ولكن هذا يعني أساسًا أن جداول الصفحة نفسها تخضع للترحيل. يجب عليك الاحتفاظ بالمستوى الأول من جداول الصفحة المقيمة في الذاكرة المادية ولكن يمكن أن يدخل المستوى الثاني والخروج حسب الحاجة. سيؤدي ذلك إلى تقليل المتطلبات المادية بشكل كبير ولكن بتكلفة السرعة ، نظرًا لأن مستويين من أخطاء الصفحات قد يحدثان في صفحة عملية فعلية (واحدة لجداول الترحيل الثانوية ثم واحدة لصفحة العملية).

---

دعونا ننظر أقرب قليلاً إلى الخيار 3.

إذا سمحنا 32 مترًا بجدول الترحيل الأساسي وإعطاء كل إدخال 4 بايت (32 بت: هناك حاجة إلى 23 فقط ولكن يمكننا أن نتجاوز الكفاءة هنا) ، وهذا سيسمح 8،388،608 صفحة لجدول الصفحة الثانوية.

نظرًا لأن كل صفحات من صفحات الجدول الثانوية هذه تبلغ 1 كيلو (مما يتيح لنا تخزين 256 إدخالات جدول الصفحة الثانوية في 4 بايت لكل منها) ، يمكننا معالجة ما مجموعه 2،147،483،648 صفحة افتراضية.

هذا من شأنه أن يسمح 8،192 محملة بالكامل (أي ، باستخدام مساحة العنوان المكونة من 28 بت بأكملها) لتشغيل جنبًا إلى جنب ، على افتراض أن لديك جزءًا لا بأس به من مساحة القرص لتخزين الصفحات غير المقيمة.

من الواضح الآن أن جدول الترحيل الأساسي (والنظام الفرعي VM ، وربما جزء كبير من بقية نظام التشغيل) يجب أن يظل مقيمًا في جميع الأوقات. لا يمكن السماح لك بتصوير إحدى الصفحات الأساسية لأنك قد تحتاج إلى هذه الصفحة من أجل إعادتها إلى :-)

ولكن هذه تكلفة مقيمة تبلغ 32 مترًا فقط من 512 متر لجدول الترحيل الأساسي ، أفضل بكثير من (على الأقل ، لعملية واحدة محملة بالكامل) من 736 متر.

Answer 2

حجم جدول الصفحة = إجمالي إدخالات جدول الصفحة*حجم إدخال جدول الصفحة

الخطوة 1: العثور على عدد الإدخالات في جدول الصفحة:

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

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

لذلك هناك 2^28 إدخالات في جدول الصفحة

Step2: لا إطارات في الذاكرة الفعلية:

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

Answer 3

1 كيلو بايت صفحات = 2^10 ، 512MB = 2^29 => إزاحة = 29 - 10 = 19 بت.

يتضمن الظاهري جزءين: إطار الصفحة + الإزاحة => إطار الصفحة + بت القذرة = 38 - 19 = 29 بت. يتضمن 29 بت 4 بت قذرة (أعلاه) => 25 بت لإطار الصفحة الحقيقي ، كل إطار صفحة يبلغ طوله 10 بت.

لذلك ، حجم جدول الصفحة: 2^25 * 10 = 320m.

أتمنى أن يكون هذا صحيحًا.