3002 אוטווה לינוקס סימפוזיום   בעיני המתבוננת
אורנה אגמון

William Irwin (aka wli): A 2.5 Page Clustering Implementation

שיטה חדשה (לא יציבה עדיין) לטיפול בקטעים גדולים של זיכרון וירטואלי. מכיוון שטבלאות הזיכרון הוירטואלי יושבות בזיכרון הנמוך - זיכרון אמיתי, הן תופסות זיכרון יקר מאד. על ידי שנוי כמות הזיכרון שאליו מצביעים ניתן לחסוך עד 008 M זיכרון נמוך. המשמעות אינה תוספת זיכרון לתוכניות של המשתמש, משום שהזיכרון המדובר נלקח ממרחב הזיכרון של הקרנל- הגרעין (ולא ממרחב המשתמש), אך בהחלט מושג ייעול של פעילות המערכת.

Cliff White (OSDL): Performance Testing the Linux Kernel

LDSO הוא ארגון שמטרתו לקשר בין יצרני המחשבים למפתחי לינוקס. הארגון מסייע לפיתוח לינוקס על ידי בחינת גרסאות חדשות על מגוון מכונות. בהרצאה הודגשה חשיבות צורת הפלט מריצות בוחן- כך שניתן יהיה לנתח את התוצאות באופן ממוחשב אוטומטי, וכן הודגשה החשיבות של קבלת פלט מכל ריצת בוחן, גם אם הריצה לא הסתיימה, נתקעה וכד'. הכלים vocg, vocl (הרחבה של vocg על ידי PTL) מסייעים בבדיקת פרופיל התוכנית. vocg נותן סטטיסטיקה על גישה לשורות קוד. vocl נותן דיווח עבור ריצת בוחן נתונה, אלו חלקים של הקוד כוסו. כמובן שאין המשמעות כי כל המסלולים האפשריים כוסו- רק כי ריצן הבוחן הגיעה לשורות קוד אלו במצב מסויים. MIA 7/9 הן חבילות המיועדות להרצה של ריצות בוחן בכמויות. 9 מריץ עבור משתמש אחד, 7 מדמה מצב של ריבוי משתמשים. MIA נותן פלט של זמן המערכת והמשתמש בריצות הבוחן השונות.

Theodor T'so (IBM): Using a Complex Benchmark to measure and improve Linux Scalability for real-world applications

ט'סו דן בריצות בוחן מטיפוס מיקרו (אשר בוחנות ביצועים של נקודה מסויימת בתוכנית) לעומת ריצות מאקרו (אשר משתמשות בתרחיש סביר מהחיים, אשר מכניס לפעולה מגוון מרכיבים במערכת. כאשר מבצעים הערכה של התוכנית באמצעות ריצות בוחן מאקרו, עלול השנוי בביצועי המרכיב הנבדק להיטמע עקב צווארי בקבוק אחרים, ברורים יותר. חיסרון אחר של ריצות מאקרו הוא כי קשה לייצר ריצת בוחן טובה מלאה. ריצות מיקרו, לעומת זאת, מעודדות מיקרו-אופטימיזצייה: שפורים הניכרים רק בבצועים של ריצת המיקרו, אך זניחים בכל הבט אחר. ריצות אלו אינן מדמות התנהגות אמיתית, ותוצאותיהן עשויות להיות מוטות לחלוטין בגלל נקודת העבודה בה נמצאת המערכת. כמו כן, בעיות בממשקים עשויות להעלם מן העין אם משתמשים רק בריצות מיקרו.

Dave Jones (Suse): Ugly Ducklings- Resurrecting unmaintained code.

דייב ביצע החייאה לקוד שבמשך זמן רב לא היה לו אחראי. הקוד הסתבך עם השנים. כדי לאפשר תחזוקתיות של הקוד, השתמש דייב בעקרונות הבאים: כאשר קטע קוד גדול נמצא בין הוראות fedfi# (כלומר לא תמיד נכלל בקומפילציה), דייב הוציא את קטע הקוד (באופן טיפוסי- מספר שגרות) לקובץ חיצוני, ודאג שקובץ זה יתהדר בפני עצמו. הקובץ נכלל על ידי הוראת edulcni# במקום בו היה קודם. כך ניתן לוודא שכל הקוד עובד (או לפחות מתהדר ללא שגיאות), כולל קוד שבדרך כלל לא נעשה בו שימוש כלל. בוצעה חלוקה של הקוד לשגרות המבצעות פעולה אחת בלבד, כך שברור מן השם מה עושה השגרה.

Tony Luck (Intel): Machine Check Recovery for Linux on Itanium Processors

