1. ניהול זיכרון  מבוא : מטרות ניהול הזיכרון.  מנגנונים : מרחב כתובות וירטואלי / פיזי. ניהול טבלת הדפים. מדיניות החלפת דפים.

2. Spring 03 חגית עטיה © מערכות הפעלה, שקף 2 ניהול הזיכרון  מערכת ההפעלה צריכה לנהל את השימוש בזיכרון : חלק מהזיכרון מוקצה למערכת ההפעלה עצמה. שאר הזיכרון מתחלק בין התהליכים הרצים כרגע. כאשר תהליך מתחיל צריך להקצות לו זיכרון. כאשר תהליך מסיים, ניתן לקחת בחזרה זיכרון זה.  מערכת ההפעלה צריכה למנוע מתהליך גישה לזיכרון של תהליכים אחרים.

3. Spring 03 חגית עטיה © מערכות הפעלה, שקף 3 Swapping  זיכרון של תהליך שאינו רץ מועבר לדיסק (swap- out).  כאשר תהליך חוזר לרוץ, מקצים לו מחדש מקום ומביאים את הזיכרון שלו (swap-in). דורש מנגנון תמיכה... זיכרון המשתמש זיכרון מערכת הפעלה P3P3 דיסק זיכרון ראשי (פיזי) P2P2 P1P1 P1P1 P2P2

4. Spring 03 חגית עטיה © מערכות הפעלה, שקף 4 מרחב הכתובות של התהליך ( תזכורת ) 0x00000000 0xFFFFFFFF address space code (text segment) static data (data segment) heap (dynamic allocated mem) stack (dynamic allocated mem) Program Counter Stack Pointer

5. Spring 03 חגית עטיה © מערכות הפעלה, שקף 5 מרחב הכתובות של התהליך  בעיקרון, כל מרחב הכתובות צריך להיות זמין בזיכרון הפיזי של המחשב, כאשר התהליך רץ... כתובת של 32 ביטים  מחשב עם זיכרון פיזי בגודל 2 32 = 4GB?... ומה עם דרישות הזיכרון של תהליכים אחרים ?  האם תהליך באמת צריך את כל הזיכרון הזה ?... בכלל משתמש בו ?  השטח הכולל שבשימוש קטן בהשוואה למרחב הזיכרון כולו  מקצים זיכרון רק אם משתמשים בו.

6. Spring 03 חגית עטיה © מערכות הפעלה, שקף 6 חיסכון בזיכרון  האם תהליך באמת צריך את כל הזיכרון הזה כל הזמן ?... ואם השתמש פעם אחת, האם ייגש אליו שנית ?  קוד איתחול.  מחסנית שגדלה מאוד, ואז קטנה.  זיכרון דינאמי משוחרר על - ידי התהליך  משתנים שמשתמשים בהם רק בשלב מסוים של הקוד  עקרון הלוקליות : תהליך ניגש רק לחלק מזערי של הזיכרון שברשותו בכל פרק זמן נתון  צריך לאחסן ערכים של משתנים, גם אם לא משתמשים בהם... אבל לא בזיכרון הפיזי !

7. Spring 03 חגית עטיה © מערכות הפעלה, שקף 7 זרוק אותו לדיסק ! הדיסק מכיל חלקים מהזיכרון של תהליך שרץ כרגע. צריך לזכור מה נמצא בזיכרון הפיזי ואיפה ( ונמצא בדיסק ). צריך לבחור מה להעביר לדיסק. צריך לזכור איפה שמנו חלקי זיכרון בדיסק, כדי לקרוא אותם בחזרה, אם נצטרך אחר - כך. זיכרון המשתמש P3P3 דיסק זיכרון ראשי (פיזי) P1P1

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

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

10. Spring 03 חגית עטיה © מערכות הפעלה, שקף 10 שיטה ישנה : חלוקה קבועה  מערכת ההפעלה מחלקת את הזיכרון הפיזי לחתיכות בגודל קבוע SIZE שיכולות להכיל חלקים ממרחב הכתובות של תהליך.  לכל תהליך מוקצית חתיכת זיכרון פיזי. מספר התהליכים הרצים ≤ מספר החתיכות. זיכרון ראשי (פיזי) P1P1 P2P2 P3P3 P4P4 base p base v זיכרון וירטואלי של תהליך P 2 (בדיסק)

