CEB - Computer-En-Books.ir - مقاله: مهاجرت دادن وظایف روی بیش‌هسته‌ای‌ها

سایت CEB:ترجمه تخصصی رشته کامپیوتر - معرفی و دانلود کتب انگلیسی رشته کامپیوتر

امتیاز کاربران

ستاره فعالستاره فعالستاره فعالستاره فعالستاره فعال
 

سرویس ترجمه‌ی سایت CEB تقدیم می‌کند: ترجمه‌ی کامل مقاله‌ای با موضوع مهاجرت دادن وظایف در سیستم‌عامل‌های توزیع شده‌ای که روی پردازنده‌های بیش‌هسته‌ای اجرا می‌شوند.

 

«عنوان و چکیده‌ی انگلیسی مقاله»

 

 2013 21st Euromicro International Conference on Parallel, Distributed, and Network-Based Processing

Task Migration for Dynamic Power and Performance Characteristics on Many-Core
Distributed Operating Systems

 

Simon Holmbacka, Wictor Lund, Sebastien Lafond, Johan Lilius
Department of Information Technologies, Abo Akademi University
Joukahaisenkatu 3-5 FIN-20520 Turku
Email: این آدرس ایمیل توسط spambots حفاظت می شود. برای دیدن شما نیاز به جاوا اسکریپت دارید

 

Abstract—Spatial locality of task execution will become more important on future hardware platforms since the number of cores are steadily increasing. The large amount of cores requires more intelligent power management due to the notion of spatial locality, and the high chip density requires an increased thermal awareness in order to avoid thermal hotspots on the chip. At the same time, high performance of the CPU is only achieved by parallelizing tasks over the chip in order to fully utilize the hardware. This paper presents a task migration mechanism for distributed operating systems running on manycore platforms. In this work, we evaluate the performance and energy efficiency of an implemented task migration mechanism. This is shown by parallelizing tasks as the performance of a single core is not sufficient, and by collecting tasks to as few cores as possible as CPU load is low. The task migration mechanism is implemented as a library for FreeRTOS using 1300 lines of code, and introduced a total task migration overhead of 100 ms on a shared memory platform. With the presented task migration mechanism, we intend to improve the dynamism of power and performance characteristics in distributed many-core operating systems.

Keywords-Task Migration, Distributed Operating Systems, Many-Core Systems, ARM Cortex-A9

 

با لینک زیر می‌توانید این مقاله انگلیسی 8 صفحه‌ای را به همراه ترجمه‌ی کامل و صفحه‌بندی شده‌ی آن دریافت کنید (نیاز به اعتبار دانلود دارد):

آیکن نشانگر نوع فایل در سایت CEBدانلود اصل مقاله انگلیسی و ترجمه‌ی آن در قالب PDF با حجم 628KB

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


 

«ترجمه‌ی کامل مقاله»

 

2013 بیست و یکمین کنفرانس بین المللی  Euromicroدر موضوعات پردازش موازی، توزیع شده و تحت شبکه

مهاجرت‌دادن وظایف جهت نیل به خصوصیات پویای (مصرف) انرژی و کارآیی در سیستم‌عامل‌های توزیع شده­‌ی (پردازنده­‌های) بیش­‌هسته‌­ای

