0% found this document useful (0 votes)
8 views21 pages

03 VirtualizeCPU

The document discusses how operating systems manage processes and share CPU resources through mechanisms like system calls, process switching via context switching, and interrupts. It covers how system calls allow restricted operations and how context switching provides an illusion of multiple CPUs through time sharing.

Uploaded by

shriyabedi17
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views21 pages

03 VirtualizeCPU

The document discusses how operating systems manage processes and share CPU resources through mechanisms like system calls, process switching via context switching, and interrupts. It covers how system calls allow restricted operations and how context switching provides an illusion of multiple CPUs through time sharing.

Uploaded by

shriyabedi17
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 21

2021-22 COMP3230A

 System Calls

 Process switch

 Interrupt

Principles of Operating Systems 2


 ILO2a - explain how OS manages processes/threads and
discuss the mechanisms and policies in efficiently sharing
of CPU resources.

Principles of Operating Systems 3


 Required Reading
 Chapter 6, Mechanism: Limited Direct Execution, Operating
Systems: Three Easy Pieces by Arpaci-Dusseau et. Al
 http://pages.cs.wisc.edu/~remzi/OSTEP/cpu-mechanisms.pdf

 Reference
 Chapter 3 of Operating Systems, 3rd edition by Deitel et. al

Principles of Operating Systems 4


 How to perform restricted operations?
 Mechanism: System Calls
Transparent:
 How to provide illusion of having many CPUs? • Process does not know
when it is running and
 Virtualizing the CPU
when it is not
 Mechanism: Context Switching • Programmer does not
need to worry about this
situation
 How to regain control of the CPU?
 Voluntary release of CPU
 Mechanism: System Calls

 Involuntary release of CPU


 Mechanism: Interrupt

Principles of Operating Systems 5


Application
 System calls allow the kernel to carefully expose
certain key services to applications API
 Restricted operations in user mode User mode
 Most OSs expose a few hundreds such functions Kernel mode System call interface

 Mostly accessed by programs via a high-level


Application Program Interface (API) rather than directly
invoke the specific system call
 Most common APIs are Win32 API for Windows, and POSIX API
for POSIX-based systems (including virtually all versions of UNIX,
Linux, and Mac OS X)
 Usually, in Unix system, the API is included in the run-time
support library (e.g. C library)

Principles of Operating Systems 6


 Why use APIs rather than directly invoke system calls?
 Caller does not need to know how the system call is
implemented and how to invoke a specific system call in that
particular OS

 Just needs to know how to use the common or standard API and
understand what OS will do / offer
 Most details of OS interface hidden from programmer by API
 The system call interface invokes intended system call in kernel and returns
status and results of the system call and pass back to calling program via
API

Principles of Operating Systems 7


Typically, the corresponding
library call contains a special
machine instruction (x86 – INT
or SYSCALL or SYSENTER)
Application
causing a “trap”, which results
in transfer control to the kernel
getpid( )
User mode
Kernel mode
System Call Interface
Before “trap” into kernel, either
the hardware or system call
function must sav e enough
sys_getpid()
process’s register context in
order to be able to return Implementation
correctly of getpid system
20 call in kernel

return

Principles of Operating Syst ems 8


Application

getpid( )
User mode

• Each system call is associated


Kernel mode
System Call Interface
with a number.
• This number is passed by the
function call to the kernel. sys_getpid()
Implementation
of getpid system
• Within kernel, the system-call 20 call in kernel
implementation maintains a table
indexed by these numbers. return
• Each entry consists of an address When finished, call a special
that points to the corresponding return-from-trap instruction (x86 -
system function in the kernel IRET or SYSRET or SYSEXIT) to
return into the calling user
Principles of Operating Syst ems program 9
OS @ run (kernel mode) Hardware Program (user mode)

Initialize trap table

Remember address of syscall handler

OS @ run (kernel mode) Hardware Program (user mode)


Create entry for process list; Allocate memory for
program; Load program into memory; Setup user
stack with argv; Fill kernel stack with reg/PC
return-from-trap
Restores regs (from kernel stack)
Move to user mode
Jump to main
Run main()…
Call system call
trap into OS
Save regs (to kernel stack)
Move to kernel mode
Jump to trap handler
Handle trap
Do work of system call
return-from-trap
Restore regs (from kernel stack)
Move to user mode
Jump to PC after trap

Return from main
trap (via exit())
Free memory of process
Remove from process list
 To provide illusion that each process has its own CPU
 By virtualizing, does not mean giving a virtual CPU
 The program is directly running on the real CPU
 Mechanism:
 Time sharing the CPU: By running one process, then stopping it and running
another, and so forth

 The Crux
 How to transparently and temporarily stop a process and resume it?
 With direct execution of application process on CPU, how can OS
regain control of the CPU?

Principles of Operating Systems 11


 To stop a process, one just needs to remove it from running in CPU (to
ready state)

 How can OS make sure that the process can be resumed without