11. Spring 03 חגית עטיה © מערכות הפעלה, שקף 11 תרגום כתובות בחלוקה קבועה  תירגום כתובת וירטואלית לכתובת פיזית : רגיסטר base P אשר מחזיק את כתובת הבסיס הפיזית של התהליך שרץ במעבד רגיסטר נוסף base V מציין את כתובת הבסיס של החלק ממרחב הכתובות של התהליך שרץ, שנמצא כרגע בזיכרון הפיזי כתובת וירטואלית va נמצאת בזיכרון הפיזי אם היא בתחום של [base V, base V +SIZE) אם לא, צריך להביא את החתיכה המתאימה מהדיסק .. או שגיאה, אם אין חתיכה מתאימה כתובת פיזית = (va – base V ) + base P.

12. Spring 03 חגית עטיה © מערכות הפעלה, שקף 12 החלפת דפים עם חלוקה קבועה  בהחלפת חתיכות זיכרון של אותו תהליך, מציבים ברגיסטר base V את כתובת התחלת החלק הוירטואלי החדש שנטען לזיכרון  זיכרון התהליך גדול מהזיכרון הפיזי.  הזיכרון הכולל של כל התהליכים גדול מהזיכרון הפיזי.  בהחלפת תהליך, מציבים ברגיסטר base P את כתובת התחלת החתיכה הפיזית שבה נמצא הזיכרון של התהליך החדש  הגנה מפני כתיבה לזיכרון של תהליכים אחרים... כמו כן, מציבים ב - base V את כתובת החלק הוירטואלי המתאים של התהליך החדש

13. Spring 03 חגית עטיה © מערכות הפעלה, שקף 13 בעיות עם חלוקה קבועה  החלפה של חתיכת זיכרון שלמה בבת אחת.  עבודה עם כתובות זיכרון רציפות : אם גדול מספיק להכיל כל מה שצריך ( וגם מה שבאמצע ),  כל החלפה לוקחת הרבה זמן. מאפשר מעט חתיכות שונות  מעט מידי תהליכים רצים בו - זמנית.

14. Spring 03 חגית עטיה © מערכות הפעלה, שקף 14 שברור פנימי דרישות זיכרון שונות לתהליכים שונים. חלק מחתיכת הזיכרון של התהליך מבוזבז ( internal fragmentation) P1P1 P2P2 P3P3 P4P4 P5P5

15. Spring 03 חגית עטיה © מערכות הפעלה, שקף 15 שיטה ישנה נוספת : חלוקה משתנה  הרחבה של השיטה הקודמת, על - ידי תוספת רגיסטר המציין את אורך החתיכה.  מונע שיברור פנימי...  כמה מקום להקצות לתהליך שמגיע ?

16. Spring 03 חגית עטיה © מערכות הפעלה, שקף 16 שיברור חיצוני שאריות מקום בין החתיכות שלא מתאימות לכלום. external fragmentation P1P1 P2P2 P3P3 P4P4 P5P5 P6P6

17. Spring 03 חגית עטיה © מערכות הפעלה, שקף 17 שיטה מודרנית : דפדוף  מחלקים את הזיכרון הוירטואלי לדפים בגודל קבוע (pages). גדולים מספיק לאפשר כתיבה / קריאה יעילה לדיסק. קטנים מספיק לתת גמישות. גודל טיפוסי = 4K.  הזיכרון הפיזי מחולק למסגרות (frames) בגודל דף זיכרון מדומה זיכרון פיזי דיסק

18. Spring 03 חגית עטיה © מערכות הפעלה, שקף 18 דפדוף  כל מסגרת בזיכרון הפיזי יכולה להחזיק כל דף וירטואלי.  כל דף וירטואלי נמצא בדיסק.  חלק מהדפים הוירטואליים נמצאים בזיכרון הפיזי. זיכרון מדומה זיכרון פיזי דיסק

19. Spring 03 חגית עטיה © מערכות הפעלה, שקף 19 מנגנון התרגום  צריך למפות מכתובת וירטואלית לכתובת פיזית ( בזיכרון הראשי או בדיסק ). איזה דף נמצא איפה ? ומהר... דורש תמיכת חומרה. זיכרון מדומה זיכרון פיזי דיסק מנגנון מיפוי / תרגום

20. Spring 03 חגית עטיה © מערכות הפעלה, שקף 20 טבלת הדפים  אחת לכל תהליך.  כל כניסה בטבלת הדפים מתייחסת למספר דף וירטואלי זהו האינדקס של הכניסה. ומכילה מספר מסגרת פיזית זהו ערך הכניסה.  לכתובת יש שני חלקים : מספר הדף (Virtual Page Number). offset ( מיקום בתוך הדף ).

