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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Spring 03 חגית עטיה © מערכות הפעלה, שקף 30 ביצועי ה TLB  מאפשר תרגום עבור KB כתובות זיכרון. אם תהליך ניגש ליותר זיכרון  החטאות ב TLB.  פגיעוֹת כמעט ב 99% של הכתובות ! מידה רבה של מקומיות ( locality ) בגישה לזיכרון.

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

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

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

Spring 03 חגית עטיה © מערכות הפעלה, שקף 34 Working set  קבוצת העבודה של תהליך P, WS P (w) = הדפים אליהם תהליך P ניגש ב w הגישות האחרונות. ככל שהקבוצה קטנה יותר ( עבור ערך w קבוע ) יש יותר מקומיות בגישות לזיכרון של התהליך. אם קבוצת העבודה לא נמצאת בזיכרון, מערכת ההפעלה מתמוטטת מרוב הבאות / פינויים של דפים (thrashing) זמן # דף WS(3)

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

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

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

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

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

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

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

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

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

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