چکیده ـ چون تعداد هسته­‌ها مدام در حال افزایش است، محلی بودن مکانی اجرای وظایف(Taskها)، در بسترهای سختافزاری آینده مهم‌تر خواهد شد. فراوانی تعداد هسته‌ها با توجه به مبحث محلی بودن مکانی، مستلزم مدیریت مصرف هوشمندانه‌تری است؛ و ظرفیت بالای تراشه، جهت اجتناب از کانون‌های دمایی روی تراشه، مستلزم هوشیاری بیشتری نسبت به دما است. در عین حال، کارآیی بالای CPU تنها از طریق موازیسازی کارها در سطح تراشه حاصل می‌شود؛ تا بتوان از سختافزار بهطور کامل بهره کشید. این مقاله یک مکانیزم مهاجرتدادن وظایف را برای سیستم‌عامل‌های توزیع شده‌ای که روی بسترهای بیش‌هسته‌ای اجرا می‌شوند، ارائه می‌دهد. در این مقاله، به ارزیابی کارآیی و بهرهوری انرژی یک مهاجرت‌دادن وظایف پیادهسازی شده می‌پردازیم؛ کار به این صورت انجام می‌گیرد که هرگاه کارآیی یک هسته به تنهایی کافی نباشد، وظایف را موازیسازی می‌کنیم و هرگاه بار CPU کم باشد، وظایف را به حداقل تعداد هسته‌ی ممکن جمع‌آوری می‌کنیم. مکانیزم مهاجرت‌دادن وظایف مذکور، با استفاده از 1300 خط کد، به عنوان یک کتابخانه برای FreeRTOS پیادهسازی شده، و روی یک بستر با حافظه مشترک، یک سربار مهاجرت‌دادن وظایف 100 میلی­ثانیه­ای را نشان داده است. با این مکانیزم مهاجرت‌دادن وظایف ارائه شده، قصد داریم که پویایی خصوصیات مصرف انرژی و کارآیی در سیستم‌عامل‌های بیش‌هسته‌ای را ارتقاء دهیم.

 کلمات کلیدی ـ مهاجرت‌دادن وظایف، سیستم‌های توزیع شده، سیستم‌های بیش‌هسته‌ای، ARM Cortex A9

 I. مقدمه

 محلی بودن مکانی منابع، معیاری را برای فاصله­ی بین وظایفِ در حال اجرا و منابع آن‌ها فراهم می‌سازد. این مقدار متناسب است با تأخیر ارتباطاتی­‌ای که، به دلیل جدا بودن مکانی، به وظایف در حال ارتباطات تحمیل می‌شود. در یک پردازنده­‌ی Network-On-Chip(NoC) بیش‌هسته‌ای، هرگاه نیاز باشد که پیام‌هایی درون شبکه­ی مسیردهی تراشه انتشار یابند، این سربار به وضوح دیده می‌شود. هنگام استفاده از ارتباطات بین‌هسته‌ای، برای حصول کمترین سربار ارتباطی ممکن، وظایفِ در ارتباط با هم باید در نزدیک‌ترین فاصله نسبت به هم قرار داده شوند. در یک سیستم ایستا، یک نگاشت بهینه از وظایف را می‌توان در زمان کامپایل انجام داد، اما در یک کامیپوتر مناسب برای کاربردهای عمومی دارای وظایفی با ایجاد شدن، زمان اجرا، تعلیق و ... پویا، جهت دستیابی به کمترین سربار ارتباطاتی می‌بایست وظایف در زمان اجرا روی تراشه مهاجرت کنند.

 کارآیی بالای سیستم معمولاً به‌وسیله‌ی نگاشت وظایف - در برنامه‌های کاربردی موازی - روی چندین هسته ارتقاء می‌یابد تا بهرهوری از سختافزار بالا رود؛ زیرا که چندین عنصر پردازشی قادر خواهند بود تا بخش‌های جداگانه­ی این برنامه کاربردی را به صورت موازی اجرا کنند. از دیگر سو بالابردن کارآیی معمولاً به قیمت قربانی کردن انرژی حاصل می‌شود برخلاف موازیسازی وظایف، جمع‌آوری وظایف به تنها تعداد کمی از هسته‌ها به مدیریت انرژیِ برمبنای حالت sleep این امکان را می‌دهد که هسته‌های بیکار را خاموش کند و سیستمی با بهرهوری انرژی بیشتر را پدید آورد. در هر دو حالت، وظایف باید در زمان اجرا قابل انتقال دادن باشند تا سیستم بتواند برای تدابیر انرژی در مقابل کارآیی بهینه شود.

 دیگر مسألهی مهمی که از محلی بودن اجرای وظایف ناشی می‌شود، توازن دمایی درون تراشه است [2]، [1]. با تغییر مکان اجرای وظایف روی تراشه، این امکان وجود دارد تا از کانون‌های دمایی که می‌توانند به تدریج تراشه را فرسوده کنند، اجتناب گردد. قبلاً کارهایی در قالب زمانبندی وظایف و توزیع دما روی تراشه صورت گرفته است. شکل1 مثالی را نشان می‌دهد از این که نگاشت وظایف چگونه بر گرادیان دمایی CPU اثر می‌گذارد. بخش سمت چپ این شکل، یک نگاشت قویاً موازیسازی شده را نشان می‌دهد که در آن گرما به شکل ملایم‌تری توازن یافته است، و بخش سمت راست، نگاشتی را نمایش می‌دهد که وظایف را تنها در تعداد کمی از هسته‌ها متمرکز می‌کند و یک کانون قرمز رنگ را تشکیل می‌دهد. از روی شکل این نکته واضح است که نگاشت وظایف روی سیستم‌های بیش‌هسته‌ای، طبق موقعیت‌های مکانی وظایف، بر گرما و کانون‌های روی تراشه اثر می‌گذارد. حتی این اثر در تراشه‌های سه‌بعدی[4]  نمود بیشتری می‌یابد؛ چرا که عناصر گرمازا در سه بعد پخش خواهند شد.

 

 شکل1. گرادیان‌های دمایی تراشه­‌ی بیش‌هسته‌ای (قرمز به معنای گرما است). برچسب‌های (g,m) نشانگر گروهِ هسته‌ایِ g و شماره هسته­‌ی m هستند[3].

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

 II. تحقیقات مرتبط

 متوازنسازیِ بارِ کاری (Load Balancing) چندین دهه است که در کرنل‌های لینوکس [5] متعارف روی سیستم‌های چندپردازنده­ای متقارن (SMP) وجود دارد. هدفCFS (زمانبند کاملاً منصفانه‌­ی) لینوکس این است که کار را روی تمام عناصر پردازشی سیستم، تا جای ممکن، متوازن کند [6]. متوازن‌ساز بار کاری لینوکس، یک وظیفه را در صف (آماده به) اجرای یک هسته­‌ی منتخب قرار می‌دهد ولی به هیچ یک از ارجاعات به منابع کرنل، دستی نمی‌زند. مهاجرت‌دادن وظایفی را برای سیستم‌عاملی توزیع شده [9]-[7] ساخته‌ایم که دارای چندین کرنل است؛ بر خلاف محیط‌های لینوکس دارای تک کرنل یکپارچه. تفاوت اصلی میان مقصود ما از مهاجرت‌دادن وظایف و متوازن‌سازی بارِ کاری متداول، انتقال دادن متن (context) وظیفه می‌باشد؛ مهاجرتدادن یک وظیفه میان کرنل‌های سیستم‌عامل، نیازمند انتقال متن بیشتری است، زیرا کرنل‌ها مستقل از هم کار می‌کنند.

 پیش از این روش‌های مهاجرت‌دادن وظایف بسیاری مورد بررسی قرار گرفته‌اند [2]، [12]-[10]، و انتخاب، معمولاً وابسته به این است که چه پیکربندی سختافزاری­‌ای و چه نوعی از سیستم‌عامل به‌کار گرفته شده است. مهاجرت‌دادن وظایف بین حافظه­‌های بهطور فیزیکی از­هم­‌جدا، نیازمند انتقال ناحیه­‌ی حافظه­‌ی هم داده و هم برنامه به مکان حافظه­‌ی جدید است [13]. مهاجرت‌دادن وظایف ناهمگن هم در تحقیق قبلی مورد ملاحظه قرار گرفته است؛ که در آن کد برنامه به منظور پشتیبانی از معماری مقصد تغییر داده می‌شود [14]. این خود چندین چالش دیگر از جمله چینش در حافظه (Memory Alignment)، ارزش مکانی در حافظه (Little Endian و Big Endian) و دستورالعمل‌­های متفاوت را به‌­وجود می­‌آورد.

 برخلاف تحقیق فوق، مکانیزم مهاجرت‌دادن وظایف ما برای یک سیستم‌عامل توزیع شده­‌ی دارای چندین کرنل، که روی یک معماری حافظه مشترک همگن دارای واحد مدیریت حافظه (MMU) اجرا می­‌شود، ساخته شده است. با توجه به این معماری، فقط یک اشاره­‌گر به وظیفه­‌ی مورد نظر، نیاز به انتقال به‌صورت فیزیکی دارد. این بدان معناست که برخلاف [10] و [2]، اندازه­‌ی وظیفه، بر سربار مهاجرتدادن تأثیر نمی‌گذارد.

 قبلاً معانی مختلفی برای مهاجرت‌دادن وظایف و استراتژی‌هایی برای نحوه آغاز کردن مهاجرت‌دادن وظایف ارائه شده است [12]، [19] – [15]. مخصوصاً در [17]، از یک مکانیزم کپی­‌گیری جهت مهاجرت‌دادن وظایف بین هسته­‌های یک سیستم چند‌هسته‌ای استفاده شده است. هرگاه وظیفه‌ای روی یک هسته ساخته شود، روی تمامی هسته‌هایی که این وظیفه می‌تواند به آن‌ها مهاجرت کند هم یک کپی از آن ایجاد می­‌شود. هرگاه نسخه­‌ی اصلی به حالت اجرا برود، این وظایفِ کپی به حالت معلق می‌­روند. وقتی که وظیفه را مهاجرت بدهیم، نسخه‌­ی کپی مربوطه، نقطه­‌ی شروع و حالت خود را دریافت می­‌کند و دقیقاً از نقطه‌ای که وظیفه­‌ی اصلی معلق شده بود شروع به اجرا می‌کند. یک مکانیزم مهاجرت‌دادن وظایف که بر‌مبنای بازتولید عمل می‌کند، در [12] ارائه شده است. استراتژی بازتولید این‌گونه است که یک وظیفه در ابتدا فقط روی هسته­‌ی محلی ایجاد می‌شود؛ هنگام اجرای مهاجرت‌دادن وظایف، وظیفه­‌ی مربوطه کاملاً به هسته­‌ی دیگر کپی شده و از نقطه‌ای که معلق شده بود شروع می‌شود. پس از پایان مهاجرت، وظیفه‌­ی اصلیِ روی هسته­‌ی اول معلق شده و پاک می‌شود.

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

 III. بستر (سختافزاری)

 ما برای تحقیق خود یک بستر بیش‌هسته‌ای را در نظر گرفته‌ایم که دارای هسته­‌های CPUی همگن، حافظه­‌ی مشترک و یکMMU  است. این­ها خصوصیاتی هستند که در بسترهای بیش­‌هسته­‌ایِ بر‌مبنای NoC امروزی به آن‌ها دست یافته­‌ایم [22]-[20]، و بنابراین انتخاب چنین بستری موضوعیت دارد.

 وقتی از این نوع بسترها بهره می‌بریم، معماری کرنل یکپارچه­‌ی استفاده شده در لینوکس شروع می‌کند به دچار مشکلات مقیاسپذیری شدن [23]. علت اصلی این است که به قفل کردن‌های بین‌هسته‌ای داده‌ساختارها در کرنل نیاز خواهد بود [24]. این قفل‌ها برای محافظت داده‌­ساختارها از دسترسی همزمان توسط چندین هسته به‌کار می‌روند ولی وقتی تعداد هسته‌های CPU افزایش می‌یابد تبدیل به یک تنگنا می‌شوند. به عنوان مثال، لینوکس به ازای هر فرآیند از یک mutex کرنل استفاده می‌کند که فراخوانی‌ها به mmap و munmap را به صف می‌کند (به صورت سریال درمی­آورد - در مقابل موازی بودن) [23].

 به جای این (سیستم‌عامل‌ها)، ما بر استفاده از یک سیستم‌عامل توزیع شده به عنوان بستر هدف خود تمرکز می‌کنیم. این ساختار سیستم‌عامل توسط چندین سیستم‌عامل تحقیقاتی پذیرفته شده است؛ از جمله ساختار مالتی­‌کرنل در Barrelfish[7] یا کرنل‌های سیار در helios[8]. هنگام استفاده از یک سیستم‌عامل مالتی‌کرنل، وظایف به جای به اشتراک گذاشتن یک کرنل بزرگ می‌توانند از فراخوانی‌های کرنل بومی هسته­‌ی خود استفاده کنند، در نتیجه، برای فراخوانی‌های کرنل نیازی به ارتباطات هسته­‌به‌­هسته یا spinlock­های بین‌هسته‌ای نخواهد بود. از این جهت این طراحی سیستم‌عامل، بهتر برای برنامه‌های کاربردی شدیداً وابسته به کرنل مقیاس می‌پذیرد[9]، [25].

 مهاجرت‌دادن وظایف ما مشخصاً برای سیستم‌عامل‌های توزیع شده­‌ی (سخت‌افزارهای با) حافظه­‌ی مشترک ساخته شده است. فرض شده است که بستر مورد استفاده، برای اختصاص پشته به وظایف، اختصاص حافظه­‌ی پویا، کد برنامه و تبادل پیام بین­‌هسته‌­­ای میان وظایف، از حافظه­‌ی مشترک استفاده می‌کند. کرنل‌ها می‌توانند در حافظه­‌ی مشترک یا در حافظه­‌ی اختصاصی هسته اجرا شوند. شکل2 ساختار سیستم ما را با استفاده از یک سیستم‌عامل به ازای هر هسته، تعدادی وظیفه و یک مکانیزم مهاجرت‌دادن وظایف (TM) به ازای هر هسته، به نمایش می­‌گذارد. در این مورد کرنل هر سیستم‌عامل در بخشی جداگانه از حافظه­‌ی مشترک قرار دارد.

 