21. Spring 03 חגית עטיה © מערכות הפעלה, שקף 21 מיפוי  ה VPN מהווה מצביע לטבלת הדפים ומאפשר למצוא את מספר המסגרת שבו נמצא הדף ( Physical Page Number ). הוספת ה offset נותנת את הכתובת עצמה. כתובת וירטואלית Virtual page #offset Page frame # כתובת פיזית Page frame #offset Page table

22. Spring 03 חגית עטיה © מערכות הפעלה, שקף 22 דוגמא  כתובת וירטואלית של 32- ביט. מרחב הכתובות מכיל 2 32 כתובות (=4GB).  דפים עם K4 (= 2 12 ) כתובות. 12 ביטים ל - offset. 20 ביטים ל - VPN. כתובת וירטואלית תתורגם ל 00000000011100000000110000000000 00000000100100000000110000000000

23. Spring 03 חגית עטיה © מערכות הפעלה, שקף 23 כניסות בטבלת הדפים מכילות גם מידע ניהולי, בנוסף למיקום הדף הפיזי :  valid bit: האם הכניסה רלוונטית. מודלק כאשר הדף בזיכרון, כבוי אם הדף נמצא רק בדיסק.  reference bit: האם ניגשו לדף. מודלק בכל גישה לדף.  modify bit: האם הייתה כתיבה לדף. בהתחלה כבוי, מודלק כאשר יש כתיבה לדף.  protection bits: מה מותר לעשות על הדף. Page frame #VprotectRM

24. Spring 03 חגית עטיה © מערכות הפעלה, שקף 24 Page Fault  כאשר החומרה ניגשת לזיכרון לפי טבלת הדפים ומגיעה לדף שאינו בזיכרון הפיזי, נגרמת חריגה מסוג Page Fault בטיפול בחריגה זו, גרעין מערכת ההפעלה טוען את הדף המבוקש למסגרת בזיכרון הפיזי ומעדכן טבלאות דפים  ייתכן שיהיה צורך לפנות דף ממסגרת בזיכרון לצורך טעינת הדף החדש .. כולל כתיבת הדף הישן לדיסק אם הוא עודכן כאשר מסתיים הטיפול בחריגה, מבוצעת ההוראה מחדש  restartable instruction Page Fault יכולה להגרם גם מסיבות אחרות : גישה לא חוקית לזיכרון, גישה לדף לא מוקצה ועוד

25. Spring 03 חגית עטיה © מערכות הפעלה, שקף 25 דפדוף : הטוב  חוסך שיברור חיצוני : כל מסגרת פיזית יכולה לשמש לכל דף וירטואלי. מערכת - ההפעלה זוכרת איזה מסגרות פנויות.  מצמצם שיברור פנימי : דפים קטנים בהרבה מחתיכות.  קל לשלוח דפים לדיסק : בוחרים גודל דף שמתאים להעברה בבת - אחת לדיסק. לא חייבים למחוק, ניתן רק לסמן כלא - רלוונטי ( ביט V).  אפשר להחזיק בזיכרון הפיזי קטעים לא - רציפים.

26. Spring 03 חגית עטיה © מערכות הפעלה, שקף 26 דפדוף : הרע  גודל טבלאות הדפים : 4 בתים לכל כניסה, 2 20 כניסות  טבלת דפים בגודל 4MB לכל תהליך. ואם יש 20 תהליכים ???  תקורה של גישות לזיכרון. לפחות גישה נוספת לזיכרון ( לטבלת הדפים ) על מנת לתרגם את הכתובת.  עדיין יש שברור פנימי : גודל זיכרון התהליך אינו כפולה של גודל הדף ( שאריות בסוף ). דפים קטנים ממזערים שברור פנימי, אבל דפים גדולים מחפים על שהוּת בגישה לדיסק (disk latency).

27. Spring 03 חגית עטיה © מערכות הפעלה, שקף 27 טבלת דפים בשתי - רמות  חוזרים על אותו תעלול, ושולחים חלקים מטבלת הדפים לדיסק. למשל, דפים של טבלת הדפים שמתייחסים לתהליכים לא פעילים. רמה נוספת של הצבעה.  טבלת דפים בריבוע מאפשרת למצוא את הדפים של טבלת הדפים.

