[tolstoy]

سلام
من debian رو رو سستمم از نوع نصب کردم و یادم رفت \ارتیشن swap بسازم .
جالب اینجاست که خیلی سریتر کار میکنه .البته ram تقریبا ‍بر شده ولی سرعت بار شدن نرم افزار ها خیلی بهتره.
چرا اینجوری مگه نباید عکسش باشه؟!!!

[alan]

یه دوتا دونه فایل حجیم باز کنید اونوقت می‌فهمین swap به چه دردی می‌خوره!

[Harir]

با سلام
اینکه با وجود swap ازش استفاده نکنیم و فقط از ram استفاده بشه، ممکنه؟ طوری که هربار این بکار گیری یا عدم بکارگیری swap براحتی ممکن باشه؟ حتی بدون reboot کردن؟

[مهمان]

swapon و swapoff

[Zouup]

سلام
من debian رو رو سستمم از نوع نصب کردم و یادم رفت \ارتیشن swap بسازم .
جالب اینجاست که خیلی سریتر کار میکنه .البته ram تقریبا ‍بر شده ولی سرعت بار شدن نرم افزار ها خیلی بهتره.
چرا اینجوری مگه نباید عکسش باشه؟!!!

یه هارد بهتر بخر

[مهمان]

آرمین جان میخوای بگی سرعت HDD از RAM بالاتره ؟
ممکنه که هارد tolstoy کند باشه, اما اگه این کار روی یه سیستم دیگه انجام بشه چی ؟
من خودم تست نکردم اما برام جالبه بدونم بدونم Swap سریعتر نیست ؟
خوب مثلا سیستمی که 2 گیگ RAM داره کجا میخواد کم بیاره که از swap استفاده کنه ؟
netcat

[مهمان]

آرمین جان میخوای بگی سرعت HDD از RAM بالاتره ؟
ممکنه که هارد tolstoy کند باشه, اما اگه این کار روی یه سیستم دیگه انجام بشه چی ؟
من خودم تست نکردم اما برام جالبه بدونم بدونم Swap سریعتر نیست ؟
خوب مثلا سیستمی که 2 گیگ RAM داره کجا میخواد کم بیاره که از swap استفاده کنه ؟
netcat

نه ، نیست . اگر شما پارتیشن Swap نداشته باشید کرنل ۱۰۰% فضای رم رو به حافظه تخصیص میده ، ولی اگر پارتیشن Swap داشته باشید کرنل 90% فضای رم رو به حافظه تخصیص میده .

این اصولا مشکله ، اگر پچ های MM کرنل های ۲.۶.۱ تا ۲.۶.۷ رو ببینید همش در مورد این قضیه Swaping ناجور کرنل صحبت شده ، آخر هم ظاهرا با استفاده از IO Scheduler تونستن کل قضیه رو دور بزنن .

سیستمی که ۲ گیگابایت رم داره اگر ۱۸۰۰ مگابایت از رمش رو استفاده کنه و بخواد بقیه رو روی هارد بنویسیه اگر هارد کندی داشته باشه خیلی کند میشه با اینکه ۲۰۰ مگابایت رم آزاد داره .

[rezatavak]

سلام

ارگ من ۲ گیگا بایت داشته باشم هم نمی تونم از رم تنها استفاده کنم؟؟؟

[Zouup]

سلام

ارگ من ۲ گیگا بایت داشته باشم هم نمی تونم از رم تنها استفاده کنم؟؟؟

چرا ، اگر انقدر رم رو پرکنی که ۸۰ درصدش رو شامل بشه و Swap نداشته باشی بقیه MEmory روی رم قرار میگیره .


من چرا هی با مهمان پست میدم ؟!‌

آرمین .

[مهمان]

آرمین جان میخوای بگی سرعت HDD از RAM بالاتره ؟
ممکنه که هارد tolstoy کند باشه, اما اگه این کار روی یه سیستم دیگه انجام بشه چی ؟
من خودم تست نکردم اما برام جالبه بدونم بدونم Swap سریعتر نیست ؟
خوب مثلا سیستمی که 2 گیگ RAM داره کجا میخواد کم بیاره که از swap استفاده کنه ؟
netcat

نه ، نیست . اگر شما پارتیشن Swap نداشته باشید کرنل ۱۰۰% فضای رم رو به حافظه تخصیص میده ، ولی اگر پارتیشن Swap داشته باشید کرنل 90% فضای رم رو به حافظه تخصیص میده .

این اصولا مشکله ، اگر پچ های MM کرنل های ۲.۶.۱ تا ۲.۶.۷ رو ببینید همش در مورد این قضیه Swaping ناجور کرنل صحبت شده ، آخر هم ظاهرا با استفاده از IO Scheduler تونستن کل قضیه رو دور بزنن .

سیستمی که ۲ گیگابایت رم داره اگر ۱۸۰۰ مگابایت از رمش رو استفاده کنه و بخواد بقیه رو روی هارد بنویسیه اگر هارد کندی داشته باشه خیلی کند میشه با اینکه ۲۰۰ مگابایت رم آزاد داره .

این جواب صحیح و فنی نیست . اگر منظور از رم همان "حافظه فیزیکی " ( Physical Memory ) است که این فضا همواره در اختیار مدیر حافظه لینوکس است . چیزی بنام 100 درصد و 90 درصد و 80 درصد و غیره مفهوم نداره . قبل از روشن شدن عملکرد Swap باید کمی در مورد مدل مدیریت حافظه و حافظه مجازی روی لینوکس گفته بشه . فرض میکنیم که بحث ذیل دربارهء سیستمهائی با میزان حافظه فوق العاده بالا ( > 64 گیگ ) نیست .

