حافظه مجازی: دادن یک فضای آدرس خصوصی به هر برنامه

برنامه‌ها طوری رفتار می‌کنند که گویی به یک بلوک بزرگ و خصوصی از حافظه دسترسی دارند، حتی اگر RAM فیزیکی محدود و بین بسیاری از فرآیندهای در حال اجرا مشترک باشد. این مقاله توضیح می‌دهد حافظه مجازی چگونه این توهم را از طریق ترجمه آدرس ایجاد می‌کند، جدول‌های صفحه و TLB چگونه ترجمه را سریع می‌کنند، و وقتی داده مورد نیاز در حال حاضر در حافظه فیزیکی نباشد چه اتفاقی می‌افتد.

حافظه مجازیجدول‌های صفحهبافر جانبی ترجمه

~4 دقیقه مطالعه · آخرین به‌روزرسانی ۱۵ شهریور ۱۴۰۵

توهمی که حافظه مجازی فراهم می‌کند

هر برنامه در حال اجرا طوری رفتار می‌کند که گویی یک بلوک بزرگ، خصوصی، و پیوسته از حافظه از آدرس صفر دارد، کاملاً بی‌خبر از برنامه‌های دیگری که هم‌زمان اجرا می‌شوند یا از اینکه ماشین واقعاً چقدر حافظه فیزیکی دارد. این توهم توسط Virtual Memory ایجاد می‌شود، مکانیزمی که آدرس‌هایی که یک برنامه استفاده می‌کند را از مکان‌های واقعی حافظه فیزیکی که داده در آن‌ها ذخیره می‌شود جدا می‌کند.

دو نوع آدرس

یک برنامه منحصراً با Virtual Addresses کار می‌کند، در حالی که حافظه سخت‌افزاری واقعی توسط Physical Addresses سازمان‌دهی می‌شود. هر دسترسی حافظه‌ای که یک برنامه انجام می‌دهد باید از یک آدرس مجازی به آدرس فیزیکی متناظر ترجمه شود پیش از اینکه سخت‌افزار واقعی بتواند داده را بازیابی یا ذخیره کند.

صفحات: واحد ترجمه

به‌جای ترجمه بایت‌های تکی یکی‌یکی، حافظه به قطعات با اندازه ثابت به نام Pages تقسیم می‌شود. هر صفحه مجازی به یک Frame فیزیکی با همان اندازه نگاشت می‌شود، و این نگاشت در یک ساختار داده به نام Page Table ثبت می‌شود، که توسط سیستم‌عامل نگهداری می‌شود.

آدرس مجازی:
[ شماره صفحه مجازی | آفست صفحه ]

جستجوی جدول صفحه:
شماره صفحه مجازی → شماره فریم فیزیکی

آدرس فیزیکی:
[ شماره فریم فیزیکی | آفست صفحه ]

چرا ترجمه باید سریع باشد

از آنجا که هر دسترسی حافظه‌ای واحد به یک ترجمه نیاز دارد، مراجعه به جدول صفحه کامل در حافظه اصلی برای هر دسترسی بسیار کند خواهد بود. برای حل این مسئله، سخت‌افزار یک کش کوچک و تخصصی به نام TLB (Translation Lookaside Buffer) شامل می‌شود، که ترجمه‌های مجازی-به-فیزیکی اخیراً استفاده‌شده را مستقیماً ذخیره می‌کند، مشابه از نظر روحی با اصول کشینگ که پیش‌تر در این مجموعه بحث شد. یک TLB hit اجازه می‌دهد ترجمه تقریباً بلافاصله رخ دهد، در حالی که یک TLB miss نیازمند مراجعه به جدول صفحه کامل است، که به‌طور قابل‌توجهی کندتر است.

وقتی داده در حافظه فیزیکی نیست چه اتفاقی می‌افتد

از آنجا که حافظه مجازی اجازه می‌دهد یک برنامه طوری رفتار کند که گویی حافظه بیشتری از آنچه فیزیکاً نصب شده دارد، برخی صفحات مجازی ممکن است در حال حاضر اصلاً در حافظه فیزیکی حضور نداشته باشند، و در عوض روی دیسک ذخیره شده باشند. وقتی یک برنامه به چنین صفحه‌ای دسترسی پیدا می‌کند، یک Page Fault رخ می‌دهد: سیستم‌عامل برنامه را متوقف می‌کند، صفحه مورد نیاز را از دیسک بازیابی می‌کند، آن را در حافظه فیزیکی قرار می‌دهد، جدول صفحه را بر همین اساس به‌روزرسانی می‌کند، و سپس اجرای برنامه را طوری از سر می‌گیرد که گویی هیچ اتفاق غیرمعمولی رخ نداده است.

چرا حافظه مجازی همچنین حفاظت فراهم می‌کند