28. Spring 03 חגית עטיה © מערכות הפעלה, שקף 28 חלוקת הכתובת בשתי - רמות  לכתובת וירטואלית יש שלושה חלקים :  רצוי שהטבלה ברמה העליונה תכנס בדף אחד KB4 = 1024 כניסות כל - אחת עם 4 בתים. החלק העליון של הכתובת צריך להיות עם 10 ביטים. גם החלק התחתון 10 ביטים. Virtual page #offset secondary page #offsetmaster page #

29. Spring 03 חגית עטיה © מערכות הפעלה, שקף 29 טבלת דפים בשתי - רמות : מיפוי כתובת וירטואלית Secondary page table כתובת פיזית Page frame #offset top-level page table secondary page #offsetmaster page # Page frame # page table

30. Spring 03 חגית עטיה © מערכות הפעלה, שקף 30 דפדוף של טבלת הדפים  הטבלה ברמה העליונה תמיד בזיכרון הראשי.  תקורה של שתי גישות זיכרון ( ולפעמים גישה לדיסק !) על כל גישה לדף. פתרון ? שימוש במטמון (cache) מיוחד. קטן וזריז...

31. Spring 03 חגית עטיה © מערכות הפעלה, שקף 31 Translation Lookaside Buffer (TLB)  מטמון חומרה אשר שומר מיפויים (= תירגוּמים ) של מספרי דפים וירטואליים למספרי דפים פיזיים. למעשה, שומר עבור כל מספר דף וירטואלי את כל הכניסה שלו בטבלת הדפים, אשר יכולה להכיל מידע נוסף ( זהו הערך ). המפתח הוא מספר הדף הוירטואלי. קטן מאוד : 16-48 כניסות ( סך - הכל KB64-192). מהיר מאוד : חיפוש במקביל ( תוך cycle אחד או שניים ). אם כתובת נמצאת ב TLB ( פגיעה, hit )  הרווחנו. אם יש החמצה ( miss )  תרגום רגיל דרך טבלת הדפים.

32. Spring 03 חגית עטיה © מערכות הפעלה, שקף 32 ביצועי ה TLB  מאפשר תרגום עבור KB64-192 כתובות זיכרון. אם תהליך ניגש ליותר זיכרון  יותר החטאות ב TLB.  פגיעוֹת כמעט ב 99% של הכתובות ! מידה רבה של מקומיוּת ( locality ) בגישה לזיכרון.  לוקליות במקום (spatial locality): מסתובבים בכתובות קרובות. ( אם ניגשתי לכתובת x, סיכוי טוב שאגש לכתובת x+d.)  לוקליות בזמן (temporal locality): חוזרים לאותן כתובות בזמנים קרובים. ( אם ניגשתי לכתובת x בזמן t, סיכוי טוב שאגש אליה גם בזמן t+Δ.)

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

34. Spring 03 חגית עטיה © מערכות הפעלה, שקף 34 דוגמא : Linux בסביבת IA32  מערכות IA32 מאפשרות שילוב של סגמנטציה ודפדוף סגמנט מוגדר כאוסף רציף של דפים וירטואליים  Windows מנצלת תמיכה זו וממש יוצרת לכל תהליך סגמנט נפרד לקוד, סגמנט נפרד לנתונים וכו '  Linux אינה מנצלת את מנגנון הסגמנטציה המוצע בחומרה עובדת גם על ארכיטקטורות חומרה אחרות שתומכות בדפדוף אבל לא בסגמנטציה  עם זאת, Linux מכילה מנגנון סגמנטציה פנימי בצורה של איזורי זיכרון דפדוף של כל הסגמנטים עם טבלת דפים עם שלוש - רמות.

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

36. Spring 03 חגית עטיה © מערכות הפעלה, שקף 36 Working set  קבוצת העבודה של תהליך P, WS P (w) = הדפים אליהם תהליך P ניגש ב w הגישות האחרונות. ככל שהקבוצה קטנה יותר ( עבור ערך w קבוע ) יש יותר מקומיוּת בגישות לזיכרון של התהליך. אם קבוצת העבודה לא נמצאת בזיכרון, מערכת ההפעלה מתמוטטת מרוב הבאות / פינויים של דפים (thrashing). 1716151413121110987654321 זמן 34443261577775162 # דף 4343 44343 243243 263263 261261 516516 571571 5757 775757 157157 615615 261261 2626 2 WS(3)