قاعدتا" به این دلیل که حافظه فیزیکی همیشه از حافظه مجازی کمتر است , مدیر حافظه لینوکس ( MM ) باید مراقب نحوهء فراخوانی Page Table ها و دسترسی به Page های فیزیکی باشه ، طبیعتا" چون دسترسی به دیسک سخت کندتر ، و حتی اگر کندتر نباشه ، پهنای باند کنترلر دیسک سخت و دیتاباس و کنترل باس مادر برد ، زمانبر و پر هزینه است ، باید برای تصمیم گرفته بشه که مناسبترین پروسه برای استفاده از حافظه فیزیکی کدام است , و برای سایر پروسه ها از حافظه مجازی استفاده شود . در مورد این قابلیت منحصر به فرد لینوکس میتونید ذیل عنوان Demand Paging در مستندات فنی مورد علاقه تون مطالب تکمیلی رو پیدا کنید . Loader لینوکس صرفا" برای فراخوانی Binary Image ها از قابلیت Demand Paging سیستم MM استفاده میکنه و برای فراخوانی سایر منابع به حافظه ، از این قابلیت استفاده نمیشه ، به عبارت دیگه ، وقتی در حال فراخوانی منبع غیر باینری به حافظه هستیم ( فرخوانی یک شیء ساخته شده در زمان اجرا به هیپ - فرضا" محتوی یک Jpeg یا یک رکورد بلاب دیتابیس یا هر چیزی مثل این ) ، از VMM استفاده میشود ( یعنی MM کنترل را به VMM میدهد - مدیر حافظه مجازی ) اما به محض فراخوانی یک Binary Image ( یک برنامه اجرائی - یک اسکریپت با فلگ اجرائی و امثال این ) از Demand Paging استفاده میشود ، به عبارت ساده تر ، همواره باینری ها دارای اولویت بیشتر هستند و تا حد ممکن از "حافظه فیزیکی" برای تخصیص حافظهء آنها استفاده میشود .

حالا میشه در مورد Swap صحبت کرد . اگر بنا به تصمیم MM قرار شد که آفست یا آفستهائی از حافظه مجازی ( یا منبعی روی دیسک سخت که هنوز فراخوانی نشده است ) به حافظه فیزیکی منتقل بشه اما برای این انتقال فضای کافی وجود نداشته باشه چه اتفاقی خواهد افتاد ؟ با توجه به ویژگی Demand Paging باید Page هائی که دارای اولویت بالاتر هستند روی حافظه فیزیکی در دسترس باشند و حالا حافظهء فیزیکی بیشتری نداریم . چه کنیم ؟ MM باید تصمیم بگیرید کدام بخش از حافظه فیزیکی را بصورت موقت تخلیه کند و به فرایند تخلیهء حافظه فیزیکی و باز-فراخوانی آفستهای تخلیه شده به حافظه فیزیکی از حافظه مجازی Swapping ( مبادله ) گفته میشه . در حقیقت وجود فضای Swap باعث میشه الگوریتم مبادلهء سیستم MM لینوکس بتونه با تشخیص مناسب اولویت ، عطف به مزایای Demand Paging ، بین حافظه فیزیکی و حافظه مجازی - با عنایت به الگوریتم تشخیص اولویت - مبادله انجام بده ، و هر چه فضای این مبادله بیشتر باشه ، با افزودن بار و فشار بیشتر روی مدیر حافظه ، باز هم لینوکس قادر به جوابگوئی به درخواستها خواهد بود ، و اگر این فضای تبادل کم باشه ، یا وجود نداشته باشه ، در حقیقت Demand Paging با موفقیت انجام نخواهد شد . این یعنی چی ؟ یعنی سیستم تشخیص اولویت تخصیص حافظه سریعتر و بهینه تر فیزیکی لینوکس عمل نخواهد کرد که نتیجه اش کند تر اجرا شدن باینریها و کاهش کارائی عملکرد سیستم است ؛ اما این یک حکم جامع و همیشگی نیست ، شاید نوع برنامه های اجرا شده ، پیکره بندی کرنل و امثال این دارای موقعیتی باشند که کاربر هنگام اجرای باینری ها احساس کندی به خصوصی نکند ، در واقع گاهی همینطور هم هست ، اما "اغلب" وقتی قرار باشه باینریهای متعددی روی سیستم اجرا بشه و حافظه فیزیکی چندان زیادی هم موجود نباشه ، و سخت افزار ماشین لینوکس ما ، چندان بهینه نباشه ، پس از مدت کوتاهی کاهش کارائی کاملا" محسوس خواهد شد . MM لینوکس از تکنیکی بنام LRU ( یا Least Recently Used ) برای تبادل Page های با اولویت پائینتر با فضای Swap استفاده میکنه که به نظر میرسه پیاده سازی مناسبی هم داره و بهتره ازش استفاده بشه ، به عبارت ساده تر ، بهتره از Swap استفاده کنیم ، حتی اگر حافظه فیزیکی زیاد و مناسبی داریم ، و سخت افزار ، مادر برد ، کنترلهای دیسک سخت و سایر باسهای بین راه همگی به اندازه کافی خوب باشند .

خوش باشید :wink:

[Zouup]

این جواب صحیح و فنی نیست . اگر منظور از رم همان "حافظه فیزیکی " ( Physical Memory ) است که این فضا همواره در اختیار مدیر حافظه لینوکس است . چیزی بنام 100 درصد و 90 درصد و 80 درصد و غیره مفهوم نداره . قبل از روشن شدن عملکرد Swap باید کمی در مورد مدل مدیریت حافظه و حافظه مجازی روی لینوکس گفته بشه . فرض میکنیم که بحث ذیل دربارهء سیستمهائی با میزان حافظه فوق العاده بالا ( > 64 گیگ ) نیست .