شکل2: ساختار بستر(مورد استفاده) با حافظه‌­ی مشترک برای هم کرنل‌های سیستم‌عامل و هم ارتباطات هسته‌به‌هسته.

نسخه‌ای چند­هسته‌ای از FreeRTOS[26] برایMPCore  از ARM Cortex A9 به عنوان بستر به نمایش گذاشتن این مکانیزم مهاجرت‌دادن وظایف ساخته شده و بهطور رایگان در دسترس است[27] . کرنل FreeRTOS کرنل بلادرنگ کوچکی است که به بسیاری از معماری‌های رایج ترجمه شده است. این کرنل زمانبند بلادرنگی را فراهم می‌کند که روی آن برنامه‌های کاربردیِ با ملزومات بلادرنگ سخت را می‌توان زمانبندی نمود. این RTOS به این دلیل انتخاب شده است که ساده است، سربار کمی دارد و پرتابل می‌باشد.

 بستر استفاده شده، برد Versatile Express [28] مجهز شده به تراشه­ی چهارهسته‌ای CA9 NEC[29] برمبنای ARM Cortex A9 دارای 1GB حافظه­‌ی اصلی است که در فرکانس 400MHZ کار می­‌کند. همانطور که در شکل2 دیده شد، یک نمونه از FreeRTOS به هر یک از هسته­‌ها نگاشت شده است و هر نمونه، تنها وظایف روی هسته­‌ی محلی را زمانبندی می­‌کند. این نمایی از یک سیستم چند­پردازشی نامتقارن (AMP) است که بدین معناست که هر نمونه از سیستم‌عامل (به‌همراه زمانبندش) مستقل از بقیه کار می­‌کند و وظایفِ روی هسته­‌های مختلف، مثل مورد SMP دید یکسانی از سیستم‌عامل را به اشتراک نمی‌گذارند.

 IV. متدولوژی مهاجرت‌دادن وظایف

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

 الف. مفهوم مهاجرت‌دادن وظایف

به این دلیل که مفهوم ما از مهاجرتدادن وظایف، مهاجرت بین کرنل­‌های سیستم‌عامل کاملاً مستقل از هم را شامل می­‌شود، باید از حالت ایمن وظیفه مطمئن باشیم تا در صورت استفاده از I/O یا عملکرد­های کرنلی، مفهوم سازگاری[30] حفظ شود. یک حالت ایمن، حالتی تعریف شده است که در آن تضمین شده است که وظیفه از عوامل خارجی­ای که در انتقال حالتش خلل وارد می­‌کنند، متأثر نمی­‌شود. انتقال خودسرانه­‌ی یک وظیفه ممکن است موجب قطع نابه­‌هنگام منابع وابسته به هسته­‌ای مثل ارتباطات I/O شود؛ که ممکن است سبب از دست رفتن داده یا بروز خطاهای timeout ناخواسته شود. بنابراین قبل از اینکه مهاجرت بتواند اتفاق بیافتد، هر کاربردی از منابع، عملکردهای کرنلی، ارتباطات داخل هسته‌­ای یا هر عملکرد غیرقابل پس­‌گرفتنی، باید به اتمام برسد و یا به صورتی ایمن ملغی شود. به دلیل این عدم قطعیت در برنامه‌­های کامپیوتری، از یک مکانیزم ایست بازرسی استفاده شده است تا نقاطی در برنامه مشخص شوند که در آنها مهاجرتدادن وظیفه ایمن است. ایست بازرسی­‌ها همچنین پیچیدگی مکانیزم مهاجرت‌دادن وظایف را کاهش می­‌دهند؛ زیرا تمام مهاجرت­‌ها در نقاطی کاملاً قابل پیش­بینی انجام می­‌گیرند. برنامه­‌نویس برای اینکه یک برنامه را قابل مهاجرت کند، هنگام ساخت برنامه، این ایست بازرسی‌ها را مشخص می‌­کند. در مدل ما، با یک فراخوانی تابع ساده می‌­توان یک ایست بازرسی را تنظیم نمود؛ TASK_IN_SAFE_STATE(). این نقطه، همان مکان مشخص شده‌­ای است که یک وظیفه می‌­تواند در آن به هسته‌­ی دیگری مهاجرت کند. آغاز مهاجرت‌دادن وظایف به عهده­‌ی خود سیستم یا وظیفه­‌ای دیگر مثلاً یک مدیریت کننده­‌ی مصرف انرژی است. مکانیزم مهاجرت‌دادن وظایف ما، از یک وظیفه‌­ی دیده­‌بان بهره می‌­برد که سناریوهایی را برای مهاجرتدادن وظایف تشخیص می­­دهد. دیده­‌بان می­‌تواند وضعیت دیگر هسته‌­ها را بررسی نماید و تصمیم بگیرد که یک وظیفه را از کدام هسته­‌ی مبدأ به کجا ببرد. گرچه، الگوریتم‌­های بهینه­‌سازی و تصمیم بهینه برای مهاجرت‌دادن وظایف جزئی از این تحقیق نیست.

 تقاضاهای مهاجرتدادن، توسط یک واسط درخواست به اطلاع هر وظیفه­‌ی قابل مهاجرت می­‌رسد؛ که از جانب دیده­‌بان، یک پرچم flag)) درخواست مهاجرتدادن را فعال می­‌کند. این پرچم بهطور منظم توسط وظیفه بررسی می‌شود تا اگر درخواستی داده شده است، به حالت ایمن برسد. برای تحقق مهاجرت‌دادن وظایف، در مدل ما این روال باید به ترتیب دنبال شود:

