אריק וינשטיין
תכנון מערכות משובצות מחשב המבוססות על ריבוי ליבות (Multi-Core) הופך למקובל היום. השילוב בין כמה ליבות יכול להתבצע על אותו סיליקון (SoC), על אותו כרטיס או כל שילוב בין השניים. זה לא סוד שפיתוח תוכנה בסביבה מרובת ליבות מציבה אתגרים בפני המפתחים אם מבחינת תכנון עם חלוקת משאבים אופטימלית בין הליבות ואם מבחינת כלי הפיתוח וניפוי שגיאות. הבשורה המעודדת באה מכיוון החברות המובילות בתחום מערכות Embedded שהתארגנו והקימו את ארגון ה- Multi-Core Association שמטרתו להגדיר תקנים ופתרונות לאתגרים הכרוכים בפיתוח מערכות משובצות בסביבה מרובה ליבות כמו MCAPI ו – MRAPI. מטרת כתבה זו היא לתאר את תקן MCAPI שפותח והוגדר ע”י ה- MCA לתקשורת בין ליבות קרובות.
במה שונה מערכת EMBEDDED מרובת ליבות ממערכות (High-Performance Computing) מרובות ליבות אחרות כמו חוות שרתים במרכזי מחקר או אפילו מחשב שולחני מרובה ליבות?
אחד ההבדלים העיקריים הוא התנהגות זמן-אמת הנדרשת ממערכת EMBEDDED. במערכות HPC כמו חוות שרתים, מעבר ההודעות בין השרתים או הצמתים נעשה ע”י פרוטוקולים מבוססי רשת כמו MPI, שבהם ההשהיה (latency) לא קבועה וזמני התגובה לא תומכים בביצועי זמן-אמת (מילי-שניות ופחות). הבדל נוסף משמעותי נוסף שקיים במערכות EMBEDDED הוא אילוצי הספק וגודל פיזי מחמירים יותר.
נזכיר 2 מושגי ייסוד בתחום ריבוי ליבות:
SMP או Symmetrical Multiprocessing: היא מערכת שמורכבת בצורה הומוגנית מליבות באותה ארכיטקטורה שהם מבוקרים ע”י עותק (Instance) יחיד של מערכת ההפעלה שעושה חלוקת עומסים בין הליבות במערכת. ארכיטקטורת ה- SMP שימושית במיוחד כאשר המעבר לסביבה מרובת ליבות נעשה עקב הצורך בכח חישוב נוסף כמו לדוגמא במחשבים אישיים.
AMP או Asymmetrical Multiprocessing היא מערכת שיכולה להכיל ליבות בארכיטקטורות שונות (הטרוגנית) וכל ליבה מריצה את המערכת הפעלה שלה (למשל ליבה אחת מריצה LINUX והאחרת RTOS ) . דוגמה למערכת כזו יכול להיות ציוד רפואי שבו נעשית חלוקה של קוד בין 2 מעבדים על מנת להוריד את עלויות הרישוי: האחד מריץ קוד שדורש רישוי לפי תקנים רפואיים ואילו השני מריץ קוד שלא דורש רישוי.
ציור-1 דוגמה לטופולוגייה של מערכת מרובת ליבות המיישמת תקן MCAPI
דוגמא לקוד איתחול :
והקמת קשר:
תקן MCAPI
MCAPI הוא תקן שמגדיר את הממשק (APIs) להעברת מידע בין הליבות במערכות מסוג AMP. התקן הראשון פורסם ע”י ארגון ה- MCA ב- 2008 ולאחרונה שוחררה גירסת 2.0 שלו. המטרה העיקרית של תקן זה היא לקבוע תאימות ברמת קוד מקור (Source Code) בין סביבות ומערכות הפעלה שונות תוך מתן גמישות לאופטימיזציות בביצועי זמן-אמת ו או דרישות זיכרון, 2 פרמטרים החשובים במערכות משובצות. חשוב להבין שתקן ה- MCAPI הוא לא פרוטוקול כי אם ממשק ברמת קוד מקור ומטרתו לאפשר תאימות של אפליקציות לסביבות שונות שמיישמות ותומכות בתקן זה (portability).
עקרונות ומושגים בתקן – MCAPI
במודל הבסיסי ביותר של תקן ה- MCAPI כל ליבה מוגדרת ומיוצגת כצומת (node) במערכת. כאשר צומת מסויימת רוצה לתקשר עם צומת אחרת, היא מגדירה נקודת קצה או endpoint שתוכל לשלוח או לקבל מידע.
צומת מאופיינת בשלושה תתי כתובות או אובייקטים שיוצרים ביחד כתובת ייחודית:
Domain – המורכב מצומת אחת או יותר בטופולוגיית של ריבוי ליבות, לכל DOMAIN יש את domain_ID שלו.
צומת (node) – שמוגדרת כתהליך בלתי תלוי בתוכנה או בחומרה , לדוגמה Process או Task של מערכת הפעלה, מערכת הפעלה עצמה או הליבה כולה. יישום מסויים של תקן ה- MCAPI גוזר מהי התכולה של הצומת – האם זה הליבה כולה או אולי רק תהליך בתוכנה.
מיספור ה- domains והצמתים של MCAPI נעשה בשלב התכנון והגדרת הטופולוגיה של המערכת מרובת הליבות ולא בזמן ריצה.
Endpoint: שהיא נקודת קצה בצומת בדומה לתקשורות שמבוססות Socket. כל צומת יכולה להכיל Endpoint אחת או יותר והיא מוגדרת ע”י שלשה מזהים: <domain_ID , node_ID, port_ID>.
מושג חשוב נוסף הוא ערוץ (channel) שמגדיר קשר חד-כיווני עם חוצצים (buffers) בין 2 endpoints.
כדי להגדיל את הגמישות, תקן MCAPI מגדיר שלשה סוגי תקשורת להעברת מידע בין הצמתים במערכת: העברות מסוג Connectionless והעברות שהם Connection-Oriented
1. Messages – העברת חבילת מידע מ- endpoint אחת לשנייה ללא כל הכנת ערוץ מוקדמת. צורה זו גמישה ביותר אך גם איטית יותר ובעלת תקורה (overhead) גבוהה.
2. ערוץ Packet: ערוץ עם FIFO חד-כיווני מ- endpoint אחת לשנייה להעברת חבילות מידע באורך משתנה ברצף (stream) וזאת לאחר שהוקם קשר בין הנקודות (Connection – Oriented)
3. ערוץ Scalar: דומה מאד לערוץ Packet אולם מעביר מילת מידע יחידה (יכולה להיות 8, 16, 32 או 64 ביט).
תקן MCAPI מגדיר את הממשק עצמו אך לא את המדיה דרכו נעשית התקשורת (לדוגמה דרך זיכרון משותף או על גבי Ethernet). מימוש MCAPI ע”י Mentor Embedded נעשה דרך זיכרון משותף שמוסיף מימד של מהירות לליבות שנמצאות על גבי אותו סיליקון.
שיקולים במימוש MCAPI:
כשבאים לממש את התקן צריך לבחון את הדרישה לביצועי זמן אמת – האם להשתמש באלוקציה דינמית של זיכרון או לא?
התאמת התוכנה למערכות הפעלה ופלטפורמות שונות – האם להשען בצורה חזקה על מערכת הפעלה ספציפית או לאפשר פורטביליות (portability)?
הגדרה וקנפוג המערכת בצורה סטטית בזמן התיכנון כפי שדורש התקן ולא בזמן ריצה.
סדר וצורת איתחול המערכת בסביבת מרובת ליבות (מי נטען ראשון, במקרה של זיכרון משותף – מי מתחל אותו לצורך התקשורת בין הליבות).
חלק מהפונקציות שמגדיר התקן הם חוסמות (blocking) – ולכן נדרש מנגנון השהיה של tasks שבד”כ מסופק ע”י מערכת ההפעלה אך לא חייב (ביישום עבור מ”ה NUCLEUS נעשה שימוש בשרות של Events שמסופק ע”י מ”ה בעוד ביישום ל- Linux נעשה שימוש במשתנים מותנים).
מנטור גרפיקס שהיא חברה בארגון MCA מימשה את תקן ה- MCAPI גם למערכת הפעלה זמן – אמת Nucleus וגם ל- Linux. את המימוש ל- Linux פתחה מנטור לקהיליית המפתחים כקוד פתוח שניתן להורידו ב- www.openmcapi.org. המימוש לשתי מערכות ההפעלה מתאפיין בצריכת זיכרון נמוכה ובעצם מהווה נדבך משלים למערכות מסוג AMP שנמצאות בשימוש נרחב.
באדיבות
אריק וינשטיין
אלון טכנולוגיות
