OS PyramidTechnion 234123 · Operating Systemsbasics → exam
Stage 9: Virtual Memory
2017A_Winter_AQuestion 4core25 pts

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

Full original question text (raw OCR)

שאלה 4 - מחזור מסגרות (25 נק') .1 a. (2 נק') הסבירו את הצורך במטמון הדפים, כלומר, הראו מצב שבו אי שימוש במטמון הדפים גורם לבעיה. .(5 נק') דורון, סטודנט בקורס, טוען שבמערכת עם מעבד יחיד, בה הגרעין הוא ,non-preemptive ניתן לפתור את הבעיה שהוצגה בסעיף הקודם באופן הבא: 1. upon evacuating frame X to slot Y do: 2. 3. 4. for every process do: for every PTE s.t PTE set PTE <- Y = X do: בפשטות, בזמן פינוי מסגרת X למגירה Y, האלגוריתם עובר על כל טבלאות הדפים של כל התהליכים ומעדכן כל PTE שהצביע על X להצביע על Y. האלגוריתם רץ בפסיקות חסומות ואינו מוותר על המעבד עד לסיומו. האלגוריתם מחליף את מנגנון הפינוי באמצעות מטמון הדפים. נמקו מדוע האלגוריתם של דורון נכון. פרטו לפחות שני חסרונות של האלגוריתם לעומת הפתרון הקיים בגרעין לינוקס, האם קיימים גם יתרונות? אם כן פרטו. 2. בחברת Green-Gat החליטו להרחיב את מערכת ההפעלה הפופולרית שלהם שזהה למערכת ההפעלה שנלמדה בקורס. ההרחבה מאפשרת למערכת ההפעלה להחליף את המיקום של מסגרת הממפה דף משתמש בזיכרון הראשי. כלומר, בהינתן דף הממופה למסגרת שכתובתה הפיזית היא X בזיכרון הראשי, ניתן להפנותו למסגרת (שאינה בשימוש) שכתובתה הפיזית היא Y בזיכרון הראשי. בסעיפים הבאים הניחו שהמערכת היא בעלת מעבד יחיד וגרעין ללא הפקעה. a.(4 נק') הסבירו כיצד תורם קיומו של מנגנון הזיכרון הווירטואלי למימוש ההרחבה. b.(6 נק') ציינו לפחות 3 מבנים בגרעין או בחומרה אותם ההרחבה צריכה לעדכן? פרטו. .1 .2 .3 3. בסעיף זה נחקור את אלגוריתם פינוי המסגרות. כזכור, האלגוריתם מורכב משתי פאזות (נתעלם מפינוי מטמונים): בשלב הראשון, קוראים לפונקציה refill_inactive ואז עוברים על רשימת ה inactive על מנת לנסות לפנות מסגרות שאינן בשימוש. Ο בשלב השני, אם התגלה הצורך, נעבור על טבלאות הדפים ונפעיל לפי הצורך את ננסה לפנות באמצעות ה inactive וכל מסגרת שנמצאת ב ,mark_page_accessed .page cache a. (4 נק') הסבירו מדוע הסדר של הפאזות חשוב, כלומר, מדוע חשוב שפאזה 1 תרוץ לפני פאזה 2? (רמז: האלגוריתם יישאר נכון גם אם נהפוך את סדר הפאזות) .(4 נק') האם בכל זאת קיים מצב שבו נעדיף להפוך את סדר הפאזות? נמקו.

  1. 1.a· short_answer· 2 ptsVirtual Memory

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

    Voluntary vs preemptive context switchlibc syscall wrapper caching pitfallsPreemption trigger identification
  2. 1.b· short_answer· 5 ptsVirtual Memory

    (5 נק') דורון, סטודנט בקורס, טוען שבמערכת עם מעבד יחיד, בה הגרעין הוא non-preemptive, ניתן לפתור את הבעיה שהוצגה בסעיף הקודם באופן הבא: 1. upon evacuating frame X to slot Y do: 2. for every process do: 3. for every PTE s.t PTE = X do: 4. set PTE <- Y בפשטות, בזמן פינוי מסגרת X למגירה Y, האלגוריתם עובר על כל טבלאות הדפים של כל התהליכים ומעדכן כל PTE שהצביע על X להצביע על Y. האלגוריתם רץ בפסיקות חסומות ואינו מוותר על המעבד עד לסיומו. האלגוריתם מחליף את מנגנון הפינוי באמצעות מטמון הדפים. נמקו מדוע האלגוריתם של דורון נכון. פרטו לפחות שני חסרונות של האלגוריתם לעומת הפתרון הקיים בגרעין לינוקס, האם קיימים גם יתרונות? אם כן פרטו.

    Voluntary vs preemptive context switchlibc syscall wrapper caching pitfallsPreemption trigger identificationNon-preemptible kernel implicationsLocal vs global interrupt disable
  3. 2.a· short_answer· 4 ptsVirtual Memory

    (4 נק') הסבירו כיצד תורם קיומו של מנגנון הזיכרון הווירטואלי למימוש ההרחבה.

    Voluntary vs preemptive context switchlibc syscall wrapper caching pitfallsPreemption trigger identification
  4. 2.b· short_answer· 6 ptsVirtual Memory

    (6 נק') ציינו לפחות 3 מבנים בגרעין או בחומרה אותם ההרחבה צריכה לעדכן? פרטו. 1. 2. 3.

    Voluntary vs preemptive context switchlibc syscall wrapper caching pitfallsPreemption trigger identification
  5. 3.a· short_answer· 4 ptsVirtual Memory

    (4 נק') הסבירו מדוע הסדר של הפאזות חשוב, כלומר, מדוע חשוב שפאזה 1 תרוץ לפני פאזה 2? (רמז: האלגוריתם יישאר נכון גם אם נהפוך את סדר הפאזות)

    Voluntary vs preemptive context switchlibc syscall wrapper caching pitfallsPreemption trigger identification
  6. 3.b· short_answer· 4 ptsVirtual Memory

    (4 נק') האם בכל זאת קיים מצב שבו נעדיף להפוך את סדר הפאזות? נמקו.

    Voluntary vs preemptive context switchlibc syscall wrapper caching pitfallsPreemption trigger identification

The exam question — original PDF

pages 16, 17, 18

Exactly as it appears on the exam paper.

loading page 16
loading page 17
loading page 18

Built from these components

Ordered basic → advanced. Master the earlier ones first.

L2Voluntary vs preemptive context switchL3libc syscall wrapper caching pitfallsL3Preemption trigger identificationL3Non-preemptible kernel implicationsL3Local vs global interrupt disable

Review the material

Read these before you answer — each verified slide teaches a component this question tests, and nothing from an unrelated topic is included. Tutorial slides show the actual slide image.

Tutorial 2slide 3קריאות מערכתלעבודה עם תהליכיםמערכות הפעלה - תרגול 23

קריאות מערכתלעבודה עם תהליכיםמערכות הפעלה - תרגול 23

Tutorial 2slide 18קריאת המערכת exit()שאלה: למה בכלל לקרוא ל-exit(status) , אם אפשר פשוט לרשום return status בסוף פונקציית ה-main?תשובה:...

קריאת המערכת exit()שאלה: למה בכלל לקרוא ל-exit(status) , אם אפשר פשוט לרשום return status בסוף פונקציית ה-main?תשובה: main היא לא באמת הפונקציה הראשית של התכנית...main() נקראת ע"י __libc_start_main() שאוספת את ערך החזרה של main() וקוראת ל-exit().int __libc_start_main(…) { …… exit(main(…));}מסקנה: הפונקציה exit תמיד נקראת לסיום סטנדרטי של התוכנית.מערכות הפעלה - תרגול 218

Tutorial 2slide 22קריאות המערכת getpid(), getppid()pid_t getpid();קריאת מערכת המחזירה לתהליך הקורא את ה-pid של עצמו

קריאות המערכת getpid(), getppid()pid_t getpid();קריאת מערכת המחזירה לתהליך הקורא את ה-pid של עצמו.pid_t getppid();קריאת מערכת המחזירה את ה-PID של תהליך האב של התהליך הקורא.שאלה: מה המשמעות של getppid() == 1 עבור תהליך משתמש טיפוסי?תשובה: תהליך האב הוא init. קורה למשל אם תהליך הבן יתום.מערכות הפעלה - תרגול 222

Tutorial 2slide 24דוגמת קודמסכמתprintf("pid = %d\n", getpid());pid_t pid = fork();if (pid == 0) { printf("child pid = %d\n", getpid());...

דוגמת קודמסכמתprintf("pid = %d\n", getpid());pid_t pid = fork();if (pid == 0) { printf("child pid = %d\n", getpid()); char* args[] = {"/bin/date", NULL}; execv(args[0], args); printf("This should not be printed\n");} else { wait(NULL); printf("parent pid = %d\n", getpid());}פלט לדוגמה:pid = 8919child pid = 8920Sun Oct 29 00:31:32 IDT 2017parent pid = 8919מערכות הפעלה - תרגול 224

Tutorial 2slide 28מערכות הפעלה - תרגול 2281שאלה ממבחן

מערכות הפעלה - תרגול 2281שאלה ממבחן

Tutorial 6slide 10מהי החלפת הקשר?מערכות הפעלה - תרגול 610

מהי החלפת הקשר?מערכות הפעלה - תרגול 610

Tutorial 6slide 11מהי החלפת הקשר?לכל תהליך יש "הקשר ביצוע" (execution context) המכיל את כל המידע הדרוש לביצוע התהליך

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

Tutorial 6slide 13שני סוגים של החלפת הקשרהחלפת הקשר כפויה(== הפקעה)הגרעין מפקיע (כלומר, לוקח בכוח) את המעבד מהתהליך, למשל בעקבות:פסיקת ...

שני סוגים של החלפת הקשרהחלפת הקשר כפויה(== הפקעה)הגרעין מפקיע (כלומר, לוקח בכוח) את המעבד מהתהליך, למשל בעקבות:פסיקת שעון (מטופלת בשגרה scheduler_tick) אשר מגלה כי הזמן שהוקצב לתהליך הנוכחי אזל.אירוע אסינכרוני אשר מעיר תהליך בעל עדיפות טובה יותר מהתהליך הרץ כרגע.לדוגמה: פסיקת דיסק או שחרור מנעול שתהליך המתין לו.החלפת הקשר יזומההתהליך מוותר מרצונו על המעבד, למשל באמצעות:קריאת מערכת חוסמת (כמו wait(), read(), …) אשר מוציאה את התהליך להמתנה.קריאת מערכת exit() אשר מסיימת את התהליך.קריאת מערכת sched_yield() – קריאת מערכת ייעודית לוויתור על המעבד.מערכות הפעלה - תרגול 613

Tutorial 6slide 14הפקעה (preemption)בעיה: תהליך משתמש עלול לרוץ לנצח (למשל, לולאה אינסופית) ולמנוע את המעבד משאר התהליכים

הפקעה (preemption)בעיה: תהליך משתמש עלול לרוץ לנצח (למשל, לולאה אינסופית) ולמנוע את המעבד משאר התהליכים.פגיעה בהוגנות (fairness) ותגובתיות (rrsponsiveness).פתרון: לינוקס מפקיעה (preempt) את המעבד מתהליך אחד לטובת תהליך אחר, בעזרת התקן חומרה מיוחד – השעון.מערכת ההפעלה מבקשת מהשעון לשלוח פסיקה במרווחי זמן קבועים כדי להעביר את השליטה למערכת ההפעלה.כל הפסיקות, בפרט פסיקת שעון, מטופלות במצב גרעין, ואז הגרעין מחליף הקשר אם יש צורך.מערכות הפעלה - תרגול 614

Tutorial 6slide 35הפונקציה __switch_to_asm (3) popq %r15 popq %r14 popq %r13 popq %r12 popq %rbx popq %rbp jmp __switch_to מערכות הפעלה...

הפונקציה __switch_to_asm (3) popq %r15 popq %r14 popq %r13 popq %r12 popq %rbx popq %rbp jmp __switch_to מערכות הפעלה - תרגול 635שחזור הרגיסטרים ממחסנית הגרעין של next.אלו הרגיסטרים ש-next שמר כאשר הוא קרא להחלפת הקשר בעבר.קפיצה (jmp) במקום קריאה (call) לפונקציה. למה?כתובת החזרה מהפונקציה __switch_to() כבר שמורה על המחסנית של next.

Tutorial 8slide 1תרגול 8מנגנוני סנכרון: משתני תנאימנגנוני סנכרון: סמפוריםדוגמה: מימוש מנעול קוראים-כותביםסינכרון בגרעין לינוקס1מערכות ...

תרגול 8מנגנוני סנכרון: משתני תנאימנגנוני סנכרון: סמפוריםדוגמה: מימוש מנעול קוראים-כותביםסינכרון בגרעין לינוקס1מערכות הפעלה - תרגול 8

Tutorial 8slide 32מימוש מנעול קוראים-כותבים (1)int readers_inside, writers_inside;cond_t read_allowed;cond_t write_allowed;mutex_t glob...

מימוש מנעול קוראים-כותבים (1)int readers_inside, writers_inside;cond_t read_allowed;cond_t write_allowed;mutex_t global_lock; void readers_writers_init() { readers_inside = 0; writers_inside = 0; cond_init(&read_allowed, NULL); cond_init(&write_allowed, NULL); mutex_init(&global_lock, NULL);}32מערכות הפעלה - תרגול 8מה ערכו המקסימלי של writers_inside?

Ask Gemini
2017A_Winter_A · Q4 — question + its material already loaded
Pick a shortcut above or ask anything about this question.
The exam text, the skills it tests, and the exact slides are already in context.