قاعدتا" به این دلیل که حافظه فیزیکی همیشه از حافظه مجازی کمتر است , مدیر حافظه لینوکس ( MM ) باید مراقب نحوهء فراخوانی Page Table ها و دسترسی به Page های فیزیکی باشه ، طبیعتا" چون دسترسی به دیسک سخت کندتر ، و حتی اگر کندتر نباشه ، پهنای باند کنترلر دیسک سخت و دیتاباس و کنترل باس مادر برد ، زمانبر و پر هزینه است ، باید برای تصمیم گرفته بشه که مناسبترین پروسه برای استفاده از حافظه فیزیکی کدام است , و برای سایر پروسه ها از حافظه مجازی استفاده شود . در مورد این قابلیت منحصر به فرد لینوکس میتونید ذیل عنوان Demand Paging در مستندات فنی مورد علاقه تون مطالب تکمیلی رو پیدا کنید . Loader لینوکس صرفا" برای فراخوانی Binary Image ها از قابلیت Demand Paging سیستم MM استفاده میکنه و برای فراخوانی سایر منابع به حافظه ، از این قابلیت استفاده نمیشه ، به عبارت دیگه ، وقتی در حال فراخوانی منبع غیر باینری به حافظه هستیم ( فرخوانی یک شیء ساخته شده در زمان اجرا به هیپ - فرضا" محتوی یک Jpeg یا یک رکورد بلاب دیتابیس یا هر چیزی مثل این ) ، از VMM استفاده میشود ( یعنی MM کنترل را به VMM میدهد - مدیر حافظه مجازی ) اما به محض فراخوانی یک Binary Image ( یک برنامه اجرائی - یک اسکریپت با فلگ اجرائی و امثال این ) از Demand Paging استفاده میشود ، به عبارت ساده تر ، همواره باینری ها دارای اولویت بیشتر هستند و تا حد ممکن از "حافظه فیزیکی" برای تخصیص حافظهء آنها استفاده میشود .

حالا میشه در مورد Swap صحبت کرد . اگر بنا به تصمیم MM قرار شد که آفست یا آفستهائی از حافظه مجازی ( یا منبعی روی دیسک سخت که هنوز فراخوانی نشده است ) به حافظه فیزیکی منتقل بشه اما برای این انتقال فضای کافی وجود نداشته باشه چه اتفاقی خواهد افتاد ؟ با توجه به ویژگی Demand Paging باید Page هائی که دارای اولویت بالاتر هستند روی حافظه فیزیکی در دسترس باشند و حالا حافظهء فیزیکی بیشتری نداریم . چه کنیم ؟ MM باید تصمیم بگیرید کدام بخش از حافظه فیزیکی را بصورت موقت تخلیه کند و به فرایند تخلیهء حافظه فیزیکی و باز-فراخوانی آفستهای تخلیه شده به حافظه فیزیکی از حافظه مجازی Swapping ( مبادله ) گفته میشه . در حقیقت وجود فضای Swap باعث میشه الگوریتم مبادلهء سیستم MM لینوکس بتونه با تشخیص مناسب اولویت ، عطف به مزایای Demand Paging ، بین حافظه فیزیکی و حافظه مجازی - با عنایت به الگوریتم تشخیص اولویت - مبادله انجام بده ، و هر چه فضای این مبادله بیشتر باشه ، با افزودن بار و فشار بیشتر روی مدیر حافظه ، باز هم لینوکس قادر به جوابگوئی به درخواستها خواهد بود ، و اگر این فضای تبادل کم باشه ، یا وجود نداشته باشه ، در حقیقت Demand Paging با موفقیت انجام نخواهد شد . این یعنی چی ؟ یعنی سیستم تشخیص اولویت تخصیص حافظه سریعتر و بهینه تر فیزیکی لینوکس عمل نخواهد کرد که نتیجه اش کند تر اجرا شدن باینریها و کاهش کارائی عملکرد سیستم است ؛ اما این یک حکم جامع و همیشگی نیست ، شاید نوع برنامه های اجرا شده ، پیکره بندی کرنل و امثال این دارای موقعیتی باشند که کاربر هنگام اجرای باینری ها احساس کندی به خصوصی نکند ، در واقع گاهی همینطور هم هست ، اما "اغلب" وقتی قرار باشه باینریهای متعددی روی سیستم اجرا بشه و حافظه فیزیکی چندان زیادی هم موجود نباشه ، و سخت افزار ماشین لینوکس ما ، چندان بهینه نباشه ، پس از مدت کوتاهی کاهش کارائی کاملا" محسوس خواهد شد . MM لینوکس از تکنیکی بنام LRU ( یا Least Recently Used ) برای تبادل Page های با اولویت پائینتر با فضای Swap استفاده میکنه که به نظر میرسه پیاده سازی مناسبی هم داره و بهتره ازش استفاده بشه ، به عبارت ساده تر ، بهتره از Swap استفاده کنیم ، حتی اگر حافظه فیزیکی زیاد و مناسبی داریم ، و سخت افزار ، مادر برد ، کنترلهای دیسک سخت و سایر باسهای بین راه همگی به اندازه کافی خوب باشند .

خوش باشید :wink:

مسئله Swap لینوکس چیزی ساده ای نیست ، چیز حل شده ای هم نیست .
طبق تعریف تئوریک شما طبیعتا لینوکس نباید مشکل Swap داشته باشه ‌، با اینکه تعریفی که کردی کاملا منطبق بر نسخه های جدید کرنل ( مخصوصا 2.6.8 به بعد ) به علت اضافه شدن IO Scheduler ها و مخصوصا CFQ که بهترین روش برای سرپوش گذاشتن روی مشکل Swap شده نیست ولی میشه بر اساسش صحبت کرد .
پیشنهاد میکنم یه تست جالب انجام بدی :
مواد لازم :‌

کرنل ۲.۶.۸ به بالا بدون IOSCH یا کرنل ۲.۶.۱ تا ۲.۶.۸ با CFQ .
۵۱۲ مگابایت رم
۱ گیگابایت Swap

روی کرنل جدید برنامه یی بنویس که با ()calloc ، تمام رم رو پر کنه ،اجراش کن ، کرنل به شدت شروع به Swap کردن میکنه و هیچ وقت Recovery رو انجام نمیده . بعد از چند ثانیه Freeze کرنل برنامه ات رو به علت OOM میکشه . ولی قبل از ایکه Kill بشه Swap ات رو نگاه کن ، حداکثر ۱۰٪ Swap ات استفاده شده . مثلا میتونی از vmstat استفاده کنی .

خب ، میدونیم که MM مشکلی نداره ، اصولا MM چیز بزرگی نیست و وقتی این همه هکر تمام وقت روش کار میکنن که بتونن این مشکل رو حل کنن میشه گفت که مشکل نداره ، تئوری شما هم طبیعتا درسته و چیزیه که لینوکس بر اساسش کار میکنه . پس چرا این مشکل پیش میاد ... ؟ مشکل Desgin ؟

