Changelog Changes made in this version not seen in fjrst lecture: - PowerPoint PPT Presentation

Changelog Changes made in this version not seen in fjrst lecture: 13 September: replace ‘multi-level queue’ with ‘multi-level feedback queue’ throughout 0

1

last time the xv6 scheduler loop through process table dedicated thread for scheduler swtch to scheduler to give up CPU scheduler switches back to you scheduling metrics throughput, response time, fairness fjrst-come fjrst-served (FCFS), round robin (RR) simple non-preemptive, preemptive scheduler priority scheduling shortest job fjrst 2

scheduler HW timing note 3

on extensions and late policies there is a late policy -10% 72 hours; -20% week I generally don’t do extensions for the whole class (exceptions: problems with submission system/weather/etc.) if someone made sure they completed the assignment on time… I might do late penalty adjustments 4

execv and const argv is a pointer to constant pointer to char probably should be a pointer to constant pointer to constant char …this causes some awkwardness: execv(path, array); // ERROR solution: cast 5 int execv( const char *path, char * const *argv); const char *array[] = { /* ... */ }; const char *array[] = { /* ... */ }; execv(path, ( char **) array); // or (char * const *)

shell HW Q&A time 6

minimizing response time recall: fjrst-come, fjrst-served best order: had shortest CPU bursts fjrst = same as priority where CPU burst length determines priority …but without preemption for now priority = job length doesn’t quite work with preemption (preview: need priority = remaining time) 7 → scheduling algorithm: ‘shortest job fjrst’ (SJF)

a practical problem so we want to run the shortest CPU burst fjrst how do I tell which thread that is? we’ll deal with this problem later …kinda 8

alternating I/O and CPU: SJF program A CPU I/O … program B C P U I/O … program C … shortest CPU burst not run immediately still have “convoy efgect” 9

alternating I/O and CPU: SJF program A CPU I/O … program B C P U I/O … program C … shortest CPU burst not run immediately still have “convoy efgect” 9

alternating I/O and CPU: SJF program A CPU I/O … program B C P U I/O … program C … shortest CPU burst not run immediately still have “convoy efgect” 9

adding preemption (1) what if a long job is running, then a short job interrupts it? short job will wait for too long solution is preemption — reschedule when new job arrives new job is shorter — run now! 10

solution: priority = remaining time adding preemption (2) what if a long job is almost done running, then a medium job interrupts it? recall: priority = job length long job waits for medium job …for longer than it would take to fjnish worse than letting long job fjnish called shortest remaining time fjrst (SRTF) prioritize by what’s left, not the total 11

adding preemption (2) what if a long job is almost done running, then a medium job interrupts it? recall: priority = job length long job waits for medium job …for longer than it would take to fjnish worse than letting long job fjnish called shortest remaining time fjrst (SRTF) prioritize by what’s left, not the total 11 solution: priority = remaining time

(that is, B is shorter than the time A has left) alternating I/O and CPU: SRTF … because fjnishing A is faster than running C C does not preempt A B preempts A because it has less time left … program C I/O program A U P C program B … I/O CPU 12

(that is, B is shorter than the time A has left) alternating I/O and CPU: SRTF … because fjnishing A is faster than running C C does not preempt A B preempts A because it has less time left … program C I/O program A U P C program B … I/O CPU 12

alternating I/O and CPU: SRTF program A because fjnishing A is faster than running C C does not preempt A B preempts A because it has less time left … program C … I/O U P C program B … I/O CPU 12 (that is, B is shorter than the time A has left)

(that is, B is shorter than the time A has left) alternating I/O and CPU: SRTF … because fjnishing A is faster than running C C does not preempt A B preempts A because it has less time left … program C I/O program A U P C program B … I/O CPU 12

SRTF, SJF are optimal (for response time) SJF minimizes response time/waiting time …if you disallow preemption/leaving CPU deliberately idle SRTF minimizes response time/waiting time …if you ignore context switch costs 13

knowing job lengths seems hard sometimes you can ask common in batch job scheduling systems and maybe you’ll get accurate answers, even 14

