پردازنده کامپیوتر ( CPU ) بخشی داره به اسم" واحد کنترل کننده حافظه" ( MMU ) ، این بخش اضافه شده تا دسترسی به حافظه انعطاف پذیری بیشتری برای CPU داشته باشه. چجوری؟ ! زمانی که CPU داره یک برنامه رو پردازش میکنه، اون نرم افزار قاعدتا یک سری دیتا داخل حافظه ریخته یا قراره بریزه یا بخونه و کارای از این قبیل، آدرسی هایی که برای حافظه هستن و نرم افزار با اونا سر و کار داره یه سری آدرس های مجازی اند یعنی آدرس دقیق روی حافظه نیستن! این آدرس ها به کار CPU نمیاد، پس یه واحدی این وسط قرار دادن به اسم MMU که کارش اینه که بره و آدرس های واقعی رو پیدا کنه به CPU اطلاع بده، یه جورایی کارش ترجمه هست، ترجمه آدرس مجازی به واقعی. البته بعضی وقتا یک سری آدرس ها قراره دوباره توسط همون برنامه یا برنامه های دیگه استفاده بشن اینجا MMU دیگه نمیره از حافظه بخونه و بده به CPU ، چون قبلا یک بار اون آدرس واقعی پیدا شده و به اصطلاح Cache شده، میره و از همون Cache آدرس رو پیدا میکنه و میده به CPU . خب حالا MMU آدرس های واقعی رو چجوری پیدا میکنه؟ ! اون از یه جدولی استفاده میکنه به اسم page table که داخلش نوشته شده کدوم آدرس مجازی ماله کدوم آدرس واقعی هست. این جدول توسط kernel ساخته و نگهداری میشه، چون kernel به عنوان رابط بین نرم افزار های دیگه و سخت افزار، رابطه مستقیمی با برنامه هایی که اجرا شدن داره پس آدرس های مجازی که اونا وارد کردن رو میگیره و با آدرس واقعیشون توی اون جدول میریزه تا MMU بتونه استفاده کنه. پروسس ها و برنامه هایی که اجرا شدن کل آدرس های حافظه رو همون اول شروع کارشون و بلافاصله نمیخوان، kernel به طور کلی فقط زمانی page table رو بارگذاری میکنه یا داخلش چیزی اضافه میکنه که اون برنامه بهش نیاز داشته باشه، که احتمالا اسم اینجور سیستم ها رو شنیده باشین! بهشون میگن on - demand یعنی زمانی که چیزی به چیزه دیگه ای نیاز داره اونو براش فراهم کنیم نه قبل تر از اون. (یکی دیگه از مثال هاش که شاید براتون آشنا تر باشه lazy loading داخل صفحات وب سایت ها هست، همون عکسایی که تا وقتی اسکرول نکردید و بهشون نرسیدید لود نمیشن، اینجوری سرعت بارگذاری صفحات خیلی بیشتر میشه، اینجا هم عکس ها on - demand هستن، یعنی وقتی نیازشون داریم برامون لود میشن! برای اینکه بیشتر درک کنید مسایل گفته شده رو، به نحوه شروع یک برنامه و ایجاد یک پروسس جدید داخل لینوکس توجه کنید: اول کار kernel میاد و کد و دستورعمل های اولیه برنامه رو میریزه داخل page table . تو این قسمت kernel میاد و میبینه شاید از قبل یک سری دیتایی که اون برنامه از حافظه نیاز داره داخل page table باشه و اونا رو برای این پروسس جدید هم اطلاق میکنه. همینجور که پروسس و برنامه جدیدمون اجرا میشه، ممکنه به یک نقطه ای برسه که دستورعمل بعدی توی کد، توی هیچ جای page table ای که kernel اون اول واسه پروسسمون لود کرد نباشه، اینجاست که kernel جلوی برنامه رو میگیره، میره و اطلاعات جدید رو داخل حافظه بارگذاری میکنه ( page table هم آپدیت میکنه طبیعتا) و بعدش اجازه میده برنامه کارشو دوباره از نقطه ای که متوقف شده بود ادامه بده. به همین ترتیب اگه برنامه به حافظه جدید بیشتری نیاز داشته باشه که از قبل توسط kernel توی page table واسش اطلاق نشده، kernel موقعیت رو با پیدا کردن فضای جدید داخل حافظه و آپدیت کردن page table و اطلاق اون فضا ها به پروسس جدید هندل میکنه! میتونید page size سیستمتون رو با دستور زیر ببینید: که احتمال خیلی زیاد عدد رو ببینید تو خروجی یعنی K ! که یه عدد خیلی نرمال برای اکثر توزیع های لینوکس هست. دقت کنید این فضای کل page table نیست! این فضای تک تک اون page هاییه که شامل اطلاعات فضای مجازی مپ شده روی فضای واقعی حافظه هستن. یه زمانی برناممون حافظه page شده ای رو نیاز داره که آماده نیست (مثل شماره بالا) ، اینجا پروسس اون برنامه page fault بوجود میاره یا خطای مربوط به page ، تو این حالت kernel قدرت CPU رو از اون برنامه میگیره تا بتونه page رو آماده کنه. به طور کلی دو نوع page fault داریم: این حالت زمانی رخ میده که page موردنظر داخل حافظه هست ولی MMU نمیدونه کجاست! دلیلش اینه که خود MMU یه فضای داخلی داره که توش ذخیره میکنه چه پروسسی چه page هایی داره و این فضا خیلی خیلی کوچیک و کمه. بنابراین kernel درباره اون page به MMU میگه و اجازه میده پروسس کارشو ادامه بده. minor page fault ها خیلی زیاد رخ میدن پس اصلا چیزی نیست که بخوایم نگرانش باشیم و کاملا طبیعیه. این حالت زمانی رخ میده که page موردنظر کلا داخل حافظه نیست! به این معنی که kernel مجبوره بره از دیسک ( Disk ) یا یه مکانیزم ذخیره سازی ک ند تر بخونه و بارگذاریش کنه. خیلی از Major page fault ها سیستم رو ک ند میکنن به این دلیل که kernel باید کار اضافه تر با زمان بیشتری رو انجام بده تا page ها رو آماده سازی کنه اینجوری باید شانس اجرا شدن پروسس های دیگه رو ازشون بگیره و اونا رو هم تو حالت تعلیق بزاره تا بتونه از دیسک چیزی رو بخونه. بعضی از Major page fault ها رو واقعا نمیشه کاریشون کرد. مثل زمانی که برای بار اول قراره یک برنامه رو اجرا کنید. چون کد اون برنامه باید از دیسک شما توسط kernel خونده شه. ولی از دفعات بعدی اگه همون برنامه اجرا شه دیگه لازم نیست kernel این کارو بکنه چون کد ها یه بار قبلا cache شده. فاجعه زمانی رخ میده که حافظه دیگه جایی نداره و پ ر شده و kernel مجبوره page های جدید رو روی دیسک شما ذخیره کنه (بالاخره خود page table هم داخل حافظه هست و وقتی حافظه پر شده طبیعتا نمیتونه داخل page table ای که توی حافظه هست چیزی بریزه) ادامه این فرایند ممکنه بزنه سیستمو به فنا بده! برای اینکه بتونیم خطاهای مربوط به page های پروسس ها رو مانیتور کنیم میتونیم از ابزار استفاده کنیم، دقت کنید که یه کامند داخل shell هم وجود داره، منظور ما اون نیست! میخوایم از نسخه سیستمی برنامه استفاده کنیم (احتمال داره نصب نباشه رو سیستمتون که خیلی راحت میتونید نصبش کنید) اول راجب کامند بالا یه توضیحی بدم، خود برنامه time که قراره اطلاعاتشو پایینتر ببینیم یک ورودی از ما میگیره که یه برنامه دیگست (برنامه ای که میخواید ماینتورش کنید) که اینجا مثلا رو استفاده کردیم، کامند تقویم رو نشونتون میده (یکی از عجایب لینوکس: تقویم توی CLI ، که خیلی باحاله به نظرم! ) تو ادامش اومدیم خروجی رو ریختیم توی dev / null /چون به دردمون نمیخوره اینجا، ما با خروجی برنامه کار داریم. (یه یادآوری کوچولو: با علامت < میشه گفت خروجی یه برنامه به ورودی یه برنامه یا هر چیز دیگه ای پاس داده بشه. اینجا ما پاسش دادیم به dev / null /که یه درایور مجازی هست، کارشم اینه که هر چی بهش بدید از بین میبره و ناپدیدش میکنه، که اینم خیلی باحاله) خروجی کامند بالا میشه یه چیزی شبیه این: طبق خروجی بالا من تا minor page fault داشتم که خب گفتیم طبیعیه و راجبش حرف زدیم و یک دونه هم major page fault داشتم که اونم دیگه دلیلشو میدونیم چون برنامه برای بار اول ران شده kernel رفته کدشو از دیسک خونده. اگه دوباره همون کد بالا رو اجرا کنید ایندفعه major page fault رو عدد نشون میده چون دیگه kernel کد برنامه رو میره از cache میخونه و استفاده میکنه. دیدن page fault ها میتونه بعضی جاها بهتون تو ردیابی مشکلات حافظه کمک کنه، اگه بخواید به صورت زنده page fault ها رو ببینید ابزار و هم میتونن این کارو براتون انجام بدن. ولی. اگه دوست دارید سیستمتون رو خیلی کلی تر و از هر نظر مانیتور کنید ابزار های دیگه ای وجود داره که تو قسمت های بعدی راجبش حتما حرف میزنیم. امیدوارم از این قسمتم خوشتون اومده باشه. تا قسمت بعدی فعلا: )