- קוהרנטיות מטמון מבטיחה שכל העותקים של אותם נתונים במטמונים שונים וב-RAM יישארו עקביים במערכות מרובות ליבות.
- היררכיית המטמון עם רמה אחרונה משותפת מפשטת את בקרת העקביות ומפחיתה גישה ישירה לזיכרון הראשי.
- פרוטוקולי קוהרנטיות משתמשים באסטרטגיות של ביטול העתקה או עדכון, הנתמכות על ידי מצבים וביטים בקרה לכל שורת מטמון.
- המהדר ומערכת ההפעלה יכולים להשלים את עקביות החומרה על ידי הוספת הוראות וקביעת תצורה של זיכרון לתקופות קריטיות.
כשמסתכלים על תרשים של כל מעבד מרובה ליבות מודרני, תמיד מופיעה אותה תבנית: ליבות מרובות, לכל אחת מטמונים סמוכים משלה, ומטמון משותף ברמה האחרונה שפועל כנקודה משותפת לפני שהוא מגיע ל-RAM. סידור זה אינו מקרי או גחמה של המתכננים, אלא תגובה ישירה לבעיה קריטית במערכות מקבילות: קוהרנטיות מטמון.
ללא מנגנון עקביות חזק, כל ליבה עלולה בסופו של דבר לעבוד עם גרסה שונה ומיושנת של אותם נתונים בזיכרון , מה שמתבטא בתוכנית בעולם האמיתי בשגיאות עדינות, כשלים בלתי צפויים ואפילו קריסות מערכת. לכן, הבנת האופן שבו עקביות זו נשמרת - הן ברמת החומרה והן ברמת התוכנה - היא המפתח להבנת הביצועים והיציבות של מעבדים מרובי ליבות מודרניים.
מהי קוהרנטיות מטמון: מטאפורת הטרמינל
דמיינו כמה אנשים שיושבים מול מסופים שונים, כולם עורכים את אותו מסמך המאוחסן בשרת מרכזי . כל מסך מציג עותק של הקובץ, וכל שינוי שאדם אחד מבצע צפוי להשתקף באופן מיידי על המסכים של כולם.
כדי שזה יעבוד, צריך להיות מנגנון סנכרון שמפיץ שינויים במסמך לכל הטרמינלים, כך שכולם תמיד יראו את אותה גרסה. כל עוד מערכת זו פועלת, הכל בסדר: מי שמשנה את הטקסט יודע שכולם יראו את הגרסה החדשה כמעט באופן מיידי.
עכשיו דמיינו שמערכת הסנכרון נכשלת פתאום. כל אדם ממשיך לערוך, משוכנע שהוא עובד על המסמך המשותף, אך במציאות, כל מסוף נותר עם עותק מקומי מנותק משלו . מאותו רגע ואילך, שינויים שבוצעו על ידי אדם אחד אינם מגיעים לאחרים, והמסמך מתחיל להתפצל ללא שליטה.
בתחום המחשוב, זה בדיוק מה שהיה קורה אם למעבד היה חסר פרוטוקול עקביות אמין: ליבה אחת משנה נתונים בזיכרון, אך הליבות האחרות ממשיכות לקרוא גרסה ישנה יותר מהמטמונים הפרטיים שלהן . זה יוצר קרקע פורייה לשגיאות לוגיות חמורות, נתונים פגומים והתנהגות פתרון באגים.
לכן, קוהרנטיות מטמון היא קבוצת המנגנונים המבטיחים שבמערכת מרובת ליבות, כל העותקים של אותם נתונים המפוזרים על פני המטמונים וה-RAM השונים ישמרו על מצב עקבי . גם אם קיימים עותקים מרובים, המערכת חייבת להתנהג "כאילו" היה רק אחד.
מטמונים והיררכיית זיכרון במעבד מרובה ליבות
מטמוני מעבד (CPU) הם זיכרונות קטנים ומהירים מאוד המחזיקים עותקים של חתיכות RAM הנמצאות בשימוש תכוף . כאשר המעבד מבצע קוד, במקום לגשת באופן רציף (יחסית איטי) ל-RAM, הוא מנסה לקרוא ולכתוב ל-cache, ובכך להפחית באופן דרסטי את זמן ההשהיה.
הטריק, כמובן, הוא שקובצי מטמון אינם מאחסנים את "הגרסה הרשמית" של הנתונים, אלא רק העתק זמני . בהתאם למטאפורת הטרמינל, RAM יהיה המסמך בשרת, בעוד שקובצי מטמון יהיו המסכים המקומיים המציגים עותקים של חלקים מסוימים של הקובץ.
במעבד מרובה ליבות, התכנון הופך למורכב יותר מכיוון שלכל ליבה יש בדרך כלל מטמונים פרטיים משלה ברמה 1 (L1) ואפילו ברמה 2 (L2) . מעל אלה, נוסף מטמון משותף ברמה 3 (לדוגמה), הממוקם בין הליבות לבקר הזיכרון המספק גישה ל-RAM.
מטמון משותף זה נוצר מכיוון שמתן אפשרות לכל הליבות לגשת ישירות ואינטנסיבית ל-RAM יגרום לקונפליקטים בגישה, מתח על אפיק הזיכרון וירידה משמעותית בביצועים . מטמון ברמה האחרונה משמש כ"מאגר" משותף שמפחית גישות ל-RAM ומרכז חלק ניכר מתעבורת הנתונים.
יתר על כן, ארכיטקטורות רבות מארגנות מטמונים באופן כוללני: שורות המאוחסנות ברמות קרובות למעבד קיימות גם ברמות גבוהות יותר של ההיררכיה . כלומר, שורה המופיעה ב-L1 נמצאת גם ב-L2, ובתורה, ב-L3. יש לכך השלכה שימושית מאוד לעקביות: עדכון נכון של המטמון ברמה הנמוכה ביותר מספיק כדי לשלוט במצב הרמות האחרות מבלי שיהיה צורך לגשת כל הזמן ל-RAM.
מדוע אחסון במטמון משותף ברמה האחרונה הוא המפתח לעקביות
ללא מטמון ברמה האחרונה הגלובלי הזה, כל ליבה תצטרך לבדוק עקביות ישירות מול הזיכרון הראשי . בכל פעם ששורת זיכרון במטמון פרטי שונתה, יהיה צורך לבדוק אם ליבות אחרות שומרות עותק של אותה שורה, ואם כן, לעדכן או לבטל אותה בכל מקום.
במערכת עם ליבות רבות, עומס עבודה זה של בדיקות יביא למספר עצום של עסקאות לזיכרון ה-RAM , ובכך יבטל חלק ניכר מהיתרון של מטמונים מהירים. על ידי הצבת מטמון משותף בין הליבות לזיכרון, המעבד יכול לרכז את בקרת הקוהרנטיות במיקום ביניים יחיד.
במימושים רבים, המטמונים ברמות גבוהות יותר (רחוקות יותר מהמעבד) מכילים עותקים של השורות הקיימות ברמות הקרובות יותר לליבה . עם ארגון זה, פרוטוקול הקוהרנטיות צריך רק להבטיח שהרמה האחרונה מסונכרנת עם הזיכרון הראשי, ושהרמות הפרטיות של כל ליבה מסונכרנות עם הרמה שמעליה.
ניתן לדמיין זאת כמעין בובת קינון רוסית: המטמון ברמה השלישית כולל את תוכן הרמה השנייה והראשונה , הרמה השנייה כוללת את התוכן שלה ואת זה של הרמה הראשונה, והרמה הראשונה מכירה רק את השורות שלה. לפיכך, על ידי שליטה ב"בובה הגדולה" (הרמה האחרונה), המערכת יכולה לתאם את השאר בצורה יעילה יותר.
התוצאה היא ששמירה על עקביות הופכת לחסכונית יותר מבחינת עיצוב ותעבורת זיכרון . במקום לאלץ כל ליבה להתמודד כל הזמן עם זיכרון RAM, הפרוטוקול פועל על המטמון המשותף ומשם מנהל אילו שורות יש לעדכן או לבטל במטמונים הפרטיים.
שיטות עדכון: ביטול ועדכון עותקים
בעיה קריטית מתעוררת כאשר שתי ליבות או יותר רוצות לגשת, כמעט בו זמנית, לאותה שורת נתונים המשוכפלת על פני מספר מטמונים . בהקשר זה, מערכות עקביות משתמשות בדרך כלל בשתי אסטרטגיות בסיסיות בעת טיפול בכתיבות.
השיטה הראשונה מבוססת על ביטול תוקף. כאשר ליבה צריכה לכתוב לשורת מטמון ספציפית, הפרוטוקול מבטל כל עותק של אותה שורה שעשוי להיות קיים במטמונים אחרים . רק הליבה שעומדת לכתוב שומרת את השורה במצב של קריאה וכתיבה; האחרים, אם הם רוצים להשתמש בנתונים אלה שוב, יצטרכו לטעון מחדש את השורה מהרמה הגבוהה יותר (או מהזיכרון) עם הגרסה המעודכנת.
האסטרטגיה השנייה כוללת עדכון. במקרה זה, כאשר ליבה משנה שורה, המערכת מנסה להפיץ באופן אוטומטי את התוכן החדש לעותקים קיימים במטמונים אחרים . בדרך זו, כל המטמונים שאחסנו את השורה מקבלים את הגרסה המעודכנת מבלי שיהיה צורך לבטל אותה ולטעון אותה מחדש מאוחר יותר.
לכל גישה יתרונות וחסרונות. ביטול תוקף (invalidation) בדרך כלל יעיל יותר כאשר כתיבות הן תכופות, משום שהוא מונע רוויה של מערכת הזיכרון בעדכונים שליבות אחרות עשויות שלא להזדקק להם באופן מיידי. לעומת זאת, עדכון יכול להיות יתרון כאשר ליבות רבות קוראות לעתים קרובות את אותם נתונים שמשתנים בתדירות נמוכה יחסית , מכיוון שהוא מפחית את ההשהיה בכך שאין צורך לטעון מחדש את השורה לאחר כל ביטול תוקף.
בכל מקרה, שתי השיטות משתמשות במצבים נוספים ובסיביות בקרה בקווי המטמון. כל שורה כוללת בדרך כלל מידע האם התוכן שלה תואם לזה שב-RAM , והאם היא משותפת, שונה, בלעדית, שמורה וכו', בהתאם לפרוטוקול הספציפי (MESI, MOESI, MSI וכו'). זה מאפשר לחומרה לקבל החלטות מהירות לגבי מה לעשות כאשר מתרחשת פעולת קריאה או כתיבה על שורה שכבר משוכפלת.
בדיקת עקביות בין מטמונים לזיכרון
אימות ישיר של העקביות בין כל רמות המטמון של המעבד או הכרטיס הגרפי (GPU) והזיכרון הראשי יהיה משימה אדירה, הן מבחינת מורכבות התכנון והן מבחינת עלות הביצועים. לכן, מערכות מודרניות מארגנות אימות זה בצורה היררכית.
זיכרון המטמון הקרוב ביותר למעבד (L1, L2) אינו מחובר בדרך כלל ישירות לזיכרון ה-RAM, אלא לרמה הבאה של המטמון. משמעות הדבר היא שעקביות אינה מאומתת מול הזיכרון הראשי בכל רמה, אלא מול הרמה הגבוהה יותר . זה מפחית את מספר הגישות ל-RAM ומפשט את הלוגיקה הנדרשת ברמות נמוכות יותר.
בסופו של דבר, ההשוואה בין תוכן המטמון לתוכן ה-RAM מתבצעת בין המטמון ברמה האחרונה לזיכרון הראשי . אם רמה אחרונה זו שומרת על מצב תקין ועקבי, וכל רמה נמוכה יותר שומרת על עקביות עם זו שמעליה, כל ההיררכיה נשארת עקבית מבלי שיהיה צורך לבדוק כל שורה מול ה-RAM שוב ושוב.
כאשר ליבה כותבת לשורת מטמון ומשנה את הנתונים שלה, מצב השורה מסומן כדי לציין שהיא כבר לא תואמת במדויק את העותק המאוחסן בזיכרון . משם, הפרוטוקול מתאם את העדכון: הוא מסמן את העותקים המתאימים במטמונים אחרים כשמורים או לא חוקיים, וכאשר מתאים, כותב את התוכן החדש לשורת הזיכרון הראשית המשויכת.
ארגון מדורג זה מאפשר לשינויים להתפשט בהדרגה מהליבה, אשר מעדכנת את הנתונים, אל הזיכרון הראשי, ועוברים דרך כל רמת מטמון בצורה מבוקרת. בדרך זו, שמירה על עקביות אינה הופכת לצוואר בקבוק בלתי עביר עבור המעבד.
קוהרנטיות חומרה לעומת קוהרנטיות תוכנה
עד כה דנו במנגנוני עקביות המיושמים בעיקר בחומרה: פרוטוקולים, ביטים של סטטוס, מטמונים משותפים וכו'. עם זאת, ישנה גישה נוספת המבקשת להעביר חלק מהמורכבות הזו לתוכנה , ובפרט למהדר ולמערכת ההפעלה.
סכמות עקביות מבוססות תוכנה מנסות להפחית את הצורך בלוגיקה נוספת על השבב על ידי ניתוח קוד וקבלת החלטות בזמן הקומפילציה . הרעיון הוא שאם המהדר יכול להסיק מתי וכיצד נגישה לנתונים משותפים מסוימים, הוא יוכל, במקרים רבים, למנוע אחסון נתונים אלה במטמון או לנהל במפורש את הנראות שלהם.
לגישה זו יש יתרון ברור: חלק מעומס העבודה עובר מפתרון בזמן ריצה לפתרון בזמן קומפילציה . במקום שהחומרה תזהה ותטפל בכל הקונפליקטים תוך כדי תנועה, המהדר מנסה לצפות אותם וליצור קוד שימנע מצבים מסוכנים.
החיסרון הוא שניתוח קוד סטטי מוגבל, ולכן מהדרים נוטים להיות שמרנים . משמעות הדבר היא שכדי להימנע מהפרת עקביות, הם מקבלים לעתים קרובות החלטות שמפחיתות את יעילות המטמון. אם הם חושדים שנתונים מסוימים עשויים להיות בעייתיים, הם מונעים לעתים קרובות את שמירתם במטמון או כופים סנכרון בתדירות גבוהה יותר מהנדרש.
לכן, למרות שתוכניות תוכנה אלו מושכות בתיאוריה, במיוחד לפישוט תכנון חומרה, בפועל הן אינן מחליפות את תמיכת הקוהרנטיות המשולבת במעבד עצמו , אלא משלימות אותה בתרחישים ספציפיים.
תפקיד המהדר בעקביות המטמון
מרכיב מפתח בגישות עקביות מבוססות תוכנה הוא תפקידו של המהדר. המהדר יכול לבצע ניתוח מעמיק של הקוד ולקבוע אילו מבני נתונים משותפים עשויים להיות לא בטוחים לאחסון במטמון . בהתבסס על כך, הוא מסמן אלמנטים אלה בצורה מיוחדת או מתאים את יצירת הקוד.
הגישה הפשוטה ביותר, וגם השמרנית ביותר, היא למנוע אחסון במטמון של משתני נתונים משותפים . כלומר, כל גישה למשתנים אלה כופה גישה לזיכרון הראשי או לאזור שאינו ניתן למטמון. זה מבטיח עקביות, אך מחמיץ הזדמנויות ביצועים רבות, מכיוון שלמעשה ניתן להשתמש במבנה משותף באופן פרטי בתקופות מסוימות, או לקריאה בלבד בתקופות אחרות.
במציאות, בעיית העקביות מתעוררת רק במרווחי זמן שבהם לפחות תהליך אחד יכול לכתוב למשתנה ותהליך אחר יכול לקרוא אותו . מחוץ לתקופות קריטיות אלו, ניתן להתייחס למשתנה כאל המשתנה לשימוש בלעדי של הליך יחיד או אפילו כקבוע אפקטיבי לזמן מה, מה שמאפשר לו להיות מאוחסן במטמון ללא בעיות.
אסטרטגיות הקומפילציה המתקדמות ביותר מנסות לזהות את התקופות "הבטוחות" שבמהלכן ניתן להתייחס למשתנה המשותף כלא מתנגש . לשם כך, המהדר מנתח נתיבי ביצוע, גישות בו-זמניות אפשריות ודפוסי סנכרון (נעילות, מקטעים קריטיים וכו'). בהתבסס על ניתוח זה, הוא מחלק את חיי המשתנה לשלבים: חלקם מתאימים לאחסון במטמון, אחרים דורשים טיפול מיוחד.
במהלך תקופות קריטיות, כאשר מתגלה גישה בו-זמנית עם כתיבות, המהדר מוסיף הוראות נוספות לקוד שנוצר כדי לאכוף עקביות במטמון . הוראות אלו עשויות לאלץ ניקוי מטמון, טעינת זיכרון מחדש, מחסומי זיכרון או גישה לאזורים המסומנים כלא ניתנים לאחסון במטמון, בהתאם למודל התכנות ולארכיטקטורה הבסיסית.
הקשר בין מהדר, מערכת הפעלה וחומרה
הביטוי "המהדר מוסיף הוראות לקוד שנוצר כדי לאכוף עקביות במטמון" עשוי להוביל לחשוב שמערכת ההפעלה קוראת את ההוראות הללו כאילו היו רמזים ברמה גבוהה , ועל סמך זה, מחליטה כיצד להפעיל את התוכנית. במציאות, המנגנון שונה במקצת.
כאשר המהדר מוסיף הוראות מסוג זה, מה שהוא מכניס לקובץ הבינארי הן פעולות ספציפיות הנתמכות על ידי הארכיטקטורה או סביבת זמן הריצה . לדוגמה, הוא יכול להכניס הוראות לניקוי מטמון, מחסומי זיכרון, הוראות מיוחדות לסימון אזורים כלא ניתנים לאחסון במטמון, או קריאות לשירותי מערכת הפעלה שמגדירים תכונות זיכרון.
מערכת ההפעלה אינה מפרשת הוראות אלה כ"הערות" או "רמזים" ברמה גבוהה שנכתבו על ידי המהדר; היא פשוט מבצעת את קוד המכונה כמו כל קוד אחר . עם זאת, חלק מההוראות הללו נועדו לתקשר עם תת-מערכת הזיכרון וניהול המטמון, ובכך לשנות את אופן הגישה של המעבד לנתונים מסוימים.
במילים אחרות, המהדר מבצע ניתוח ראשוני ומייצר קוד שכאשר הוא מבוצע, מייצר את התנהגות המטמון הרצויה . מערכת ההפעלה משתפת פעולה על ידי יצירת תכונות זיכרון (אזורים הניתנים לאחסון במטמון או שאינם ניתנים לאחסון במטמון, מדיניות כתיבה וכו') ומתן פרימיטיבים של סנכרון, אך היא אינה "קוראת" הוראות מיוחדות במובן של פירושן סמנטית כפי שהיה עושה מהדר.
ייתכן גם שהחומרה, עם ראיית הוראות מסוימות, מפעילה מנגנוני קוהרנטיות או סנכרון ספציפיים . לדוגמה, הוראות גדר או מחסום מבטיחות את סדר הגישה לזיכרון ואוכפות אפקטים מסוימים של נראות על פני היררכיית המטמון. במקרה זה, קיים שיתוף פעולה תלת-כיווני: המהדר מחליט היכן למקם את ההוראות הללו, מערכת ההפעלה מגדירה את סביבת הביצוע, והחומרה מיישמת את ההתנהגות בפועל ברמת המטמון ואפיק הזיכרון.
יחד, כל האלמנטים הללו מבטיחים שגם עם עותקים מרובים של אותם נתונים המפוזרים על פני מטמונים שונים וזיכרון ראשי, תוכניות מקבילות יפעלו עם מודל זיכרון עקבי . קוהרנטיות מטמון, רחוקה מלהיות פרט פנימי פשוט של המעבד, הופכת למרכיב מרכזי עבור מערכות מרובות ליבות כדי לפעול בצורה אמינה ויעילה.
הבנת האופן שבו היררכיית מטמון, פרוטוקולי קוהרנטיות חומרה וטכניקות תמיכה בתוכנה משתלבות מבהירה מדוע עיצובים מודרניים של מעבדים חולקים מבנה דומה כל כך, ומדוע כשל קטן בכל אחד מהמנגנונים הללו יכול לעורר התנהגות כאוטית ביישומים בו-זמניים התלויים לחלוטין בכך שכל הליבות יראו את אותם נתונים בזמן הנכון.