کاری که فعلا شده ، اینه که CFQ هیچ وقت اجازه نمیده وقتی ۱۰۰٪ حافظه فیزیکی یا همون رم خودمون رو استفاده کنه و بعد شروع به Swap کردن کنه ، این اتفاق کمی قبل تر ، وقتی که ۸۰٪ تا ۹۰٪ رم استفاده شده اتفاق میفته ، همون برنامه رو میتونی رو ۲.۶.۱۵ تست کنی . الان دیگه باکس Freeze نمیشه ، ولی به طور کل Swaping خیلی خوبی هم انجام نمیده .

اگر کسی اینجا دلش میخواد این تست رو انجام بده ولی نمیتونه کد بزنه ، یه نمونه مینویسم که میتونه استفاده کنه :
[ltr]

کد :

#include <stdio.h>

int main()
{
    char *p;

    p= calloc(1, 1024*1024*512 );
    if (!p) {
        fprintf(stderr, "Not enough memory");
        exit(1);
    }
    return 0;
}

[/ltr]

[مهمان]

تصور نميكردم كه لازم باشه نكات ابتدائي و اوليه اي مانند مفهوم حافظه مجازي روي وضعيت Protected Mode‌ رو توضيح بدم ؛ اما به نظر مياد مسئله همينه .

روی کرنل جدید برنامه یی بنویس که با ()calloc ، تمام رم رو پر کنه ،اجراش کن

هيچ برنامه اي قادر نيست تمام حافظه فيزيكي رو اشغال كنه . وقتي سيستم عامل در وضعيت Protected Mode است ، براي هر پروسه فضاي آدرسي منحصر به فردي در نظر گرفته ميشه كه بخشي از اون روي حافظه فيزيكي و بخشي از اون تحت مديريت حافظه مجازي است ، و يك پروسه روي لينوكس فقط ميتونه تحت كنترل MM و داخل فضاي آدرسي خودش از حافظه استفاده كنه . روي معماري 32 بيتي اينتل ، اين فضا براي هر پروسه چهار گيگابايت است . از اين مقدار دو گيگ به اجزاء سطح كرنل پروسه ( مپ شدن ماژولهاي كرنل ) و دو گيگ به بخش سطح كاربر ( User Mode ) اختصاص داره ، و نهايتا" يك پروسه روي لينوكس نميتونه در حالت عادي فضائي بيش از اين رو به متغيرهاش اختصاص بده ( مگر با استفاده از Remote Thread ها يا Inline Code Injection - روي سايت برنامه نويس دو مقاله در موردشون نوشته ام - براي مراجعات بعدي )

پس پيش از هر چيز به اين نكته توجه كن كه "پر كردن رم" مفهوم فني نداره . يك پروسه روي يك ماشين معمولي لينوكس ، روي يك معماري 32 بيتي ، ميتونه داخل همين فضاي 4 گيگ زندگي كنه . از دو گيگي كه براي سطح كاربر در نظر گرفته شده ، بايد Binary Image Size رو كم كردم ، همينطور Boarder هائي كه بين استك و هيپ و bss توسط سيستم عامل رزرو ميشه ، و تازه در عمل فضاي موجود خيلي كمتر از اين حرفها هم هست ، به دليل Padding و smashing روي استك و مواردي از اين دست .

پس چرا این مشکل پیش میاد ... ؟ مشکل Desgin ؟

خوب بايد ديد آيا اصلا" مشكلي هست يا نيست ؟
سيستم عامل ، و مشخصا" كرنل ، هميشه دست بالاترين بخش حافظه فيزيكي رو براي ادامه حياط خودش در اختيار ميگيره ، و در هر حال اون فضا به كرنل و ماژولهاي مربوطه اختصاص داره ، و امكان دسترسي به اون فضا از سطح كاربر نيست ، و در سطح كرنل ( Ring0‌ ) هم كاملا" ابلهانه است اگه برنامهء معقولي تصميم به دست اندازي به فضاي آدرسي كرنل سيستم عامل بگيره . از حافظه فيزيكي باقي مانده ، هر چه كه هست ، MM و VMM اند كه تقسيم و تسهيم كننده اند . بايد ديد كدي كه تو نوشتي دقيقا چه ميكنه ؟ و چرا اين يه مشكل به نظر مياد در حاليكه مشكل نيست . كدي كه تو نوشتي با اختصاص فضا روي هيپ ، جلو ميره ، اما تا كجا ؟ قاعدتا" تا زماني كه از محدودهء مذكور تو قسمت قبل بحث تجاوز نكنه ، و بعد از اون طبيعتا" بايد با خطاي Access Violation مواجه بشي ، چون آدرس ديگري براي تخصيص وجود نداره ، ظرفيت فضاي آدرسي پروسه ات تمام شده . طبيعيه كه لينوكس براي كد باينري تو اولويت بالاتري قائل ميشه ( ر-ك جواب قبلي ) و تلاش ميكني با مبادله اي كه گفتي ، فضاي آدرسي بيشتري روي حافظه فيزيكي فراهم كنه ، و بعيد نيست كه وقتي ديگه فضاي بيشتري براي تخصيص روي حافظه فيزيكي موجود نيست ، on Demand Paging كرنل با مشكل مواجه بشه . در هر حال اين مسئله بيشتر شبيه يك نوع هندل كردن خطاست ، نه يك خطا در معماري يا حتي پياده سازي . بهر ترتيب هيچ وقت يك رفتار طبيعي ، از يك پروسه عادي ، تقاضاي اختصاص تمام ( اندكي كمتر از ) دو گيگا بايت فضاي سطح كاربر پروسه مذكور رو نخواهد كرد ، مگر اينكه يه چيزي يه جائي غير عادي باشه ، كه مسئله ميره تو زمين قسمت حمايت از خطا ؛

