תהליך BOOT במערכות הפעלה זמן-אמת מסוג SMP

BOOTמאת: אריק וינשטיין

בעוד יצרני הסיליקון מובילים את המגמה בהחדרת מעבדים מרובי ליבות ליישומי מערכות משובצות (Embedded) נאבקים  מפתחי התוכנה לשמור על הקצב בתחום זה אם לפיתוח מערכות הפעלה, תווכות או יישומים. משוכה עיקרית במעבר לסביבה מרובת ליבות היא הצורך להשתמש באסטרטגיות פיתוח תוכנה חדשות עבור מערכות קיימות.  כתבה זו דנה בדוגמה אחת למעבר כזה – העלאת  התוכנה  במערכת מרובת ליבות הומוגנית (בה הליבות זהות)  ללא השימוש ב- boot-loader (מערכת bare-metal). נתמקד בלהציג את הנקודות הדורשות התייחסות בתהליך ה- boot של מערכת ההפעלה זמן-אמת כמו בניית המחסנית, אתחול  המשתנים הדרושים לגרעין (kernel) של מ”ה וסנכרון בין הליבות בתהליך העלייה.
רוב מ”ה המסחריות כיום נשענות בצורה זו או אחרת על boot-loader לצורך העלאת התוכנה. ה- Uboot נפוץ במיוחד בשימוש עם לינוקס בטווח רחב של מעבדים כמו ARM  או POWERPC. יש היגיון להשתמש כשאפשר בדרך זו אך יש מיקרים שבהם נדרשת מ”ה לעלות לבד למשל מערכות בהם נדרש זמן עלייה מהיר של התוכנה או במקרים בהם אין זיכרון FLASH  לאחסון ה-boot-loader. לבסוף נזכיר גם שמ”ה זמן-אמת שקיימות בשוק לאו דווקא תומכות בשיטה זו של
boot-loading אלא יודעות  לעלות  בצורה עצמית – דבר שמאתגר את המתכננים במעבר לסביבה מרובת ליבות.

תהליך BOOT במערכות SMP
כדי לאפשר מעבר לתהליך ה- boot מסביבת מעבד יחיד למעבד מרובה ליבות SMP, דברים בסיסיים כמו סדר איתחול הזיכרון או בקר הפסיקות, סנכרון בין הליבות ובניית המחסנית – כל אלה צריכים להיפתר ע”י מ”ה.
1.סדר האתחולים:
במערכות SMP יחידת ה- Cache Coherency היא מודול נוסף שדורש אתחול. בדרך כלל המימוש נעשה ע”י פרוטוקול ברמת  ה- bus  שמאפשר לזיכרון ה- cache להיות מעודכן בערכים האחרונים של המשתנים בזיכרון וכל ליבה שלוקחת חלק ב- SMP   צריכה “להירשם” במודול זה. כדי להימנע ממצב שאתחול  זה תלוי בארכיטקטורה ספציפית אלא יהיה כללי יותר, רישום זה של הליבות יכול להיעשות כחלק מאתחול הזיכרון ע”י מ”ה. חיסרון בשיטה זו שבד”כ פקודות  אטומיות מסוג read-modify-write  ניתנות לשימוש רק לאחר אתחול מודול ה-  Cache Coherency, כך שפעולות סנכרון בין הליבות במעבד (ידון מאוחר יותר) לא יכול לעשות שימוש בפקודות אלו לפני אתחול הזיכרון.

דיאגרמה 1 : תהליך ה- boot במערכת הפעלה Nucleus SMP