37. Spring 03 חגית עטיה © מערכות הפעלה, שקף 37 דפדוף לפי דרישה  מביאים דף רק אם התהליך דורש אותו ( demand paging ) למשל, בהתחלת הביצוע ניגשים לדפים חדשים, של נתונים ושל קוד. אם הדף לא נמצא בזיכרון, קורה page fault.  לעומת זאת, prepaging מנסה לנבא איזה דפים ידרשו, ומביא אותם מראש. גישה לדיסק תוך כדי חישוב אחר במעבד.

38. Spring 03 חגית עטיה © מערכות הפעלה, שקף 38 מדיניות ההחלפה את מי מפנים ?  מטרה עיקרית : מזעור מספר פסיקות הדף. מחיר פינוי דף " מלוכלך " יקר יותר מאשר פינוי דף נקי.  מתי עושים מה : טיפול בפסיקת דף מתבצע on-line. תהליך פינוי דפים מתבצע בדרך - כלל ברקע (off-line), כאשר מספר המסגרות הפנויות יורד מתחת לאיזשהו סף. דפים מלוכלכים נכתבים ברקע לדיסק.

39. Spring 03 חגית עטיה © מערכות הפעלה, שקף 39 אלגוריתם FIFO מפנה את הדף שנטען לפני הכי הרבה זמן ABCDABCDABCD 0AAADDDCCCBBB 1BBBAAADDDCC 2CCCBBBAAAD

40. Spring 03 חגית עטיה © מערכות הפעלה, שקף 40 אנומליה באלגוריתם FIFO ABCDABEABCDE 0AAADDDEEEEEE 1BBBAAAAACCC 2CCCBBBBBDD 0AAAAAAEEEEDD 1BBBBBBAAAAE 2CCCCCCBBBB 3DDDDDDCCC

41. Spring 03 חגית עטיה © מערכות הפעלה, שקף 41 אלגוריתם אופטימאלי  אם כל הגישות לזיכרון ידועות מראש...  האלגוריתם החמדן מפנה מהזיכרון את הדף שהזמן עד לגישה הבאה אליו הוא הארוך ביותר. ABCABDADBCB 0AAAAAAAAACC 1BBBBBBBBBB 2CCCDDDDDD

42. Spring 03 חגית עטיה © מערכות הפעלה, שקף 42 Least Recently Used (LRU) מפנה את הדף שהגישה האחרונה אליו היא המוקדמת ביותר ABCABDADBCB 0AAAAAAAAACC 1BBBBBBBBBB 2CCCDDDDDD ABCDABCDABCD 0AAADDDCCCBBB 1BBBAAADDDCC 2CCCBBBAAAD מתנהג כמו החמדן מתנהג כמו FIFO

43. Spring 03 חגית עטיה © מערכות הפעלה, שקף 43 מימוש LRU  חותמת זמן (timestamp) לכל דף בגישה לדף מעדכנים את החותמת מפנים את הדף עם הזמן המוקדם יותר  ניהול מחסנית בגישה לדף מעבירים את הדף לראש המחסנית מפנים את הדף בתחתית המחסנית  יקר ודורש תמיכה בחומרה

44. Spring 03 חגית עטיה © מערכות הפעלה, שקף 44 LRU מקורב : אלגוריתם ההזדמנות השנייה reference bit לכל דף.  בגישה לדף, הביט מודלק.  בפינוי דפים, מערכת ההפעלה עוברת באופן מחזורי על כל הדפים אם reference bit = 0, הדף מפונה. אם reference bit = 1, מאפסים את הביט.

45. Spring 03 חגית עטיה © מערכות הפעלה, שקף 45 LRU מקורב : שיבה טובה  בגישה לדף מבצעים : R = 1  כל יחידת timer, עבור כל דף בזיכרון הפיזי מבצעים : if (R) then age = 0 R = 0 else age++ if ( age > threshold ) evict page  מצרפים שדה גיל (age) לכניסה של דף בטבלת הדפים.  דפים שלא ניגשו אליהם הרבה זמן, מפונים מהזיכרון.

46. Spring 03 חגית עטיה © מערכות הפעלה, שקף 46 דוגמא : אלגוריתם דפדוף ב NT  לפי דרישה, אבל מביאים קבוצת דפים מסביב.  מדיניות הדפדוף היא FIFO על הדפים של תהליך ( בנפרד ).  מנהל הזיכרון הוירטואלי עוקב אחרי ה - working set של התהליכים, ומריץ את תהליכים שיש בזיכרון מקום לכל ה - working set שלהם.  גודל ה - working set נקבע עם התחלת התהליך, לפי בקשתו ולפי הצפיפות הנוכחית בזיכרון.