כתוצאה מקרינה קוסמית, הפרות מתח, קרינת שמש וכד', עשוי להתרחש היפוך ביט בזיכרון המחשב. כמובן שתדירות התופעה גדלה כאשר עוסקים באשכולות מחשבים גדולים. לאיטניום יש יכולת תיקון עצמית לחלק מן השגיאות, הממומשת בחומרה (בלי לערב את מערכת ההפעלה). שגיאות באזורים מסוימים של הזיכרון זקוקות לשיתוף פעולה של מערכת הפעלה וחומרה. למשל, הזיכרון של ה BLT יכול להיות מתוקן אוטומטית על ידי החומרה, אך מערכת ההפעלה צריכה לדאוג לעדכן את ה- ehcac BLT. אם שגיאת זיכרון ארעה בשטח זיכרון של גרעין מערכת ההפעלה, יש צורך בדרך כלל באתחול המחשב. אם השגיאה ארעה בשטח זיכרון של המשתמש, ניתן להרוג את התהליך אשר עושה שימוש בזיכרון הפגוע, או לטפל בבעיה בדרכים אחרות: למשל, אם דף הזיכרון הוא לקריאה בלבד, ויש לו עותק על הדיסק הקשיח, ניתן לטעון אותו מחדש. אם הדף הוא לקריאה וכתיבה יש להרוג את כל התהליכים שחולקים באותו דף (למשל, אם זו ספריה , לדוגמא clib, יש להרוג את כל התהליכים שמשתמשים בשפת C). יש בעיה בזיהוי כל התהליכים החולקים דף. על איטניום, החומרה אחראית להנפת דגל אדום כאשר תהליך של המשתמש (ecape resu) עומד לקרוא מידע שנפגע. בצורה זו ניתן להימנע מהריגת כל התהליכים- הרי ייתכן שהמידע שעבר שנוי לא ייקרא לעולם, ואין צורך להרוג את התהליך. במרחב הגרעין (ecape resu) הבעיה פתוחה- ייתכן שחובה לבצע איתחול.

Patricia A Gaughen (IBM): Linux Support for NUMA hardware

NUMA=Non Uniform Memory Access.
בלינוקס יש תמיכה מיוחדת למעבדים המסודרים בצורה של AMUN, כלומר כך שלכל מעבד יש זיכרון הסמוך אליו יותר מלאחרים. הספריה amunbil שכתב neelK idnA -מ esuS מאפשרת העדפה בקשירת תהליכים וחוטים למעבדים ולחלקי זיכרון מסוימים (ytiniffa UPC). כמובן שכאשר מבקשים להקצות זיכרון מסוים בסמוך למעבד מסוים, הגרנולריות היא של גודל דף זיכרון (בעיקרון K 4). אופטרון, מעבד ה 46 ביט של DMA, מיועד לעבוד בתצורת AMUN. בתצורת PMS הגשר הצפוני נראה כך:
North bridge of SMP
לדבריו של אריך מ- DMA, תכנון של גשר PMS הוא מסובך, ומעטים מסוגלים לעשות זאת טוב. בגשר PMS יש צווארי בקבוק בגישה של המעבדים לגשר למשל: סכום מהירויות הגישה של כל המעבדים לזיכרון חסום על ידי צוואר בקבוק זה. בתצורה אופיינית לאופטרון, הגשר הצפוני של צומת (קבוצת מעבדים סמוכים) נראה כך:
North bridge of NUMA
לכל מעבד יש זיכרון הצמוד אליו. המעבדים מחוברים בתקשורת מהירה מאד, על פי תקן פתוח. ככל שהמעבדים מחוברים ליותר מעבדים אחרים, התצורה יקרה יותר. במכונה מורכבת יותר יהיו מספר צמתים, שמהירות מעבר הנתונים ביניהן מוגבלת יותר. בזימון תהליכים על AMUN עבור CPH (gnitupmoC ecnamrofreP hgiH) יש חשיבות גבוהה לקשירה של תהליכים למעבדים קבועים, כך שהמידע המתאים יימצא בזכרון הסמוך ביותר. ה- reludehcs (1)O משפר את קשירת התהליכים למעבדים, אך מתעלם מרוחב פס של גישה לזיכרון וממיקום הזיכרון ביחס למיקום התהליך.

המשתמש יכול לייעל מאד את ביצועי החישוב אם יקבע ידנית (תוך שימוש בספריה amunbil) את המיקום המועדף מבחינת מעבד וזיכרון עבור התהליך. לשם כך המשתמש צריך להיות מודע לדברים כמו ה - kasm-UPC של המכונה הספציפית בה הוא משתמש. מסכת UPC היא מספר אשר בו כל ביט מתאים למעבד. כך, אם המשתמש מכווין את התהליך לעבוד על מסכת מעבדים 1100, הכוונה היא שהתהליך יכול לעבוד על מעבדים 1 או 2, אך לא על 3 ולא על 4.