פרמטר אחר שמשפיע על תהליך ה- boot במעבדים מרובי ליבות הוא הטופולוגיה של המערכת והזמינות של המידע על המבנה הטופולוגי, לדוגמא – כמה ליבות יש בזמן העלייה של המערכת? האם ליבה אחת מסוימת נחשבת לליבה עיקרית במבנה? האם ניתן להוסיף ליבות חדשות בזמן ריצה? התשובות לשאלות אלו לא משפיעות רק על סדר האתחול של היחידות השונות אלא יכולות להשפיע בצורה עקיפה על בניית המחסנית וסינכרונים שונים שבהם נדון בהמשך.
2.בניית המחסנית: במערכת עם ליבה אחת, מחסנית ראשוניתזמנית  בד”כ מאותחלת להמשיך בקוד אל תוך  סביבת  ה-C (שתומכת כבר בהרצת קוד ב- C), לאחר מכן מאותחלת מחסנית קבועה (system stack) שבה משתמשת כל התוכנה. בסביבה מרובת ליבות ניתן לעשות תהליך דומה על כל ליבה בנפרד אך ניתן לממש זו גם בדרך שונה: ליבה “עיקרית” אחת בונה מחסנית זמנית  אחת, וליבה זו בהמשך תבנה את המחסניות הקבועות עבור שאר הליבות. היתרון בשיטה זו שהיא חוסכת קוד על ה-”ליבות המשניות” והם יכולות להשתמש במחסניות אלו ממש בתחילת תהליך ה- boot. ההנחה בשיטה זו היא שתהליך ה- boot של הליבה העיקרית משיג את זה של הליבות המשניות וכן שהליבה העיקרית יודעת את מספר הליבות המשניות בזמן שאלו מחכות לסיגנל start-boot  ממנה.
3. סנכרון בין הליבות: בזמן תהליך ה-boot  יש צורך לסנכרן בין ליבות ה-SMP מפני הליבה העיקרית אחראית על האתחול של המערכת בעוד הליבות המשניות אחראיות על אתחולים הספציפיים להן בלבד. השיטה המקובלת היא ע”י שימוש ב- reset: הליבה העיקרית מבצעת את תהליך האתחול בעוד האחרות נמצאות במצב wait. בשיטה זו נדרש שימוש גם בחומרה והישענות רק על מימוש בתוכנה יכולה להוביל לבעיות.  דוגמא לכך , אם ליבה משנית נמצאת במצב “Wait-For-Event” לצורך קבלת הסיגנל מהליבה העיקרית הרי שמודול הפסיקות שלה צריך גם להיות מאותחל ע”י הליבה הראשית, דבר שלא תמיד אפשרי מאילוצי חומרה.  בנוסף, הליבות המשניות לא יכולות לקבל את הסיגנל הנ”ל דרך הזיכרון  כי ה- cache ובקרי הזיכרון  לא מאותחלים עדיין. נקודה נוספת בסנכרון מנקודת מבטה של הליבה העיקרית, בנקודת זמן שהיא מבצעת  את אתחול ה-kernel של מ”העליה לוודא שהליבות המשניות התקדמו בתהליך ה- boot וגם מוכנות להגדיר processes  או tasks  (הגדרה שגם צריכה להיעשות בשלב אתחול ה- kernel). במקרה זה הזיכרון מאותחל כבר כך שאין בעיה לממש סנכרון זה דרך דגלים בזיכרון.
Nucleus SMP של מנטור גרפיקס מהווה  פתרון לאתגרי התכנון שתוארו למעלה.  תהליך ה- boot  של Nucleus SMP  מתואר בדיאגרמה -1 גם לליבה העיקרית וגם לליבות המשניות.  בחלק העליון, הליבה העיקרית מתחילה ב- reset וממשיכה להתקנת המחסנית הראשונית.  לאחר מכן, השלבים שמסומנים ברקע סגול מסמנים את הפעולות שנעשות ע”י כל הליבות בעוד אלה עם הרקע הכתום נעשים רק ע”י הליבה העיקרית.
Nucleus SMP   לא מסתמך על קבצי scripts לאתחול, כל הנדרש לאתחול סביבת מרובה ליבות נמצא ומנוהל על ידי מערכת ההפעלה עצמה. דבר זה מהווה יתרון בתחזוקתיות וגם בתהליך porting  למעבדים אחרים. עם תהליך boot  כפי שמתואר בדיאגרמה 1, האתגרים בהעלאת המערכת מנוהלים בצורה יעילה וישירה ע”י מ”ה ומאפשרים מעבר חלק יותר מיישומים המשתמשים במ”ה רגילה בליבה אחת לזו התומכת ביישומי – SMP  בסביבה מרובת ליבות.
Nucleus SMP מבוסס בעיקרו על Nucleus OS המוכרת  של מנטור גרפיקס ותומך במעבדים מרובי ליבות כמו ה- Cortex-A9 MPCore  של ARM   המכיל 4 ליבות.
באדיבות אלון טכנלוגיות –
נציגי Mentor Embedded בישראל

תגובות סגורות