Operating systems cmpsc 473
Download
1 / 20

Operating Systems CMPSC 473 - PowerPoint PPT Presentation


  • 101 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Operating Systems CMPSC 473' - edith


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Operating systems cmpsc 473

Operating SystemsCMPSC 473

Processes (3)

September 17 2008 - Lecture 9

Instructor: Bhuvan Urgaonkar


Announcements
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
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 topics1
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
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


Re entrant kernels
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


Re entrant kernels1
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


Re entrant kernels2
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


Re entrant kernels3
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


Re entrant kernels4
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


Realizing re entrancy take 1
Realizingre-entrancy: Take 1

  • Write kernel functions that only modify local variables and do not alter global variables

    • Re-entrant functions

  • Pros and Cons?


Realizing re entrancy take 11
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 (?)


Realizing re entrancy take 2
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
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


Kernel mode stack1
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


Kernel mode stack2
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


Kernel mode stack3
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


Kernel mode stack4
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];

    • };


Kernel mode stack5
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];

    • };


Enumerating possible cpu multiplexing between processes
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?


ad