1)      یک عامل دیده‌بان در سیستم، درخواست مهاجرتدادن وظیفه‌­ی 1 را به هسته­‌ی nام می‌دهد.

2)     واسط درخواست در وظیفه­‌ی1 فراخوانی می­‌شود و پرچم migration_request فعال می­‌گردد.

3) وظیفه‌­ی 1 در برنامه­‌ی کاربردی خود، پرچم migration_request را که حالا فعال شده است، بررسی می‌کند و به کمک تابع TASK_IN_SAFE_STATE() وارد حالت ایمن می­‌شود.

4)     مهاجرت دهنده‌­ی وظایف فراخوانی می­‌شود و وظیفه­‌ی 1 به هسته­‌ی n مهاجرت داده می‌شود.

 ب. مورد کاربرد

 چون ایست بازرسی­‌ها توسط برنامه‌­نویس جای داده می­‌شوند، بایستی سیستم از قبل جهت تعیین یک تأخیرِ درخواست نهایی تحلیل شود. تأخیر درخواست، زمان بین یک درخواست مهاجرتدادن از جانب وظیفه­‌ی دیده­‌بان است تا زمانی که وظیفه­‌ی مورد نظر به حالت ایمن برسد. این زمان با جای دادن ایست بازرسی­‌های مکرر در برنامه کمینه می­‌شود. سرکشی از پرچم درخواست با پرچم –o3 روی CPUی Cortex A9، تنها از سه دستورالعمل استفاده می­‌کند، اما چون رخداد مکررتر ایست بازرسی­‌ها، سربار را به­‌طور چشم­گیری افزایش می‌دهد، باید حساب تکرّر جای دادن ایست بازرسی­‌ها را داشته باشیم.

 

 لیست1. مثالی از ایست بازرسی

لیست1 حلقه­‌ی ساده­‌ای را نشان می­‌دهد که اعدادی را افزایش می­‌دهد و تابع foo() را فراخوانی می­‌کند. پس از هر تکرار حلقه یک ایست بازرسی تنظیم شده است، به این معنا که وظیفه­‌ی حاوی این حلقه می­‌تواند پس از هر تکرار حلقه مهاجرت داده شود. وظیفه­‌ی مربوطه در هر تکرار حلقه، پرچم migration_request را بررسی می­‌کند که بدین معناست که در بدترین حالت، تأخیر مهاجرت (احتمالاً منظور نگارنده همان تأخیر درخواست بوده و اشتباه شده است) برابر زمان یک تکرار حلقه است. نهایت مسئولیت برنامه‌نویس این است که برای دستیابی به کمترین تأخیر درخواست ممکن، ایست بازرسی­‌ها را به طرز هوشمندانه‌­ای تنظیم نماید تا سربار ایست بازرسی­‌ها هم پایین بماند.

 V. پیاده­‌سازی

الف. دید کلی

این مکانیزم مهاجرت‌دادن وظایف، در زبان C بهطور ویژه برای FreeRTOS مجموعاً در 1300 خط کد پیاده‌­سازی شده است. این مکانیزم شامل یک وظیفه‌­ی مهاجرت دهنده می­‌شود که روی هر هسته نگاشت شده است و انتقال فیزیکی و ارتباطات بین­‌هسته‌­ای را بر عهده دارد. کرنل FreeRTOS تغییر داده شد تا از اضافه شدن و خارج شدن پویای وظایف در لیست وظایف پشتیبانی شود و در عین حال حالت وظیفه سازگار بماند. کل تغییرات انجام شده روی FreeRTOS با استفاده از 110 خط کد C پیاده­‌سازی شد. این بخش مهمترین قسمت پیاده­‌سازی را شرح می‌­دهد، یعنی اینکه حافظه چگونه بین کرنل­‌ها مورد استفاده قرار می‌­گیرد و چگونه حالت یک وظیفه بین هسته­‌ها جابجا می­‌شود.

 

ب. نگاشت حافظه­‌ی مجازی

 

به این جهت از حافظه­‌ی مجازی استفاده می­‌شود که جایگزین دیدگاه حافظه­‌ی فیزیکی از سیستم شود و آن‌را با یک نمایش مجازی، که آسان­‌تر می­‌توان با آن کار کرد، عوض نماید. در مدل ما، هر هسته‌ C حاوی یک کرنل K است. تمام کرنل­‌ها از یک فضای حافظه‌­ی مجازی استفاده می­‌کنند، که به این معناست که همه‌­ی کرنل­‌ها دید یکسانی از حافظه دارند؛ این موضوع در قسمت سمت چپ شکل3 دیده می­‌شود. این نمای مجازی، این حقیقت که کرنل­‌ها در واقع در مکان­‌های جداگانه­‌ای از حافظه اجرا می‌­شوند را مخفی و دستخوش تجرید کرده است (قسمت سمت راست شکل3). در چنین محیطی تمام وظایف می­‌توانند فراخوانی­‌های کرنل را با آدرس­‌های ارجاع یکسانی انجام دهند. این باعث افزایش مقیاسپذیری سیستم‌عامل می­‌شود زیرا نیازی به قفل­‌های کرنل بین‌هسته‌­ای نیست بلکه وظایف همیشه کرنل محلی را فراخوانی می­‌کنند. جلوتر در بخش ج مثالی آمده است.

 

شکل3 طرح حافظه را برای پردازنده­ی چهارهسته­ای که قبلاً از آن سخن رفت، نشان می­دهد. وظایف درحال اجرا روی یک کرنل، با ناحیه­ای مشخص از حافظه سروکار دارند به نام GVM (حافظه­ی قابل­رؤیت­از­همه­جا – Globally Visible Memory). مکان این ناحیه وابسته به این است که وظیفه روی کدام هسته (در کدام کرنل) ساخته شده است. برای مثال وظیفه­ای که روی هسته­ی C1 ایجاد شده است، فضای پشته­ی خود را در GVM1 تخصیص می­دهد. GVMها، از دیگر سو، دید یکسانی از حافظه­ی مجازی را فراهم نمی­کنند. این بدان علت است که وظایف باید بتوانند کرنلی که قرار است روی آن زمانبندی شوند را تعویض کنند. حالت وظیفه باید همواره به فضای آدرس حافظه­ی مطلقی اشاره کند که باید مستقل از اینکه وظیفه روی کدام هسته در حال اجراست، سازگار نگه داشته شود. برای مثال وظیفه­ی T1ای را با حافظه­ی پشته­ی GVM1 در نظر بگیرید که از C1 به C2 مهاجرت می­کند. برای این­که حالت سازگار بماند، هرچند T1 به C2 منتقل شده است، باید هنوز ارجاعات به GVM1 را نگهداری کند. حال اگر اشارهگر پشته­یT1 می­بایست من بعد به GVM2 اشاره کند، بدون انتقال فیزیکیِ کل پشته به GVM2، محتوای پشته سازگار نخواهد ماند. چون یک معماریِ با حافظه­ی مشترک را فرض کرده­ایم، این امکان وجود دارد که به­جای یک انتقال کامل، تنها ارجاعات را به GVM مربوطه انتقال دهیم. سربار مهاجرتدادن نیز بسیار کوچکتر خواهد شد زیرا اطلاعات کمتری منتقل می­شود.

 

 

