1 / 20

Operating Systems CMPSC 473

Operating Systems CMPSC 473. Processes (3) September 17 2008 - Lecture 9 Instructor: Bhuvan Urgaonkar. Announcements . Suggested Reading for this lecture: Sections 3.1-3.3 Quiz 1: Will have several questions that came up during previous lectures. Overview of Process-related Topics.

edith
Télécharger la présentation

Operating Systems CMPSC 473

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Operating SystemsCMPSC 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 Process 1 Process 1 Process 2 Process 2 • Transitions between User and Kernel modes: An example USER MODE KERNEL MODE Sys call handler Scheduler Interrupt handler Time

  6. Re-entrant Kernels Process 1 Process 1 Process 2 • 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. USER MODE KERNEL MODE Excp Intr Intr Time Intr

  7. Re-entrant Kernels Process 1 Process 1 Process 2 • 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 USER MODE KERNEL MODE Excp Intr Intr Kernel control paths Time Intr

  8. Re-entrant Kernels Process 1 Process 1 Process 2 • 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 USER MODE KERNEL MODE Excp Intr Intr Kernel control paths Time Intr

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

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

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

  12. Realizingre-entrancy: Take 1 • 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 (?)

  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) • KM stack and PCB need to be able to find each other • KM stack must have access to a pointer to the PCB Stack esp

  15. Kernel Mode Stack PCB (task_struct) • 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 Stack esp task thread_info structure curent

  16. Kernel Mode Stack PCB (task_struct) • 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 Stack esp task thread_info structure curent thread_info

  17. Kernel Mode Stack PCB (task_struct) • 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 Stack esp task thread_info structure curent thread_info

  18. Kernel Mode Stack PCB (task_struct) • 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? Stack esp task thread_info structure curent thread_info • union thread_union { • struct thread_info thread_info; • unsigned long stack[2048]; • };

  19. Kernel Mode Stack PCB (task_struct) • 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 Stack esp task thread_info structure curent thread_info • 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?

More Related