يك Swaping خوب ، Swaping اي نيست كه تو بپنداري بهت اجازه ميده هر چقدر كه ميخواهي حافظه تخصيص بدي ، اين نكته در واقع بصورت تئوريك ممكن نيست ؛ يك شمارندهء طبيعي روي معماري IA32 قاعدتا" تا چهار گيگ رو آدرس ميده و لينوكس ، بخاطر معماري مدرن ترش ( نسبت به ويندوز كه اخيرا" به اين حالت رسيده - بهتره بگم زور ميزنه كه ادعا كنه داره ميرسه ) فقط دو گيگ رو به سطح كاربر ( Ring3‌) اختصاص خواهد داد . ( ميشه با تغيير پيكره بندي ، اين نسب 2-2 رو به يه نسبت 3-1 تغيير داد . يعني 3 گيگ روي Ring3 و يك گيگ براي Rin0 كه معمولا" كاربرد خاصي نداره )

فضائي كه به سطح كرنل يك پروسه اختصاص داده ميشه مصروف اختصاص فضا به Map شدن آدرسهاي Shared Object ها يا Library هاي Kernel Mode همان پروسه ، يا SO هاي سطح كرنلي كه متعلق به سيستم عامل است و در اين پروسه بهشون پيوندي وجود داره ، ميشه و بقيه فضاي موجود به قرار گرفتن خود كد ، bss و هيپ و استك برنامه و ماژولهاي سطح كاربرش اختصاص دارند . يك برنامهء عادي و معقول ، قاعدتا" از اين منطق پيروي ميكنه ، و اگه تو كدي نوشتي كه تلاش كرد ، منطق رو نقض كنه ، در صورت بروز خطائي كه كنترل سيستم رو ميگيره ، ميشه هندل كردن خطاهاي سيستم عامل رو مقصر دونست ، و بهر حال اين مسئله ارتباطي به وجود يك مشكل در VMM يا Swaping نداره . حالا سوال اينه كه آيا اين مسئله به معناي پرفكت بودن Swaping است ؟ جوابش منفيه . اگر اهل پيگيري كردن ايميلهاي ليست هاي پست كرنل باشي ، الگوريتهاي on Demand Paging و Page Table padding و ترجيح اولويت همچنان مسائل بازي هستند كه ميتونن به مراتب بهتر از وضع فعلي بشن . اينكه ما بپذيريم لينوكس در حال بهبوده يك حرف است ، و اينكه با نقض بديهيات تئوريك انتظار معجزه داشتيم باشيم ، شايد يه بحث ديگه . شايد من منظورت رو از نوشته هات به درستي متوجه نشده باشم ، كه اگر اينطوره قاعدتا" خودت توضيح ميدي .

موفق باشي .

[Zouup]

تصور نميكردم كه لازم باشه نكات ابتدائي و اوليه اي مانند مفهوم حافظه مجازي روي وضعيت Protected Mode‌ رو توضيح بدم ؛ اما به نظر مياد مسئله همينه .

:!:

هيچ برنامه اي قادر نيست تمام حافظه فيزيكي رو اشغال كنه . وقتي سيستم عامل در وضعيت Protected Mode است ، براي هر پروسه فضاي آدرسي منحصر به فردي در نظر گرفته ميشه كه بخشي از اون روي حافظه فيزيكي و بخشي از اون تحت مديريت حافظه مجازي است ، و يك پروسه روي لينوكس فقط ميتونه تحت كنترل MM و داخل فضاي آدرسي خودش از حافظه استفاده كنه . روي معماري 32 بيتي اينتل ، اين فضا براي هر پروسه چهار گيگابايت است . از اين مقدار دو گيگ به اجزاء سطح كرنل پروسه ( مپ شدن ماژولهاي كرنل ) و دو گيگ به بخش سطح كاربر ( User Mode ) اختصاص داره ، و نهايتا" يك پروسه روي لينوكس نميتونه در حالت عادي فضائي بيش از اين رو به متغيرهاش اختصاص بده ( مگر با استفاده از Remote Thread ها يا Inline Code Injection - روي سايت برنامه نويس دو مقاله در موردشون نوشته ام - براي مراجعات بعدي )

پس پيش از هر چيز به اين نكته توجه كن كه "پر كردن رم" مفهوم فني نداره . يك پروسه روي يك ماشين معمولي لينوكس ، روي يك معماري 32 بيتي ، ميتونه داخل همين فضاي 4 گيگ زندگي كنه . از دو گيگي كه براي سطح كاربر در نظر گرفته شده ، بايد Binary Image Size رو كم كردم ، همينطور Boarder هائي كه بين استك و هيپ و bss توسط سيستم عامل رزرو ميشه ، و تازه در عمل فضاي موجود خيلي كمتر از اين حرفها هم هست ، به دليل Padding و smashing روي استك و مواردي از اين دست .

بی شک هیچ برنامه ای نمیتونه تمام حافظه فیزیکی رو اشغال کنه ،برای همینه که اون برنامه کوچیک کیل میشه ، مشکل اینه که اگر ما در PM هستیم چرا Swaping درستی انجام نمیشه . اگر قرار بود هر برنامه ای بتونه تمام حافظه فیزیکی رو اشغال کنه چیزی به به اسم سیستم عامل پایدار وجود نداشت ، سیستم عامل چیزی میشد که باید هر چند دقیقه از اول اجرا بشه . بحثی رو این قضیه نیست .

خوب بايد ديد آيا اصلا" مشكلي هست يا نيست ؟
سيستم عامل ، و مشخصا" كرنل ، هميشه دست بالاترين بخش حافظه فيزيكي رو براي ادامه حياط خودش در اختيار ميگيره ، و در هر حال اون فضا به كرنل و ماژولهاي مربوطه اختصاص داره ، و امكان دسترسي به اون فضا از سطح كاربر نيست ، و در سطح كرنل ( Ring0‌ ) هم كاملا" ابلهانه است اگه برنامهء معقولي تصميم به دست اندازي به فضاي آدرسي كرنل سيستم عامل بگيره . از حافظه فيزيكي باقي مانده ، هر چه كه هست ، MM و VMM اند كه تقسيم و تسهيم كننده اند . بايد ديد كدي كه تو نوشتي دقيقا چه ميكنه ؟ و چرا اين يه مشكل به نظر مياد در حاليكه مشكل نيست . كدي كه تو نوشتي با اختصاص فضا روي هيپ ، جلو ميره ، اما تا كجا ؟ قاعدتا" تا زماني كه از محدودهء مذكور تو قسمت قبل بحث تجاوز نكنه ، و بعد از اون طبيعتا" بايد با خطاي Access Violation مواجه بشي ، چون آدرس ديگري براي تخصيص وجود نداره ، ظرفيت فضاي آدرسي پروسه ات تمام شده . طبيعيه كه لينوكس براي كد باينري تو اولويت بالاتري قائل ميشه ( ر-ك جواب قبلي ) و تلاش ميكني با مبادله اي كه گفتي ، فضاي آدرسي بيشتري روي حافظه فيزيكي فراهم كنه ، و بعيد نيست كه وقتي ديگه فضاي بيشتري براي تخصيص روي حافظه فيزيكي موجود نيست ، on Demand Paging كرنل با مشكل مواجه بشه . در هر حال اين مسئله بيشتر شبيه يك نوع هندل كردن خطاست ، نه يك خطا در معماري يا حتي پياده سازي . بهر ترتيب هيچ وقت يك رفتار طبيعي ، از يك پروسه عادي ، تقاضاي اختصاص تمام ( اندكي كمتر از ) دو گيگا بايت فضاي سطح كاربر پروسه مذكور رو نخواهد كرد ، مگر اينكه يه چيزي يه جائي غير عادي باشه ، كه مسئله ميره تو زمين قسمت حمايت از خطا ؛

يك Swaping خوب ، Swaping اي نيست كه تو بپنداري بهت اجازه ميده هر چقدر كه ميخواهي حافظه تخصيص بدي ، اين نكته در واقع بصورت تئوريك ممكن نيست ؛ يك شمارندهء طبيعي روي معماري IA32 قاعدتا" تا چهار گيگ رو آدرس ميده و لينوكس ، بخاطر معماري مدرن ترش ( نسبت به ويندوز كه اخيرا" به اين حالت رسيده - بهتره بگم زور ميزنه كه ادعا كنه داره ميرسه ) فقط دو گيگ رو به سطح كاربر ( Ring3‌) اختصاص خواهد داد . ( ميشه با تغيير پيكره بندي ، اين نسب 2-2 رو به يه نسبت 3-1 تغيير داد . يعني 3 گيگ روي Ring3 و يك گيگ براي Rin0 كه معمولا" كاربرد خاصي نداره )
[...]
موفق باشي .

بله مشکلی هست ، بی شک مشکلی هست و این مشکل صرفا Handle کردن خطا نیست .
این برنامه احمقانه ( تاکید میکنم که غیر معقوله ، ولی ممکنه به خیلی دلایل واقعا اتفاق بیقته ) تا جایی که کرنل بهش اجازه بده از حافظه فیزیکی استفاده میکنه و بعد کیل میشه ، خب ، این مشخصه و بحثی روش نداریم . تئوریی که ارائه کردی هم درسته و کرنل لینوکس بر این اساس کار میکنه ،‌
چیزی که مهمه اینه که اولا چرا چنین چیز کوچکی میتونه سیستم رو چند ثانیه Freeze کنه ، دوم اینکه چرا ما روی این برنامه سنگین Swaping نداریم .
من تلاش نکردم منطقی رو نقض کنم ، کرنل نمیدونه که من دارم منطق رو تقض میکنم ، صرفا باید این اجازه باید وجود داشته باشه که من از فضای سیستم( حافظه فیزیکی + Swap ) در حد معقول استفاده کنم ، مهم نیست چه استفاده ای .
چرا این اتفاق نمیفته ؟ جواب این نیست استفاده ای که من میکنم احمقانه است .
قبل از 2.6.8 ، وقتی تمام فضای حافظه فیزیکی که کرنل اجازه استفاده ازش رو میداد پر میشد همزمان هم kswapd شروع به کار میکرد و هم سیستم Freeze میشد ، توجه کن که سیستم واقعا Freeze میشه و این بی شک نباید در Protected Mode اتفاق بیفته .
در زمان 2.6.8.1 Con Colivans پچی ارائه کرد که یک Watermark جدید به kswapd اضافه میکرد ، کل قضیه اینه که این پچ باعث میشه وقتی بیشتر از ۸۰٪ درصد حافظه فیزیکی در حال استفاده است ،‌Kswapd شروع به کار کنه و بر اساس اولویت process هارو روی حافظه فیزیکی یا Swap بفرسته ، این کاریه که IOSche انجام میده CFQ دقیقا چیزیه که Colivans نوشته ، برای این بود که گفتم "کرنلهای جدید تر وقتی ۸۰٪ حافظه رو پر میکنن بر خلاف کرنلهای قبلی که این مقدار حداکثر ممکن بود شروع به Swaping میکنن" .

پچ های این بابا رو میتونی در
[ltr]
<!-- m --><a class="postlink" href="http://ck.kolivas.org/patches/2.6/2.6.8.1/">http://ck.kolivas.org/patches/2.6/2.6.8.1/</a><!-- m -->
[/ltr]
پیدا کنی ، برای تمام نسخه های لینوکس این پچ وجود داره و مثل سری مورتون جدا Merge میشه .من نسخه 2.6.8.1 رو میفرستم چون مشخص ترین تغییرات رو داره .

[مهمان]

پیش از بحث اصلی :

مشکل اینه که اگر ما در PM هستیم چرا Swaping درستی انجام نمیشه .

این دو بهم مربوط نیستند . Swaping یک ویژگی سیستم عامل است ، میتونه روی Real Mode هم پیاده سازی بشه . Protected Mode یک ویژگی پردازنده است که تکلیف مسائلی مانند مدیریت حافظه و پردازه ها و آدرس دهی و ... رو روشن میکنه . Swaping خوب ، Swaping بد ، یا هر چیزی بین این دو ، ربطی به بحث PM نداره . من اون تذکر رو نوشتم برای اشاره به این نکته که "چیزی که بتونه حافظه فیزیکی رو کاملا" پر کنه " وجود خارجی نداره ؛ فی الواقع یه بحث جانبی بود .

اولا چرا چنین چیز کوچکی میتونه سیستم رو چند ثانیه Freeze کنه ، دوم اینکه چرا ما روی این برنامه سنگین Swaping نداریم .

در مورد اولا" اش مطلبی ندارم چون درباره اش به اندازه کافی وقت نگذاشتم . ( بین خودمون باشه - یکسال قبل تو یه بحث دیگه به من میگفتی ثبات و قابلیت اطمینان لینوکس با ویندوز قابل مقایسه نیست ، البته من هم باهات موافق بودم اما نه به اون سبک افراطی ؛ جالبه بدونی کدی مانند کدی که تو نوشتی ویندوز رو فریز نخواهد کرد . فقط یک پیام Access Violation ساده میبینی و خلاص ؛ ) اما تکلیف دوما" روشنه . این مسئله ارتباطی به Swaping نداره ! متوجه نشدم چطور بین اینها ارتباط برقرار میکنی .

اختصاص تمام حافظهء مجاز به یک پروسه روی ring3 به عهدهء VMM است ؛ حالا یا خوب عمل میکنه یا بد ، یا موفقه یا نیست ، در هر حال این مسئله ارتباط مستقیمی با Swap نداره . Swap فوق العاده وابسته به شرایط و وضعیت سیستم هست. میزان حافظه ای که قبلا" اختصاص پیدا کرده و میزان حافظه مجازی مصرف شده و مواردی از این دست . ممکنه در شرایطی به محض اجرای کد فوق الذکر Swaping خفنی روی سیستم اتفاق بیفته ، و ممکنه گاهی اینطور نباشه . در واقع مسئلهء "تخصیص حافظه" به مسئله "تبادل Page های فیزیکال و ویرچوال" ربطی نداره .

توجه کن که سیستم واقعا Freeze میشه و این بی شک نباید در Protected Mode اتفاق بیفته .

البته این یک ایده آله . در اینکه یک چیزی یه جائی داره بد کار میکنه شکی ندارم و باهات موافقم .

وقتی بیشتر از ۸۰٪ درصد حافظه فیزیکی در حال استفاده است ،‌Kswapd شروع به کار کنه و بر اساس اولویت process هارو روی حافظه فیزیکی یا Swap بفرسته

من این Patch ها رو مطالعه نکردم و وقتش رو هم ندارم اما وقتی میگی اینطور هست حتما هست . چیزی که من میفهمم اینه که کد تو ، یا هر کدی مانند این ، به محض عبور از حد مجاز مطابق معماری سخت افزاری و روایت سیستم عامل ، متوقف میشه ، آنهم به شکلی نا مناسب ، نه مناسب . حالا چه سیستم Swaping موفقی داشته باشه ، چه نداشته باشه ، در هر حال اون کد اجرای موفقیت آمیزی نخواهد داشت . در واقع Swap راه حلی برای فائق اومدن بر مسالهء "حداکثر چهار گیگ" نیست ، فقط راه حلی برای دسترسی سریعتر به Virtual Page هاست . حالا حتی اگر ما یک Swap نا موفق داشته باشیم ، یا هیچ Swap ای داشته باشیم ، باز هم کد تو با سیستم مشکل خواهد داشت ، و این مساله که سیستم عامل چطور با این مشکل مواجه میشه ، مربوطه به Exception Handling ، نه Swap ، و نه چیزی مثل این . مطمئن نیستم که فریز به دلیل یک باگ در MM است ، یا در کرنل یا ...، اونی که مطمئنم اینه که صورت مسئلهء بحث ، یعنی Swap ، ارتباطی با هنگ کردن ، یا هنگ نکردن ، در این حالت کاملا" خاص نداره . ما اینجا با یک بحث تئوریک ساده روبرو هستیم ؛ یک برنامه به چقدر فضا دسترسی خواهد داشت ؟ همین . حالا اینکه لینوکس برای افزایش بهینگی از Swap استفاده میکنه ، تغییری در این صورت مسئله و مشکل نمیده . در واقع من در حال صحبت کردن در مورد Patch هائی که میگی نیستم ، در حال نفی ارتباط بین این دو موضوع هستم . ( موضوع الف : میزان دسترسی یک برنامه به فضا و برخورد سیستم عامل با زیاده خواهی های احتمالی / موضوع ب : نقش Swap در افزایش کیفیت و یا کارائی VMM )

روز خوش

[مهمان]

شرمنده من وسط بحث یه هویی میپرم وسط, اما عجب بحثی شد !
کاشکی همه بحث ها اینجوری بشن.
netcat

[Zouup]

[...]

من این Patch ها رو مطالعه نکردم و وقتش رو هم ندارم اما وقتی میگی اینطور هست حتما هست . چیزی که من میفهمم اینه که کد تو ، یا هر کدی مانند این ، به محض عبور از حد مجاز مطابق معماری سخت افزاری و روایت سیستم عامل ، متوقف میشه ، آنهم به شکلی نا مناسب ، نه مناسب . حالا چه سیستم Swaping موفقی داشته باشه ، چه نداشته باشه ، در هر حال اون کد اجرای موفقیت آمیزی نخواهد داشت . در واقع Swap راه حلی برای فائق اومدن بر مسالهء "حداکثر چهار گیگ" نیست ، فقط راه حلی برای دسترسی سریعتر به Virtual Page هاست . حالا حتی اگر ما یک Swap نا موفق داشته باشیم ، یا هیچ Swap ای داشته باشیم ، باز هم کد تو با سیستم مشکل خواهد داشت ، و این مساله که سیستم عامل چطور با این مشکل مواجه میشه ، مربوطه به Exception Handling ، نه Swap ، و نه چیزی مثل این . مطمئن نیستم که فریز به دلیل یک باگ در MM است ، یا در کرنل یا ...، اونی که مطمئنم اینه که صورت مسئلهء بحث ، یعنی Swap ، ارتباطی با هنگ کردن ، یا هنگ نکردن ، در این حالت کاملا" خاص نداره . ما اینجا با یک بحث تئوریک ساده روبرو هستیم ؛ یک برنامه به چقدر فضا دسترسی خواهد داشت ؟ همین . حالا اینکه لینوکس برای افزایش بهینگی از Swap استفاده میکنه ، تغییری در این صورت مسئله و مشکل نمیده . در واقع من در حال صحبت کردن در مورد Patch هائی که میگی نیستم ، در حال نفی ارتباط بین این دو موضوع هستم . ( موضوع الف : میزان دسترسی یک برنامه به فضا و برخورد سیستم عامل با زیاده خواهی های احتمالی / موضوع ب : نقش Swap در افزایش کیفیت و یا کارائی VMM )

روز خوش

صحبت اصلی Thread در مورد این بود که دقیقا کی لینوکس شروع به Swaping میکنه ،‌ وقتی که تمام فضای آزاد حافظه فیزیکی به Process اختصاص داده میشه یا قبل از تر آن .
دقیقا مسئله همینه ، من کدی نوشتم که به طور نامناسب OOM می گیره ، مهم اینجا نیست که چرا این برنامه به طور نا مناسب OOM می گیره ، چیزی که توجه من رو جلب میکنه اینه که
۱ پراسس شروع به کار میکنه
۲ این تابع callof () ، سعی میکنه ۵۱۲ مگابایت به خودش رو اختصاص بده
۳ طبیعتا تا وقتی که احتیاج به Swap نداشته باشیم همه چیز مرتبه

حالا از اینجا به بعد دو حالت داریم ،‌یا از Swap استفاده میکنیم یا نه

۴-۱ اگر از Swap استفاده نکنیم برنامه بلافاصله و بدون Freeze شدن Box کیل میشه
۴-۲ اگر از Swap استفاده کنیم ، درست وقتی که باید Swap شروع به کار کنه سیستم Freeze میشه و تابع calloc () و بعد از اون OOM در حالی که ۱۰٪‌ فضای Swap فعاله و calloc خیلی کند به کار خودش ادامه میده و کرنل همین طور به Swap کردن ادامه میده .

مثلا من این vmstat رو روی تست های چند وقت پیشم روی این مشکل قبل از کیل شدن داشتم :‌


[ltr]
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 4 12412 61108 70028 0 0 95 13 1107 2939 7 2 85 6
0 0 4 12412 61112 70048 0 0 20 0 1086 3165 4 2 60 34
0 0 4 12412 61112 70048 0 0 0 0 1086 3153 4 2 94 0
0 0 4 12412 61112 70048 0 0 0 0 1091 3189 4 3 93 0
0 0 4 12348 61120 70064 0 0 16 68 1091 3242 4 2 91 3
0 0 4 12284 61128 70064 0 0 0 20 1095 3224 4 2 94 0
0 0 4 12220 61128 70064 0 0 0 0 1089 3238 4 2 94 0
0 0 4 12092 61132 70132 0 0 72 0 1087 3175 4 1 92 3
0 0 4 12092 61132 70132 0 0 0 0 1080 3148 4 2 94 0
1 0 4 12092 61132 70132 0 0 0 0 1082 3104 3 3 94 0
0 0 4 12092 61140 70132 0 0 0 16 1083 3129 4 2 94 0
0 0 4 12092 61140 70132 0 0 0 0 1085 3302 4 1 95 0
0 0 4 12092 61148 70132 0 0 8 0 1094 3241 3 2 90 5
2 0 56 3640 36912 67616 0 52 12 52 1087 3264 11 32 54 3
2 0 5376 3556 68 46908 128 5112 128 5112 1125 3381 19 81 0 0
3 2 32736 4024 76 35616 796 27576 864 27580 1164 3055 11 89 0 0
2 2 77380 3832 68 26960 696 44648 984 44664 1100 2818 9 91 0 0
2 2 155356 3928 68 19568 416 77980 664 77984 1090 2708 8 92 0 0
2 9 261120 3436 88 9860 328 105708 856 105712 1098 2695 7 93 0 0
0 17 552496 2348 92 1056 3464 320072 213472 320072 59021 124484 0 83 0 16
[/ltr]



بعد از این قضیه این Colivans که پچ اش رو فرستادم یک Watermark جدید به kswapd اضافه کرد که کرنل Swaping رو وقتی ۲/۳ فضای حافظه فیزیکی اشغال شد شروع کنه . حالا میشه نتیجه گرفت که کرنل Swaping رو وقتی ۸۰ درصد حافظه فیزیکی قابل اختصاص را اختصاص داد شروع به Swaping میکنه و ظاهرا این مشکل دیگه پیش نمیاد ، قبلا گفتم که CFQ و IOSCHE صرفا سرپوشی ان برای این مشکل ، چون همچنان calloc کند کار میکنه و آنقدر سریع که انتظار Swap تخصیص داده نمیشه ، حسن این قضیه فقط اینه که Process دیگه Kill نمیشه .

بحث اینکه چرا سیستم Freeze میشه از اونجایی مرتبط به بحث Swaping میشه که دقیقا وقتی kswapd شروع به کار میکنه سیستم Freeze ، پراسس Kill و Swaping خیلی بدی انجام میشه . موافقم که در هر صورت اجرای اون کد باید با عدم موفقیت روبرو بشه ولی نه وقتی که کرنل Resource کافی در اختیار داره ولی اون رو در اختیار Process قرار نمیده ، با اینکه دلیل منطقی برای این کار وجود نداره . در واقع نتیجه ای که من میخواستم از اون کد بگریم این نبود که پراسس کیل بشه ، درست هم اینه که پراسس کیل نشه چون کرنل حافظه درخواستی روی سیستم فرضی مثال قبلی رو در اختیار داره .

میدونی ، این صرفا بحث اینکه کرنل چقدر میتونه حافظه به پراسس اختصاص بده نیست ، توجه کن که سیستم فرضی ما ۵۱۲ مگابایت رم و ۱ گیگابایت Swap داره . این کد لزوما از جهت تئوریک باید بدون مشکل اجرا بشه ،‌اگر فرض کنیم که کد درخواست ۲ گیگابایت حافظه رو هم داشت ؛لزوما؛ بعد از یک Swaping سالم باید Kill میشد .