شکل3. طرح حافظه برای یک CPU­ی چهار هسته‌­ای

 

پس از مهاجرتدادن T1 از C1 به C2، اشاره­‌گر مربوطه به GVM1، به K2 گذر داده می­‌شود تا با آن لیست وظایف محلی خود را به‌­روز کند. اگر T1 روی K2 پاک شود، K2 پیغامی را به K1 می­‌فرستد تا حافظه­‌ی اختصاص یافته‌­ای که T1 در GVM1 از آن استفاده می­‌کرد را آزاد کند. در حالت کلی، اگر هسته­‌ای فرمان پاک کردن را روی وظیفه‌­ای اجرا کند که روی یک هسته­‌ی غیرمحلی ایجاد شده است، درخواست پاک کردن به سمت مبدأ آن وظیفه انتشار می­‌یابد تا حافظه­‌ی گرفته شده توسط این وظیفه آزاد شود.

 

حافظه­‌ی رزرو شده برای ارتباطات هسته‌­به‌­هسته (ICC) ناحیه­‌ای است در بالاترین قسمت حافظه که به­‌صورت ایستا تخصیص یافته است و برای گذر دادن پیام­‌ها بین هسته‌­ها استفاده می­‌شود. ارتباطاتِ به وسیله­‌ی متغیر مشترک، از مهاجرت وظایف متأثر نخواهد بود، چراکه آدرس متغیر مشترک در بخش قابل‌رؤیت‌­از­همه­‌جای حافظه قرار دارد و بنابراین می­‌تواند توسط هر وظیفه‌­ای، مستقل از اینکه آن وظیفه روی کدام هسته زمانبندی شده است، دستیابی گردد.

 

ج. انتقال متن (Context)

 

انتقال حالت در مهاجرت یک وظیفه، از انتقال حالت در سیستم­های SMP­ لینوکس پیچیده­تر است زیرا وظیفه به یک نمونه­ی جدید از سیستم­عامل منتقل میشود؛ در حالی که باید حالت آن را ثابت نگه داریم. حالت یک وظیفه، شامل هر موجودیتی است که در آن وظیفه ذخیره شده است و در اجرای آن وظیفه، تعیین کننده است و در زمان اجرا، قابل دستکاری می­‌باشد. در کنار نام و اشاره‌گر تابعی به خود وظیفه، متن زیر هنگام مهاجرتدادن وظیفه منتقل می‌­شود:

1)حالت پشته: در آغاز، بسته به اینکه وظیفه روی کدام هسته ساخته شده است، پشته روی یک GVM مشخص ایجاد می­‌شود. هنگام مهاجرتدادن وظیفه، اشاره­‌گر به محل پشته­، به هسته­‌ی مقصد منتقل می‌­شود. چون فرض کرده­‌ایم که پشته‌­های وظایف در حافظه‌­ی ازهمه­‌جاقابل­‌رؤیت جای دارند، خود پشته به‌صورت فیزیکی جاب­جا نمی­‌شود.

2) حالت هیپ (Heap): تمام متغیرهایی که بصورت پویا تخصیص یافته‌­اند، در هیپ ذخیره شده‌­اند. مشابه پشته، متغیرهای هیپ در GVM هسته­‌ای ذخیره شده‌­اند که وظیفه‌ای که از آنها استفاده می­‌کند روی آن ساخته شده است. وقتی که وظیفه­‌ای مهاجرت داده می­‌شود، اشاره­‌گر ارجاع به تمامی متغیرهایی که به‌صورت پویا تخصیص یافته­‌اند به هسته­‌ی جدید گذر داده می­‌شود، که به این معنی است که مانند حالت پشته، غیر از اشاره­‌گرها، داده‌­ای به­‌صورت فیزیکی جاب­جا نمی­‌شود.

 

3) ارجاعات به توابع: انگیزه‌ای که در پس استفاده از کرنل توزیع شده قرار دارد این است که سیستم‌عاملی مقیاس­‌پذیر برای معماری­‌های بیش­‌هسته‌­ای ساخته شود. یک عملکرد مهم در این معماری آن است که امکان فراخوانی­‌های کرنل بومی هسته فراهم آید. بنابراین تمامی وظایف باید تنها از کرنل محلی برای فراخوانی‌های کرنل استفاده کنند (به شرطی که کرنل مورد نظر بتواند عملکرد درخواست شده را اجابت کند). سیستم نشان داده شده در شکل4 را ملاحظه بفرمایید: وظیفه­‌ی T1 روی هسته­‌ی C1 ساخته شده است و از کرنل K1 برای فراخوانی­‌های کرنل استفاده می‌­کند. پس از مهاجرت وظیفه به C2 ،T1 باید ارجاع کرنل خود را به K2 به‌­روزرسانی کند تا فراخوانی‌­های کرنل بومی هسته داشته باشد.

 

 

شکل4. به­روزرسانی ارجاع کرنل پس از مهاجرت وظیفه

 

برای حصول این عملکرد، (فایل­‌های) باینری elf قابل بازپیوند(Re-link) را برای FreeRTOS پیاده­‌سازی کرده‌­ایم. همگی وظایف به باینری­‌های elf جداگانه‌­ای کامپایل شده‌­اند و با کرنل روی یک هسته پیوند خورده‌­اند. طی مهاجرت‌دادن وظیفه، پیوند بین وظیفه و کرنل قطع می­‌شود و با کرنل روی هسته­‌ی هدف بازپیوند می­‌خورد. ارجاعات حافظه‌­ای به کرنل قبلی تغییری نمی­‌کند، زیرا حافظه‌­ی مجازی نمای یکسانی از حافظه را برای تمامی کرنل­‌ها تضمین می‌­کند (آن­گونه که در شکل3 نشان داده شد). به این طریق، وظایف نیازی ندارند به پیگیری این­که روی کدام هسته نگاشت شده‌­اند؛ که این باعث می­‌شود برای برنامه­‌نویس، برنامه‌­نویسی کاملاً مستقل از مکان (Location Transparent) باشد.

 

4) ارتباطات بین­وظیفه­ای: وظایف در حال ارتباطات به کمک حافظه­ی مشترک، مکان حافظه­ی استفاده شده برای ارتباطات را بدون هیچ تغییری حفظ خواهند نمود. این امر به این دلیل امکان­پذیر است که هر وظیفه­ای در هر زمان می‌تواند به هر GVMای دستیابی انجام دهد. وظیفه­ی مهاجرت داده شده، پس از مهاجرت، آدرس حافظه­ی مشترکی که ارتباطات در آن انجام می­شد را حفظ می­کند.

 

