1. Operating Systems CMPSC 473 Processes (3) September 17 2008 - Lecture 9 Instructor: Bhuvan Urgaonkar

2. Announcements Suggested Reading for this lecture: Sections 3.1-3.3 Quiz 1: Will have several questions that came up during previous lectures

3. Overview of Process- related Topics How a process is born –Parent/child relationship –fork, clone, … How it leads its life –Loaded: Later in the course –Executed CPU scheduling Context switching Where a process “lives”: Address space –OS maintains some info. for each process: PCB –Process = Address Space + PCB How processes request services from the OS –System calls How processes communicate Some variants of processes: LWPs and threads How processes die

4. Overview of Process- related Topics How a process is born –Parent/child relationship –fork, clone, … How it leads its life –Loaded: Later in the course –Executed CPU scheduling Context switching Where a process “lives”: Address space –OS maintains some info. for each process: PCB –Process = Address Space + PCB How processes request services from the OS –System calls How processes communicate Some variants of processes: LWPs and threads How processes die more today

5. The Process/Kernel Model Transitions between User and Kernel modes: An example Process 1 USER MODE KERNEL MODE Process 1Process 2 Time Sys call handler Scheduler Interrupt handler

6. Re-entrant Kernels Note: Not showing scheduler invocations Re-entrant kernel: Several processes may be in Kernel Mode at the same time –A re-entrant kernel is able to suspend the current running process even if it is in the Kernel Mode Note: Traps are a type of exceptions. We will encounter more types later. Process 1 USER MODE KERNEL MODE Process 1Process 2 Time ExcpIntr

7. Re-entrant Kernels Note: Not showing scheduler invocations Re-entrant kernel: Several processes may be in Kernel Mode at the same time –A re-entrant kernel is able to suspend the current running process even if it is in the Kernel Mode Process 1 USER MODE KERNEL MODE Process 1Process 2 Time ExcpIntr Kernel control paths

8. Re-entrant Kernels Note: Not showing scheduler invocations Re-entrant kernel: Several processes may be in Kernel Mode at the same time –A re-entrant kernel is able to suspend the current running process even if it is in the Kernel Mode A kernel control path denotes the sequence of instructions executed by the kernel to handle a system call, an exception, or an interrupt Process 1 USER MODE KERNEL MODE Process 1Process 2 Time ExcpIntr Kernel control paths

9. Re-entrant Kernels Note: Not showing scheduler invocations Why re-entrancy? Process 1 USER MODE KERNEL MODE Process 1Process 2 Time ExcpIntr Kernel control paths

10. Re-entrant Kernels Note: Not showing scheduler invocations Why re-entrancy? –Improves throughput of devices controllers that raise interrupts –Allows priorities among interrupts Process 1 USER MODE KERNEL MODE Process 1Process 2 Time ExcpIntr Kernel control paths

11. Realizing re-entrancy: Take 1 Write kernel functions that only modify local variables and do not alter global variables –Re-entrant functions Pros and Cons?

12. Take 1: Write kernel functions that only modify local variables and do not alter global variables –Re-entrant functions Pros/Cons –Simplifies/complicates kernel programming (?) Realizing re-entrancy: Take 1

13. Realizing re-entrancy: Take 2 Kernel Mode Stacks We know: a process running in User Model refers to its private stack To allow re-entrancy, there is a Kernel Mode Stack for each process Each kernel control path uses its own private kernel stack Kept in part of RAM reserved for the kernel

14. Kernel Mode Stack PCB (task_struct) Stack KM stack and PCB need to be able to find each other KM stack must have access to a pointer to the PCB esp

15. Kernel Mode Stack thread_info structure PCB (task_struct) esp curent Stack KM stack and PCB need to be able to find each other KM stack must have access to a pointer to the PCB –Linux: thread_info PCB must have access to KM stack task

16. Kernel Mode Stack thread_info structure PCB (task_struct) esp curent Stack KM stack and PCB need to be able to find each other KM stack must have access to a pointer to the PCB –Linux: thread_info PCB must have access to KM stack thread_info task

17. Kernel Mode Stack thread_info structure PCB (task_struct) esp curent Stack Since KM stacks make little use of the stack, only a few thousand bytes suffice –An example of “Design for the most common case”, we’ll see more –Linux: 8KB, thread_info 52 bytes thread_info task

18. Kernel Mode Stack thread_info structure PCB (task_struct) esp curent Stack Since KM stacks make little use of the stack, only a few thousand bytes suffice –An example of “Design for the most common case”, we’ll see more –Linux: 8KB Why combine KM stack and thread_info into a union? thread_info union thread_union { struct thread_info thread_info; unsigned long stack[2048]; }; task

19. Kernel Mode Stack thread_info structure PCB (task_struct) esp curent Stack Since KM stacks make little use of the stack, only a few thousand bytes suffice –An example of “Design for the most common case”, we’ll see more –Linux: KM Stack 8KB, thread_info 52 bytes Why combine KM stack and thread_info into a union? –You might think spatial locality –The kernel can easily obtain the address of the thread_info structure of the process currently running on the CPU from the value of the esp register –task field is at offset 0 –Other benefits apply to multi-processors: makes it easy to efficiently find the current process on each processor Earlier approach: Have an array of current pointers thread_info task union thread_union { struct thread_info thread_info; unsigned long stack[2048]; };

20. Enumerating # Possible CPU Multiplexing Between Processes Consider two processes P1 and P2 –P1: n instructions –P2: m instructions –No jump instrictions => No loops How many unique executions are possible?