فراتر از فعال کردن برنامه‌ها برای استفاده از حافظه بیشتری نسبت به آنچه فیزیکاً موجود است، حافظه مجازی یک بهره حفاظتی حیاتی فراهم می‌کند: از آنجا که هر برنامه فقط دید به فضای آدرس مجازی خودش دارد، نمی‌تواند مستقیماً حافظه متعلق به یک برنامه دیگر در حال اجرا را بخواند یا خراب کند، چون سیستم‌عامل جدول صفحه هر برنامه را کنترل می‌کند و صرفاً هرگز آدرس‌های آن را روی حافظه فیزیکی برنامه دیگری نگاشت نمی‌کند.

چرا این مکانیزم برای محاسبات مدرن ضروری است

بدون حافظه مجازی، اجرای امن و هم‌زمان چند برنامه مستقل نیازمند مدیریت حافظه دستی بسیار دقیق‌تر و شکننده‌تری خواهد بود، و برنامه‌ها باید دقیقاً می‌دانستند ماشین چقدر حافظه فیزیکی دارد و برنامه‌های دیگر کجا قرار دارند — سطحی از پیچیدگی که حافظه مجازی به‌طور کامل پنهان می‌کند، و اجازه می‌دهد نرم‌افزار بسیار ساده‌تر و امن‌تر نوشته شود.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

تصورات غلط رایج درباره محاسبات موازی و درس‌های نهایی کتاب

پس از پوشش هر چیزی از موازی‌سازی سطح رشته تا محاسبات در مقیاس انبار، ارزش دارد تصورات غلط پایداری درباره سیستم‌های موازی که حتی مهندسان باتجربه هم گاهی به آن‌ها دارند را اصلاح کنیم. این مقاله به مغالطات رایج درباره مقیاس‌پذیری و سخت‌افزار موازی می‌پردازد، سپس فصل پردازش موازی را با پیوند دادن مسیر کامل از یک دستور منفرد تا یک ساختمان پر از ماشین‌های همکار به پایان می‌رساند.

ادامه

واقعیت‌های عملی: بنچمارک CPU در مقابل GPU و ضرب ماتریس چندپردازنده‌ای

مقایسه منصفانه یک CPU و یک GPU نیازمند مدلی است که هم توان عملیاتی محاسباتی و هم محدودیت‌های پهنای باند حافظه را با هم در نظر بگیرد. این مقاله مدل roofline مورد استفاده برای مقایسه سخت‌افزار واقعی مانند Intel Core i7 و NVIDIA Tesla GPU را معرفی می‌کند، سپس نشان می‌دهد ضرب ماتریس چگونه در سراسر چند پردازنده تسریع می‌شود، به‌عنوان کاربرد عملی نهایی مفاهیم موازی این فصل.

ادامه

بنچمارک کردن چندپردازنده‌ها و مدل‌سازی کارایی موازی

سنجش کارایی یک سیستم موازی نیازمند ابزارها و سنجه‌های متفاوتی نسبت به سنجش یک پردازنده تک‌هسته‌ای است. این مقاله بنچمارک‌های تخصصی مورد استفاده برای ارزیابی سیستم‌های چندپردازنده را پوشش می‌دهد، توضیح می‌دهد چگونه رفتار مقیاس‌پذیری را با افزودن پردازنده‌های بیشتر مدل‌سازی کنیم، و قانون آمدال را در زمینه سنجش کارایی دنیای واقعی بازبینی می‌کند.

ادامه

شبکه‌سازی کلاستر: ارتباط با دنیای بیرون

یک کلاستر از ماشین‌ها فقط زمانی مفید است که بتواند به‌طور کارآمد هم داخلی و هم با دنیای بیرون ارتباط برقرار کند. این مقاله لایه‌های شبکه‌سازی درگیر در ارتباط کلاستر، مبادلات بین تأخیر و پهنای باند در مقیاس، و اینکه کلاسترها چگونه به شبکه‌های خارجی و کاربران متصل می‌شوند را پوشش می‌دهد.

ادامه

کلاسترها، کامپیوترهای در مقیاس انبار، و توپولوژی‌های شبکه

فراتر از یک تراشه واحد، موازی‌سازی به کل ساختمان‌های پر از کامپیوترهای مستقلی که با هم کار می‌کنند گسترش می‌یابد. این مقاله گذار از چندپردازنده‌سازی حافظه مشترک به کلاسترهایی از ماشین‌های جداگانه را توضیح می‌دهد، مفهوم محاسبات در مقیاس انبار را معرفی می‌کند، و توپولوژی‌های شبکه که این ماشین‌های مستقل را به‌طور کارآمد متصل می‌کنند را پوشش می‌دهد.

ادامه

مقدمه‌ای بر GPU: موازی‌سازی عظیم برای بارهای کاری سنگین از نظر داده

یک GPU ایده SIMD که پیش‌تر در این مجموعه پوشش داده شد را به یک مقیاس افراطی می‌برد، و هزاران رشته سبک را به‌طور هم‌زمان اجرا می‌کند تا حجم عظیمی از داده مستقل را پردازش کند. این مقاله توضیح می‌دهد چرا GPU ها از نظر معماری این‌قدر با CPU متفاوت‌اند، مدل اجرای رشته آن‌ها چگونه کار می‌کند، و چه نوع بارهای کاری بیشترین بهره را از این طراحی می‌برند.

ادامه