ارتباطاتِ به­کمک انتقال پیام بین وظایف، جزئی از تحقیقات آتی خواهد بود. این عملکرد ساده نیست زیرا مکانیزم انتقال پیام وابسته به (نوع) ارتباطات محلی یا غیرمحلی است. ارتباطات غیرمحلی نیازمند ارتباطات صریح هسته­به­هسته است زیرا وظایفِ در حال ارتباطات، روی هسته­های متفاوتی قرار دارند، در حالی که ارتباطات محلی، برای اجتناب از سربار اضافی، کافی است فقط از مکانیزم صف پیام بهره ببرند.

 

VI. ارزیابی

 

محیط ارزیابی شامل چهار وظیفه­ی جداگانه­ی پخش ویدئو می­شود که روی بستر چهارهسته­ای ARM شرح داده شده در بخش III نگاشت شده‌اند. هر وظیفه، ویدئویی با یک تفکیک­پذیری مشخص را پخش می‌کند. نرخ فریم­ (fps) در بازه­های زمانی منظم اندازه­گیری شد تا کارآیی ویدئو سنجیده شود. ما سیستم را نسبت به هم کارآیی و هم بهره­وری انرژی ارزیابی کردیم تا پویایی ارتقاء یافته­ی سیستم را نشان دهیم. سربار تحمیل شده­ی ناشی از مهاجرتدادن وظایف هم اندازهگیری شد تا بتوان نتیجه­گیری­های نهایی را ارائه داد.

 

چون بستر ارزیابی شده (که در بخش III توصیف شد) به­عنوان بستری کم­مصرف طراحی شده است و به­خودی­خود از کانون­های دمایی رنج نمی‌برد، و چون این بستر به ازای هر هسته اندازه­گیری گرمایی را فراهم نمی‌­آورد، ما اندازه‌­گیری‌­های گرمایی را در آزمایشات خود دخیل نکرده‌­ایم.

 

الف. ارزیابی کارآیی

 

اولین آزمایش برای این اجرا شد تا نشان دهد کارآیی وظایف ویدئویی چه‌طور با موازی­سازی افزایش می­یابد؛ یعنی با مهاجرتدادن وظایف به تمامی هسته­های در دسترس. هدف ما در این تست آن است که برای تمامی چهار ویدئو، به یک پخش ویدئوی پایدار (25fps) برسیم. در آغاز چهار ویدئوی با تفکیک­پذیری بالا به هسته­ی0 روی بستر ARM نگاشت شدند. پس از اندازه­گیری یک نرخ فریم پایین، سه­تا از وظایف ویدئویی به هسته­های دیگر مهاجرت داده شدند تا سیستمی حاصل شود که به ازای هر هسته، یک وظیفه­ی ویدئویی دارد. در وظیفه­ی ویدئویی، به ازای هر فریم یک نقطه­ی حالت ایمن گنجانده شده است که باعث شده است به کد منبع (Source Code) برنامه­ی کاربردی 11 خط اضافه شود.

 

شکل5 اجرای این تست را نشان می­دهد. در آغاز تست (بازه­ی زمانی 1 تا 3)، تمام ویدئوها با نرخ فریمی بین 6 تا 14 فریم بر ثانیه پخش می­شوند، که برای رضایت کاربر بسیار پایین است. در لحظه­ی 3، وظیفه­ی ویدئویی اول (Video1) به هسته­ی دیگری مهاجرت داده می­شود، که منجر به افزایش نرخ فریم Video1 در لحظه­ی 5 می­شود، و همچنین نرخ فریم بالاتری برای باقیمانده­ی وظایف روی هسته­ی0. به­طور مشابه در زمان 6، Video2 مهاجرت داده می­شود و در نتیجه در زمان9 به نرخ فریم رضایت­بخش می­رسد. در نهایت Video3 در زمان 13 مهاجرت می­کند و در زمان 14 کاملاً پایدار است. قله­ی بالاییِ وظیفه­ی مهاجرت نکرده (Video4) به­دلیل مکانیزم جاانداختن فریم­ها است که برای تحمل نرخ فریم پایین در ابتدای تست استفاده شده است.

 

در لحظه­ی 14 تمامی ویدئوها به هسته­ی مخصوص خود نگاشته شده­اند و تمام وظایف ویدئویی بصورت کاملاً موازی به اجرا درآمده­اند. با موازی‌سازی وظایف و بهره­وری بهتر از سختافزار، همه­ی ویدئوها به نرخ فریم تقریباً 25 فریم بر ثانیه رسیدند و پس از لحظه‌­ی 18 یک پخش پایدار را حفظ نمودند.

 

 

شکل5. نرخ فریم­‌های ویدئوهای با تفکیک­‌پذیری بالا که به چهار هسته مهاجرت داده شدند. مهاجرت‌دادن وظایف در لحظه­‌ی 3 آغاز شده است. نقاط 1، 2 و 3 نشان دهنده­‌ی نقاط مهاجرت در طول زمان هستند.

 

ب. ارزیابی مصرف انرژی

 

آزمایش دوم برای این انجام شد که ظرفیت‌­های باالقوه‌­ی بهره­‌وری انرژی را که مهاجرت‌دادن وظایف می­‌تواند سبب بروز آن­ها شود، نشان دهد. در این آزمایش، ما کار را با چهار ویدئوی با تفکیکپذیری پایین که هر یک روی یک هسته­‌ی همان بستر ARM چهارهسته‌­ای نگاشت شدند، شروع کردیم. مصرف انرژی مستقیماً از روی یک رجیستر داخلی در تراشه­‌ی Cortex A9 MPCore خوانده می­‌شود. هدف ما در این تست این است که در عین پایدار نگه داشتن نرخ فریم‌­ها، اتلاف انرژی را تا جای ممکن کم کنیم. از نقطه­‌ی شروع که چهار ویدئوی موازی داشتیم، همگی وظایف ویدئویی به یک هسته (Core0) مهاجرت داده شدند. هسته­‌های بیکار باقیمانده (Core2، Core1 و Core3) خاموش بودند چون پس از مهاجرت، وظیفه‌­ای روی آن­ها نگاشت نشده بود.

 

شکل6 نرخ فریم‌­ها و انرژی مصرفی مربوطه را برای این آزمایش نشان می­‌دهد. منحنی­‌های مرتبط با ویدئوها، بر حسب محور نرخ فریم­‌ها رسم شده‌­اند و منحنی اتلاف انرژی، برحسب محور انرژی رسم شده است. آزمایش با پخش ویدئوها روی نرخ فریم 25fps آغاز می­‌شود که برای کاربر کافی است، با اینحال تفکیک­‌پذیری پایین فرمت ویدئوها به ما این امکان را می‌­دهد که همه‌­ی ویدئوها را به یک هسته جمع‌­آوری کنیم. داخل شکل6 در لحظه­‌ی 7 مکانیزم مهاجرت‌دادن وظایف شروع می­‌کند به جمع‌­آوری ویدئوها به صورت تک‌تک به هسته‌­ی 0 و در لحظه‌­ی 12 این عملیات را به پایان می­‌رساند.

 

این شکل نشان می­‌دهد که چگونه مصرف انرژی در ابتدا از حدود 900mW شروع به کاهش می­‌کند تا تقریباً 550mW پس از مهاجرت‌دادن وظایف به هسته‌ی0. این (کار) به‌­وضوح مصرف انرژی این بستر را تحت­‌تأثیر قرار می­‌دهد؛ چون مصرف انرژی 40% کاهش یافته است. همچنین شکل6 نشان می­‌دهد که هسته­‌ی0 به تنهایی قادر است، هنگام پخش معمولی، نرخ فریم کافی 25fps را برای هر چهار ویدئو حفظ کند. هنگام مهاجرتدادن، وظایف ویدئویی مهاجرت داده شده، اندکی افت نرخ فریم را نشان می­‌دهند، اما هنوز کیفیت کلی کافی حفظ شده است.

 

 