המשתמש צריך להיות מודע לטופולוגיית המכונה (אילו מעבדים קשורים ישירות לאילו, מה מרחק הקשתות בין המעבדים שאינם מחוברים ישירות) והעומס על המכונה. כמובן שתכנות כזה אינו פורטבילי. בנוסף לכך, התחייבות יתר שנוצרת על ידי המשתמש ("משתמש שחושב שהוא חכם יותר ממערכת ההפעלה, אך טועה") עשויה לגרום לפגיעה בביצועים.

את ביצועי ה AMUN ניתן לבחון באמצעות מערכת ריצות בוחן בשם hcnebAMUN, אותה אפשר להריץ לבד, או מופרעת על ידי ריצות שונות (למשל על ידי hcnebkcah).

כאשר מערכת ההפעלה רוצה לבצע אופטימיזציה של הרצת תהליכים, יש כמה גורמים סותרים לעתים שיש להביא בחשבון. איזון עומסים דוחף לכך שלא יהיו מעבדים שעומדים בטל. מצד שני, חוטים שחולקים באותו מידע בזיכרון מרוויחים כאשר הם ממוקמים על אותו מעבד (או על מעבדים בקרובים לזיכרון הדרוש). גם כאשר מבוצע פיצול של התהליך ( fork), אם מיוצרים שני תהליכים החולקים בהרבה מאד זיכרון קריאה-בלבד, יש רווח במיקום התהליך החדש על אותו מעבד. מצד שני, אם תהליך אחד יוצר חוטים רבים או מתפצל פעמים רבות, העומס על המעבד הסמוך לזיכרון יהיה גדול מדי, ועדיף להצמיד את התהליכים החדשים למעבדים אחרים.

כרגע אין איזון עומסים התחלתי (כלומר ברגע תחילת הריצה של החוט או התהליך) עבור enolc , krof (יצירת תהליך חדש החולק עותק של הזיכרון) וחוטים של PMnepo. חוטים מבוצעים אוטומטית על המעבד שהריץ את התהליך לו הם שייכים. במהלך פעולת התהליכים, נדגם אורך התור הממתין למעבד (מדי 004 מילישניה על מעבד עמוס, מדי 5 מילישניה על מעבד פנוי), ומבוצע איזון עומסים: מעבדים פנויים יותר מקבלים חלק מן התור הממתין למעבדים עמוסים. כך מבוצעת הגירת תהליכים.

בשלב זה אי אפשר להגר את הזיכרון הדרוש לתהליכים. כאשר עומדים להקצות זיכרון חדש, נשאלת השאלה היכן יש להקצותו. האם על המעבד הנוכחי שמריץ את התהליך? או אולי על המעבד בו הורץ התהליך ברוב הפעמים בהן קיבל זמן חישוב? או על המעבד אליו סמוכים רוב דפי הזיכרון שהתהליך השתמש בהם עד כה? בחירה לא נכונה תוביל לפיזור של הזיכרון: חלקים מהזיכרון של התהליך יישבו בסמוך לכמה מעבדים, ולא יהיה מעבד מיטבי עבור תהליך זה: לא יהיה אף מעבד הסמוך לכל הזיכרון.

מחקר עתידי יעסוק בשאלות הבאות:

Ray Brynt(SGI): Linux Scalability for Large NUMA Systems

ה - xitlA של IGS מכיל כיום 46 מעבדי איטניום 2, המקושרים ביניהם ב IPM מעל זיכרון משותף.מצ"ב רשימת ריצות בוחן מסוגים שונים, שבוצעו לאלטיקס לעומת מספר מחשבים אחרים. בחינת ביצועים שנעשתה למערכות הקבצים 2txe, kcabetirw.3txe, sfrezier, SFX העלתה כי 2txe ו- SFX מתמודדות הרבה יותר טוב עם מערכות גדולות, כאשר ל SFX יש אפילו ביצועים טובים במעט משל 2txe. IGS מצאה את גרסת לינוקס 20.4.2 כגרסה המועדפת ל-AMUN, פרט לכך שהיא מבצעת יותר מדי הגירה של תהליכים.

Paul "Rusty" Russell, keynote speaker: Hanging Out with Smart People

רסטי מנה רשימת כלים שכדאי לדעתו לכל מפתח להכיר:
ספרים מומלצים :
רסטי מנה דרכים לווידוא של שימוש נכון בשגרות (בסדר יורד של עוצמה), כך שאפילו משתמשים שאינם מכירים את הקוד שמאחורי שמות הפונקציות לא יתקשו להשתמש בהן נכון: תכונותיו החשובות של מתכנת על פי לארי וול הן עצלות, חוסר סבלנות והיבריס. רסטי מוסיף לכך את הפחד מסיבוך. כמו כן, רסטי מציין כי קוד שלא נבדק הוא קוד שבור.