Operating Systems CMPSC 473 Processes (3) September Lecture 9 Instructor: Bhuvan Urgaonkar

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

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

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

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

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

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

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

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

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

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?

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

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

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

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

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

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

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

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]; };

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?