• Like
AOS Lab 6: Scheduling
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

AOS Lab 6: Scheduling

  • 276 views
Published

 

Published in Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
276
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
7
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Lab 6: Scheduling Advanced Operating Systems Zubair Nabi zubair.nabi@itu.edu.pk March 6, 2013
  • 2. Introduction 1 An operating system runs more processes than it has processors
  • 3. Introduction 1 An operating system runs more processes than it has processors 2 Needs some plan to time share the processors between the processes
  • 4. Introduction 1 An operating system runs more processes than it has processors 2 Needs some plan to time share the processors between the processes 3 A common approach is to provide each process with a virtual processor – An illusion that it has exclusive access to the processor
  • 5. Introduction 1 An operating system runs more processes than it has processors 2 Needs some plan to time share the processors between the processes 3 A common approach is to provide each process with a virtual processor – An illusion that it has exclusive access to the processor 4 It is then the job of the OS to multiplex these multiple virtual processors on the underlying physical processors
  • 6. Scheduling triggers 1 A process does I/O, put it to sleep, and schedule another process
  • 7. Scheduling triggers 1 A process does I/O, put it to sleep, and schedule another process 2 Use timer interrupts to stop running on a processor after a fixed time quantum (100 msec)
  • 8. Context switching • Used to achieve multiplexing
  • 9. Context switching • Used to achieve multiplexing • Internally two low-level context switches are performed
  • 10. Context switching • Used to achieve multiplexing • Internally two low-level context switches are performed 1 Process’s kernel thread to the current CPU’s scheduler thread
  • 11. Context switching • Used to achieve multiplexing • Internally two low-level context switches are performed 1 2 Process’s kernel thread to the current CPU’s scheduler thread Scheduler’s thread to a process’s kernel thread
  • 12. Context switching • Used to achieve multiplexing • Internally two low-level context switches are performed 1 2 Process’s kernel thread to the current CPU’s scheduler thread Scheduler’s thread to a process’s kernel thread • No direct switching from one user-space process to another
  • 13. Context switching • Used to achieve multiplexing • Internally two low-level context switches are performed 1 2 Process’s kernel thread to the current CPU’s scheduler thread Scheduler’s thread to a process’s kernel thread • No direct switching from one user-space process to another • Each process has its own kernel stack and register set (its context)
  • 14. Context switching • Used to achieve multiplexing • Internally two low-level context switches are performed 1 2 Process’s kernel thread to the current CPU’s scheduler thread Scheduler’s thread to a process’s kernel thread • No direct switching from one user-space process to another • Each process has its own kernel stack and register set (its context) • Each CPU has its own scheduler thread
  • 15. Context switching • Used to achieve multiplexing • Internally two low-level context switches are performed 1 2 Process’s kernel thread to the current CPU’s scheduler thread Scheduler’s thread to a process’s kernel thread • No direct switching from one user-space process to another • Each process has its own kernel stack and register set (its context) • Each CPU has its own scheduler thread • Context switch involves saving the old thread’s CPU registers and restoring previously-saved registers of the new thread (enabled by swtch)
  • 16. swtch • Saves and restores contexts
  • 17. swtch • Saves and restores contexts • Takes two arguments: struct context **old and struct context *new
  • 18. swtch • Saves and restores contexts • Takes two arguments: struct context **old and struct context *new • Replaces the former with the latter
  • 19. swtch • Saves and restores contexts • Takes two arguments: struct context **old and struct context *new • Replaces the former with the latter • Each time a process has to give up the CPU, its kernel thread invokes swtch to save its own context and switch to the scheduler context
  • 20. swtch • Saves and restores contexts • Takes two arguments: struct context **old and struct context *new • Replaces the former with the latter • Each time a process has to give up the CPU, its kernel thread invokes swtch to save its own context and switch to the scheduler context • Flow in case of an interrupt:
  • 21. swtch • Saves and restores contexts • Takes two arguments: struct context **old and struct context *new • Replaces the former with the latter • Each time a process has to give up the CPU, its kernel thread invokes swtch to save its own context and switch to the scheduler context • Flow in case of an interrupt: 1 trap handles the interrupt and the calls yield
  • 22. swtch • Saves and restores contexts • Takes two arguments: struct context **old and struct context *new • Replaces the former with the latter • Each time a process has to give up the CPU, its kernel thread invokes swtch to save its own context and switch to the scheduler context • Flow in case of an interrupt: 1 trap handles the interrupt and the calls yield 2 yield makes a call to sched
  • 23. swtch • Saves and restores contexts • Takes two arguments: struct context **old and struct context *new • Replaces the former with the latter • Each time a process has to give up the CPU, its kernel thread invokes swtch to save its own context and switch to the scheduler context • Flow in case of an interrupt: 1 trap handles the interrupt and the calls yield 2 yield makes a call to sched 3 sched invokes swtch(&proc->context, cpu->scheduler)
  • 24. swtch • Saves and restores contexts • Takes two arguments: struct context **old and struct context *new • Replaces the former with the latter • Each time a process has to give up the CPU, its kernel thread invokes swtch to save its own context and switch to the scheduler context • Flow in case of an interrupt: 1 trap handles the interrupt and the calls yield 2 yield makes a call to sched 3 sched invokes swtch(&proc->context, cpu->scheduler) 4 Control returns to the scheduler thread
  • 25. Scheduling mechanism • Each process that wants to give up the processor:
  • 26. Scheduling mechanism • Each process that wants to give up the processor: 1 Acquires ptable.lock (process table lock)
  • 27. Scheduling mechanism • Each process that wants to give up the processor: 1 Acquires ptable.lock (process table lock) 2 Releases any other locks that it is holding
  • 28. Scheduling mechanism • Each process that wants to give up the processor: 1 Acquires ptable.lock (process table lock) 2 3 Releases any other locks that it is holding Updates proc->state (its own state)
  • 29. Scheduling mechanism • Each process that wants to give up the processor: 1 Acquires ptable.lock (process table lock) Releases any other locks that it is holding Updates proc->state (its own state) 4 Calls sched 2 3
  • 30. Scheduling mechanism • Each process that wants to give up the processor: 1 Acquires ptable.lock (process table lock) Releases any other locks that it is holding Updates proc->state (its own state) 4 Calls sched 2 3 • Mechanism followed by yield, and sleep and exit
  • 31. Scheduling mechanism • Each process that wants to give up the processor: 1 Acquires ptable.lock (process table lock) Releases any other locks that it is holding Updates proc->state (its own state) 4 Calls sched 2 3 • Mechanism followed by yield, and sleep and exit • sched ensures that these steps are followed
  • 32. sched 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 void sched (void) { int intena ; if(! holding (& ptable .lock )) panic (" sched ptable .lock"); if(cpu−>ncli != 1) panic (" sched locks "); if(proc−>state == RUNNING ) panic (" sched running "); if( readeflags ()& FL_IF ) panic (" sched interruptible "); intena = cpu−>intena ; swtch (& proc−>context , cpu−>scheduler ); cpu−>intena = intena ; }
  • 33. yield 1 2 3 4 5 6 void yield (void) { acquire (& ptable .lock ); proc−>state = RUNNABLE ; sched (); release (& ptable .lock ); }
  • 34. Scheduling mechanism (2) • Why must a process acquire ptable.lock before a call to swtch? • Breaks the convention that the thread that acquires a lock is also responsible for releasing the lock
  • 35. Scheduling mechanism (2) • Why must a process acquire ptable.lock before a call to swtch? • Breaks the convention that the thread that acquires a lock is also responsible for releasing the lock • Without acquiring ptable.lock, two CPUs might want to schedule the same process because they can access ptable
  • 36. scheduler • Simple loop: find a process to run, run it until it stops, repeat
  • 37. scheduler • Simple loop: find a process to run, run it until it stops, repeat • Acquires and releases ptable.lock, and enables interrupts on every iteration. Why?
  • 38. scheduler • Simple loop: find a process to run, run it until it stops, repeat • Acquires and releases ptable.lock, and enables interrupts on every iteration. Why? • If CPU is idle (no RUNNABLE)
  • 39. scheduler • Simple loop: find a process to run, run it until it stops, repeat • Acquires and releases ptable.lock, and enables interrupts on every iteration. Why? • If CPU is idle (no RUNNABLE) 1 Idle looping while holding a lock would not allow any other CPU to access the process table
  • 40. scheduler • Simple loop: find a process to run, run it until it stops, repeat • Acquires and releases ptable.lock, and enables interrupts on every iteration. Why? • If CPU is idle (no RUNNABLE) Idle looping while holding a lock would not allow any other CPU to access the process table 2 Idle looping (all processes are waiting for I/O) while interrupts are disabled would not allow any I/O to arrive 1
  • 41. scheduler • Simple loop: find a process to run, run it until it stops, repeat • Acquires and releases ptable.lock, and enables interrupts on every iteration. Why? • If CPU is idle (no RUNNABLE) Idle looping while holding a lock would not allow any other CPU to access the process table 2 Idle looping (all processes are waiting for I/O) while interrupts are disabled would not allow any I/O to arrive 1 • The first process with p->state == RUNNABLE is selected
  • 42. scheduler • Simple loop: find a process to run, run it until it stops, repeat • Acquires and releases ptable.lock, and enables interrupts on every iteration. Why? • If CPU is idle (no RUNNABLE) Idle looping while holding a lock would not allow any other CPU to access the process table 2 Idle looping (all processes are waiting for I/O) while interrupts are disabled would not allow any I/O to arrive 1 • The first process with p->state == RUNNABLE is selected • The process is assigned to the per-CPU proc
  • 43. scheduler • Simple loop: find a process to run, run it until it stops, repeat • Acquires and releases ptable.lock, and enables interrupts on every iteration. Why? • If CPU is idle (no RUNNABLE) Idle looping while holding a lock would not allow any other CPU to access the process table 2 Idle looping (all processes are waiting for I/O) while interrupts are disabled would not allow any I/O to arrive 1 • The first process with p->state == RUNNABLE is selected • The process is assigned to the per-CPU proc • The process’s page table is switched to via switchuvm
  • 44. scheduler • Simple loop: find a process to run, run it until it stops, repeat • Acquires and releases ptable.lock, and enables interrupts on every iteration. Why? • If CPU is idle (no RUNNABLE) Idle looping while holding a lock would not allow any other CPU to access the process table 2 Idle looping (all processes are waiting for I/O) while interrupts are disabled would not allow any I/O to arrive 1 • The first process with p->state == RUNNABLE is selected • The process is assigned to the per-CPU proc • The process’s page table is switched to via switchuvm • The process is marked as RUNNING
  • 45. scheduler • Simple loop: find a process to run, run it until it stops, repeat • Acquires and releases ptable.lock, and enables interrupts on every iteration. Why? • If CPU is idle (no RUNNABLE) Idle looping while holding a lock would not allow any other CPU to access the process table 2 Idle looping (all processes are waiting for I/O) while interrupts are disabled would not allow any I/O to arrive 1 • The first process with p->state == RUNNABLE is selected • The process is assigned to the per-CPU proc • The process’s page table is switched to via switchuvm • The process is marked as RUNNING • swtch is called to start running it
  • 46. scheduler 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 void scheduler (void) { struct proc ∗p; for (;;){ sti (); acquire (& ptable .lock ); for(p = ptable .proc; p < & ptable .proc[ NPROC ]; p++){ if(p−>state != RUNNABLE ) continue ; proc = p; switchuvm (p); p−>state = RUNNING ; swtch (&cpu−>scheduler , proc−>context ); switchkvm (); proc = 0; }
  • 47. Sleep and wakeup • sleep and wakeup enable an IPC mechanism
  • 48. Sleep and wakeup • sleep and wakeup enable an IPC mechanism • Enable sequence coordination or conditional synchronization
  • 49. Sleep and wakeup • sleep and wakeup enable an IPC mechanism • Enable sequence coordination or conditional synchronization • sleep allows one process to sleep waiting for an event
  • 50. Sleep and wakeup • sleep and wakeup enable an IPC mechanism • Enable sequence coordination or conditional synchronization • sleep allows one process to sleep waiting for an event • wakeup allows another process to wake up processes sleeping on an event
  • 51. Queue 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 struct q { void ∗ptr; }; void∗ send( struct q ∗q, void ∗q) { while(q−>ptr != 0) ; q−>ptr = p; } void∗ recv( struct q void ∗p; while ((p = q−>ptr) == 0) ; q−>ptr = 0; return p; } ∗p) {
  • 52. Queue with sleep and wakeup 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 void∗ send( struct q ∗q, void ∗q) { while(q−>ptr != 0) ; q−>ptr = p; wakeup (q); } void∗ recv( struct q void ∗p; while ((p = q−>ptr) == 0) sleep (q); q−>ptr = 0; return p; } ∗p) {
  • 53. Queue with sleep and wakeup and locking 1 2 3 4 struct q { struct spinlock lock; void }; ∗ptr;
  • 54. Queue with sleep and wakeup and locking (2) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 void∗ send( struct q ∗q, void acquire (&q−>lock ); while(q−>ptr != 0) ; q−>ptr = p; wakeup (q); release (&q−>lock ); } void∗ recv( struct q void ∗q) { ∗p; acquire (&q−>lock ); while ((p = q−>ptr) == 0) sleep (q); q−>ptr = 0; release (&q−>lock ); return p; } ∗p) {
  • 55. Queue with sleep and wakeup and implicit locking 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 void∗ send( struct q ∗q, void acquire (&q−>lock ); while(q−>ptr != 0) ; q−>ptr = p; wakeup (q); release (&q−>lock ); } void∗ recv( struct q void ∗q) { ∗p; acquire (&q−>lock ); while ((p = q−>ptr) == 0) sleep (q, &q−>lock ); q−>ptr = 0; release (&q−>lock ); return p; } ∗p) {
  • 56. sleep 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 void sleep (void ∗chan , struct spinlock if(proc == 0) panic (" sleep "); if(lk == 0) panic (" sleep without lk"); if(lk != & ptable .lock ){ acquire (& ptable .lock ); release (lk ); } proc−>chan = chan; proc−>state = SLEEPING ; sched (); proc−>chan = 0; if(lk != & ptable .lock ){ release (& ptable .lock ); acquire (lk ); } } ∗lk) {
  • 57. wakeup 1 2 3 4 5 6 7 8 9 10 11 12 static void wakeup1 (void struct proc ∗chan) { ∗p; for(p = ptable .proc; p < & ptable .proc[ NPROC ]; p++) if(p−>state == SLEEPING && p−>chan == chan) p−>state = RUNNABLE ; } void wakeup (void ∗chan) acquire (& ptable .lock ); wakeup1 (chan ); release (& ptable .lock ); } {
  • 58. Today’s Task • ptable.lock is a very coarse-grained lock which protects the entire process table • Design a mechanism (in terms of pseudocode) that splits it up into multiple locks • Explain why your solution will improve performance while ensuring protection
  • 59. Reading(s) • Chapter 5, “Scheduling” from “xv6: a simple, Unix-like teaching operating system”