شکل6. نرخ فریم­‌های ویدئوهای با تفکیک­‌پذیری کوچک که به یک هسته مهاجرت داده شدند و انرژی مصرفی Cortex A9. مهاجرت‌دادن وظایف در زمان 7 آغاز شده است. نقاط 1، 2 و 3 نشانگر نقاط مهاجرت در طی زمان هستند.

 

ج. سربار مهاجرتدادن

 

مهاجرت‌دادن وظایف قدری سربار را بوجود می­‌آورد که ناشی است از انتقال داده و اضافه کردن و خارج ساختن وظایف در زمانبند سیستم­‌عامل. ارزیابی ساده‌ای برای اندازه‌گیری سربار کل انجام داده شد تا نشان داده شود، این امکان وجود دارد که یک وظیفه‌­ی جریانی مثل یک پخش کننده‌­ی ویدئو را بدون اختلال قابل توجهی مهاجرت داد. سربار تعریف شده‌­ی ما از مهاجرتدادنِ یک وظیفه، بصورت زمان بین معلق کردن وظیفه روی هسته­‌ی فرستنده تا ادامه به اجرای (Resume) وظیفه روی هسته­‌ی هدف اندازه‌­گیری می­‌شود. این سربار در سه قسمت اندازه‌­گیری می­‌شود:

 

1)      زمان خارج ساختن وظیفه (از زمانبند سیستم‌عامل مبدأ) و فعال­‌سازی ارتباطات بین‌هسته‌­ای (بین هسته‌­ی مبدأ و مقصد)

 

2)      زمان انتقال داده در کانال بین‌هسته‌­ای

 

3)      زمان بین رسیدن داده­‌ی بین‌هسته­‌ای و اضافه نمودن وظیفه (به زمانبند سیستم­‌عامل مقصد)

 

قسمت­های 1 و 3 با یک زمانبند tic-toc ساده که زمان طی شده بین tic و toc را طی تیک­‌های سیستم­‌عامل می­‌شمارد، اندازه­‌گیری شده و به آسانی به میلی ثانیه تبدیل شد. قسمت 2 (تأخیر ارتباطات بین­‌هسته‌­ای)، با یک کتابخانه­‌ی آماده­‌ی ارتباطات بین­‌هسته‌­ای برای FreeRTOS، اندازه­‌گیری شد. این کتابخانه از وقفه­‌های بین­‌هسته­‌ای برای همگام­‌سازی زمان بین دو کانال بین­‌هسته‌­ایِ درحال ارتباطات استفاده می­‌کند، زیرا کلاک‌­های هسته­‌های متفاوت یکسان نیستند. اندازه­‌گیری­‌ها چندین بار اجرا شدند و انحراف نتایج، برای هر سه قسمت، صفر بود. سربار کل در جدول1 آمده است. این جدول نشان می­‌دهد که قسمت 3، که شامل اضافه کردن وظیفه به زمانبند سیستم‌­عامل جدید می­‌شود، در انتقال هر یک از وظایف ویدئویی ما بیشترین سربار را ایجاد کرده است. یک علت این امر آن است که وقتی وظیفه به یک هسته‌­ی جدید با یک کش L1 سرد انتقال می­‌یابد تعداد missهای کش L1 افزایش می­‌یابد. برای کاهش این سربار می‌­توان سیستم را طوری تنظیم کرد که قبل از ادامه­‌ی اجرای وظیفه، خطوط کش را گرم کند. رهیافت دیگری برای کاهش این سربار آن است که کش L2 را فعال کنیم (که در این آزمایشات خاموش بود). خارج‌سازی وظیفه (قسمت 1) با تنها 17ms کمترین سربار را داشته است، و انتقال فیزیکی داده 38ms سربار داشته است. انتقال داده شامل (استفاده از فایل) باینری پروتکل آماده‌­ای برای ارتباطات بین­‌هسته­‌ای می­‌شد که ما را بر تحلیل همگام­‌سازی کلاک قادر ساخت ولی تحلیل سربار مکانیزم داخلی آن به­‌دلیل متن­‌باز نبودن آن ممکن نبود.

 

 

جدول1. اندازه­‌گیری سربارها

 

یک مقایسه­‌ی عادلانه با مکانیزم­‌های مرتبط چندان سرراست نیست، زیرا متدولوژی­‌ها، بسترها و مفهوم مهاجرت وظایف معمولاً متفاوت است. برای مثال یک معماری NUMA – با زمان دستیابی به حافظه‌­ی نایکدست (Non-Uniform Memory Access) – در مهاجرت یک وظیفه به مقصدی واقع در مکانی دورتر، تأخیر بزرگتری را نشان خواهد داد. جدای از این‌ها، با سربار ایجاد شده، پخش ویدئو برای کاربر بسیار روان بود و اندک انجماد بوجود آمده طی مهاجرتدادن وظیفه­‌ی یک ویدئوی 25fps به سختی به چشم می‌­آمد. این مکانیزم مهاجرت‌دادن وظایف در کل 160 بایت به برنامه­‌ی کاربردی اضافه نمود، که مربوط می­‌شود به 40 دستورالعملی که باید اجرا می‌­شدند (با فلگ –o3 از gcc).

 

VII. نتیجه‌­گیری­‌ها

 

این مقاله خصوصیات پویای کارآیی و مصرف انرژی مهاجرت‌دادن وظایف را برای سیستم­‌عامل­‌های توزیع شده‌­ی (پردازنده­‌های) بیش‌هسته‌ای نشان داد. یک مکانیزم مهاجرت‌دادن وظایف ارائه و ارزیابی شد تا از طریق موازیسازیِ وظایف، به بیشینه کارآیی سیستم دست پیدا کنیم و از طریق بهره‌کشی حداکثری از سختافزار فعال و خاموش کردن سختافزار بیکار، به صرفه‌جویی در انرژی برسیم. با یک مجموعه از وظایف ویدئویی مربوط به یک مورد کاربرد که در آن مفهوم کیفیت خدمات حائز اهمیت است، یک مکانیزم مهاجرت‌دادن وظایف را ارزیابی نمودیم. در آزمایشات، مثالی متداول را نشان دادیم که در آن صرفه جویی در انرژی قابل توجهی را به قیمت قربانی کردن مقدار ناچیزی از کارآیی خریدیم. نکته کلیدی در سیستم‌عامل‌های توزیع شده این است که برای اجرای مؤثر بخش‌های مختلف سیستم‌عامل از موقعیت‌های مکانی (مختلف) بهره ببریم.

 

در مطالعه موردی، ما نشان دادیم که موقعیت مکانی یک وظیفه‌­ی شدیداً وابسته به CPU چگونه بر کارآیی و مصرف انرژی اثر کاملاً مستقیم دارد. در سیستم‌های بیش‌هسته‌ای NoC بزرگتر و (دارای سختافزارهای با انواع) متنوع‌تر، بخش‌های مختلف سیستم‌عامل توزیع شده را می‌توان با توجه به عملکردشان به نزدیکی سختافزار مربوطه نگاشت کرده و مهاجرت داد. برای مثال بخش‌های شدیداً وابسته به شبکه را باید در نزدیک‌ترین فاصله نسبت به رابط فیزیکی شبکه نگاشت نمود و بخش‌های شدیداً وابسته به حافظه را باید در نزدیکی کنترلگر‌های حافظه نگاشت نمود.

 

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

 