affecting its execution logic?

 OS needs to save the register context (the contents of CPU registers) of current
running process before stopping it
 To resume, OS needs to restore the register context of the soon-to-be running
process back to CPU registers before resuming it

 Question: Where to store the register context?

 Context Switch
 Switching of the register context of one process to another

Principles of Operating Systems 12


 Action
 Save the “current” process’s register context to the process’s kernel
stack
 save the general purpose registers, PC, as well as the kernel stack pointer of the
currently-running process, and then restore said registers, PC, and switch to the kernel
stack for the soon-to-be-executing process.
 Other Actions
 Change the process’s state in PCB to appropriate status
 Move the process to appropriate queue
 Select a ready process (according to scheduling policy)
 Load the “to be dispatched” ready process’s register context from its PCB
 Update the process’s state of that going to be run process
 Resume that process by turning control over to that process

Principles of Operating Systems 13


 The CPU is considered as not performing any “useful”
computation for the application process
 OS must minimize context-switching time
 There are hardware instructions in some architectures that facilitates
the switching

 Has some indirect cost (induced overheads)


 The newly scheduled process may not have data and/or instructions in
the physical memory

 The newly scheduled process does not have any part of its address
space in cache

Principles of Operating Systems 14


 Mode switch
 Switching from user mode to kernel mode
 the Kernel is said to be “executing on behalf of the process”
 the process’s context remains accessible (e.g., address space)
 upon exiting kernel, the process may resume and return to execute in user
space

 Context switch
 Switching from one process to another
 is an essential feature of multiprogramming or time-sharing systems
 Kernel must
 (1) suspends the progression of current process and stores its context
 (2) retrieves the context of another process (B) and restores it to the CPU
 (3) resumes execution of process B

Principles of Operating Systems 15


 A Passive Approach
 OS just waits for a process to make system calls or an illegal operation
 Indeed, this works most of the time as processes quite frequently
invoke system calls
 However, in worst case, a process gets into an infinite loop and never
makes a system call, then what can OS do!!

 An Active Approach (assume non-cooperative processes)


 Needs hardware support: Timer Interrupt
 A timer device periodically generates an interrupt, e.g. every few
milliseconds
 When the interrupt is raised, OS will be called in to handle the interrupt,
and thus can do what it wants

Principles of Operating Systems 16


 Interrupt-request line triggered by hardware device
 Interrupts enable OS to respond to “alerts” from hardware

 May be triggered by a running process


 Interrupt in this case is called an exception
 Synchronous with the operation of the current process
 Unexpected event from within the processor
 e.g., dividing by zero or referencing protected memory

 May be initiated by some event that may or may not be related to the running process
 Asynchronous with the operation of the current process
 Unexpected event from outside the processor
 e.g., a key is pressed or the mouse is moved, timer events

 Software-generated interrupt
 the INT instruction

Principles of Operating Systems 17


The CPU control After receiv ing an interrupt,
processor the processor completes
responds to execution of the current
interrupts P1 instruction
and
exceptions Interrupt vector
in essentially Timer device
• OS has to sav e
the same remainder of
way. CPU has to sav e some register process state in
somewhere
contents when interrupt
occurred. It could be the • Jump to interrupt
whole set or just a few handler and

Interrupt
handler
registers. process the
interrupt
• Interrupt handlers are stored in an
array of function pointers called the
interrupt v ector
• OS sets up the v ector at boot time
The interrupt handler
• CPU reads from the system bus the determines how the
P2
interrupt v ector number prov ided by system should
an interrupt controller respond
• This number is used as an index to
locate the interrupt handler
Principles of Operating Syst ems 18
CPU control

P1

Interrupt vector
Timer device

After completion of
interrupt handling, a
decision has to be made

Interrupt
handler
by the Scheduler: restore
the interrupted process or
switch to a different one.

If the decision is to switch,


a context switch will be
made (slide # 13)
P2

Principles of Operating Syst ems 19


OS @ run (kernel mode) Hardware Program (user mode)
Initialize trap table
Remember address of syscall handler
Start interrupt timer
Start timer
I nterrupt CPU every x ms

OS @ run (kernel mode) Hardware Program (user mode)


Process A…

timer interrupt
Save regs(A) to kernel stack(A)
Move to kernel mode
Jump to trap handler
Handle trap
Call switch() routine to switch from A to B
return-from-trap (into B)
Restore regs(B) to kernel stack(B)
Move to kernel mode
Jump to B’s PC
Process B…
 Three mechanisms
 System call
 Each call represent a service provided by the OS to user application
 System mode will switch from user mode to kernel mode, and after the
service, will switch back from kernel mode to user mode
 Context switch
 The key action of virtualizing the CPU
 The whole set of register context must be saved for the interrupted process
 The register context of coming process are restored
 Context switch involves certain amount of performance overhead
 Interrupt processing
 A mechanism for hardware devices to alert OS for handling high-priority
events
 This gives a chance to OS to regain control of CPUs

Principles of Operating Systems 21

You might also like