approximating SJF with priorities process B use more than 1ms at priority 3? — you shouldn’t be there priority level = allowed time quantum goal: place processes at priority level based on CPU burst time process F process E process D process C process A priority 3 20+ ms timeslice priority 0 10–20 ms timeslice priority 1 1–10 ms timeslice priority 2 0–1 ms timeslice 15

pde_t* pgdir; char *kstack; struct proc *parent; struct trapframe *tf; struct context *context; void *chan; struct file *ofile[NOFILE]; struct inode *cwd; // Current directory char name[16]; // Open files // If non-zero, have been killed int killed; // If non-zero, sleeping on chan // Process name (debugging) // swtch() here to run process the SJF/SRTF problem // Parent process // Trap frame for current syscall so, bucket implies CPU burst length // Process ID int pid; // Process state enum procstate state; // Bottom of kernel stack for this process // Page table // Size of process memory (bytes) uint sz; e.g. not any of these fjelds well, how does one fjgure that out? 16

the SJF/SRTF problem // Process ID // Process name (debugging) char name[16]; // Current directory // Open files // If non-zero, have been killed int killed; // If non-zero, sleeping on chan // swtch() here to run process // Trap frame for current syscall so, bucket implies CPU burst length // Parent process int pid; // Size of process memory (bytes) well, how does one fjgure that out? e.g. not any of these fjelds uint sz; // Page table enum procstate state; // Bottom of kernel stack for this process // Process state 16 pde_t* pgdir; char *kstack; struct proc *parent; struct trapframe *tf; struct context *context; void *chan; struct file *ofile[NOFILE]; struct inode *cwd;

predicting the future worst case: need to run the program to fjgure it out but heuristics can fjgure it out (read: often works, but no gaurentee) intuition: interactive program with lots of I/O tends to stay interactive intuition: CPU-heavy program is going to keep using CPU 17 key observation: CPU bursts now are like CPU bursts later

taking advantage of history process D process A put on higher priority next time fjnished early? process A add to lower priority queue now used whole timeslice? priority process run highest process F process E process C priority 3 / 1 ms process B process A quantum with difgerent each priority round robin at idea: priority = CPU burst length priority 0 / 100 ms priority 1 / 20 ms priority 2 / 10 ms 18

taking advantage of history process D process A put on higher priority next time fjnished early? process A add to lower priority queue now used whole timeslice? priority process run highest process F process E process C priority 3 / 1 ms process B process A quantum with difgerent each priority round robin at idea: priority = CPU burst length priority 0 / 100 ms priority 1 / 20 ms priority 2 / 10 ms 18

taking advantage of history process D process A put on higher priority next time fjnished early? process A add to lower priority queue now used whole timeslice? priority process run highest process F process E process C priority 3 / 1 ms process B process A quantum with difgerent each priority round robin at idea: priority = CPU burst length priority 0 / 100 ms priority 1 / 20 ms priority 2 / 10 ms 18

taking advantage of history process D process A put on higher priority next time fjnished early? process A add to lower priority queue now used whole timeslice? priority process run highest process F process E process C priority 3 / 1 ms process B process A quantum with difgerent each priority round robin at idea: priority = CPU burst length priority 0 / 100 ms priority 1 / 20 ms priority 2 / 10 ms 18

multi-level feedback queue idea higher priority = shorter time quantum (before interrupted) adjust priority and timeslice based on last timeslice intuition: process always uses same CPU burst length? ends up at “right” priority rises up to queue with quantum just shorter than it’s burst then goes down to next queue, then back up, then down, then up, etc. 19

cheating multi-level feedback queuing algorithm: don’t use entire time quantum? priority increases getting all the CPU: while ( true ) { useCpuForALittleLessThanMinimumTimeQuantum(); yieldCpu(); } 20

almost none — starvation multi-level feedback queuing and fairness suppose we are running several programs: A. one very long computation that doesn’t need any I/O B1 through B1000. 1000 programs processing data on disk C. one interactive program how much time will A get? intuition: the B programs have higher priority than A because it has smaller CPU bursts 21