VIII. تحقیقات آتی

 

وظایفی که از ارتباطات بین‌وظیفه‌ای بهره می‌برند نیازمند آن هستند که اگر یکی از وظایفِ در حال ارتباطات، موقعیت مکانی خود را تغییر دهد، ارجاعات خود را برای انتقال پیام‌ها بهروزرسانی کنند. ارتباطات هسته‌به‌هسته بایستی صریحاً به وظایف طرف ارتباطات که روی هسته‌های مختلف قرار دارند، منتسب شوند؛ حال آن که وظایف روی یک هسته می‌توانند از صف‌های پیام ساده استفاده کنند. به منظور پوشاندن این جزئیات از برنامه‌نویس، ما یک چارچوب کاری قطعه‌ای سبک‌وزن را برای سیستم‌های بلادرنگ تولید کردیم[31] . با این چارچوب کاری، توسعه دهنده قادر است تا برای ارتباطات بین‌وظیفه‌ای، رابط‌های ارتباطاتی ویژه‌ای را تنظیم کند که می‌توان از آن‌ها برای ارتقاء سطح انتزاع در ارتباطات بین‌وظیفه‌ای بهره گرفت. ما قصد داریم به منظور ساده کردن بهروزرسانی ارجاعات ارتباطات، امکان مهاجرتدادن وظایف را به این چارچوب کاری اضافه کنیم.

 

همچنین این مکانیزم مهاجرت‌دادن وظایف، فعلاً از متوازن‌سازی بارِ کاری پشتیبانی نمی‌کند. متوازن‌سازی بارِ کاری مستلزم یک مکانیزم تصمیم‌گیری است که قادر باشد تصمیم بگیرد که در چه زمانی چه وظیفه‌ای باید به کدام هسته انتقال داده شود. مکانیزم مهاجرت‌دادن وظایف (ارائه شده در این مقاله) باید همچنین روی یک بستر بیش‌هسته‌ای بزرگ‌تر ارزیابی شود تا مزایای واقعی جابجایی مکانی وظایف را به نمایش بگذارد.

 

سپاسگزاری­‌ها

 

این تحقیق توسط پروژه­‌ی RECOMP (هزینه جوازدهی کاهش یافته، با استفاده از بسترهای چندهسته‌ایِ مورد اعتماد) از Artemis JU حمایت شده است (توافق‌نامه­ی اعطای کمک هزینه­‌ی شماره 100202).

 

(عناوینِ) مراجع

 

1. سیاست‌های قابل سازگاری مهاجرت‌دادن وظایف برای کنترل دمایی در MPSoCها(سیستم‌های روی تراشه­ی چندپردازنده‌ای)

2. سیاست متوازن­سازی دمایی برای بسترهای محاسباتِ جریانیِ (Stream Computing) چندپردازنده‌ای

3. متوازنسازی سختافزاری بارِ کاری برای معماری‌های چند‌هسته‌ای عظیمی که گذردهی انرژی (Power Gating) را پیادهسازی می‌کنند

4. بررسی راهکارهایی برای خنک­سازی توده‌های تراشه‌ای سه بعدی

5. درون زمانبند لینوکس

6. درون زمانبند کاملاً منصفانه‌­ی لینوکس2.6

7. مالتی­‌کرنل: معماری جدیدی برای سیستم‌عامل‌های چندهسته‌ای مقیاسپذیر

8. Helios: چندپردازشی ناهمگن با کرنل‌های سیار

9. Corey: سیستم‌عاملی برای بیش‌هسته‌ای‌ها

10. سیستم‌عامل بلادرنگ توزیع شده­‌ی Bag و مهاجرت‌دادن وظایف

11. مهاجرت‌دادن وظایف جهت تحملپذیری خطا در سیستم‌عامل‌های توکار دارای سطوح مختلف حساسیت(Mixed-Critical)

12. پشتیبانی از مهاجرت‌دادن وظایف در سیستم‌های روی تراشه­‌ی (SoCهای) چندپردازنده­ای: یک مطالعه­ی امکان سنجی

13. مهاجرتدادن پویای وظایف از ماشین مجازی SIMD به ماشین مجازی SPMD

14. مهاجرتدادن اجرا در یک چندپردازشگر تراشه‌ایِ دارای معماری‌های مجموعه دستورالعمل (ISAهای) ناهمگن

15. پشتیبانی از مهاجرتدادن وظایف در معماری با توجه به MPSoC

16. ارزیابی اثر مهاجرت‌دادن وظایف بر کاربردهای چندرسانه‌ایِ جریانیِ(Streaming) بلادرنگ‌نرم توکار

17. پیادهسازی مهاجرت‌دادن وظایف چندپردازشگره در یک بستر قابل بازپیکربندی

18. استراتژی‌های تخصیص وظیفه­‌ی پویا در MPSoC برای کاربردهای بلادرنگ نرم

19. مهاجرتدادن فرآیندهای ناهمگن: سیستم TUI

20. ارتباطاتMPI  بین پردازنده‌های با معماریMIC با استفاده از mvapich2: تجربیات اولیه

21. یک پردازنده­ی انتقال پیام 48 هسته‌ای با معماری 32 بیتی اینتل (IA-32) مجهز به مقیاس‌دهی پویای ولتاژ و فرکانس(DVFS) با استفاده از (تراشه­های) CMOS با تکنولوژی 45 نانومتری

22. معماری اتصالِ روی تراشه­‌ی پردازنده­‌ی کاشی‌وار (Tile)

23. تحلیلی از قابلیت مقیاسپذیری لینوکس به هسته‌های فراوان

24. قابلیت مقیاسپذیری لینوکس در چندهسته‌ای­‌ها

25. سیستم‌عامل‌های دسته‌بندی شده (FOS): گزینه‌­ی مناسب برای یک سیستم‌عامل مقیاسپذیر برای چند‌هسته‌ای‌ها

26. راهنمای مرجع FreeRTOS: توابعAPI  و گزینه‌های پیکربندی

27. نسخه­‌ی MPCore Cortex A9 از FreeRTOS

28. راهنمای مرجع فنی CoreTile Express a9x4

29. راهنمای مرجع فنی Cortex A9

30. مصاف با مسائل سازگاری برای بهروزرسانی سیستم‌های توزیع شده در زمان اجرا

31. یک چارچوب کاری غنی از قطعات سبک‌وزن برای سیستم‌های بلادرنگ توکار



برای دانلود کتاب، ثبت درخواست ترجمه، و دریافت رایگان خبرنامه‌های سایت نیاز به ثبت نام دارید.

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

هم اکنون! سايت CEB را به چند نفر از دوستان خود هم معرفی کنيد؛ با اين کار علاوه بر حمايت از ما، به بالا رفتن کيفيت خدمات و پايين ماندن تعرفه‌ی دانلود هم کمک کرده‌ايد.



dear author and publishers!
If you do not agree that your books be freely available through this site to Iranians - Those who are not subject to the Copy Right law - please contact us through your official email address so that we can identify you as the author or publisher of that books and remove all your books that you don't like to be accessible through this site. Note that only downloadable material can be appeared on this website. Also note that this site is not the source of illegal publication of the books; We only gathered the books accessible via the Internet together and maked these books more accessible to Iranians.


Valid XHTML 1.0 Transitional