Post on 17-Jan-2016
Operating System KernelMore Virtual Stuff
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 1
Why an OS
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 2
What wersquove got bull A Single Sequence Machine capable of doing ONE thing at a time ndash one instruction one IO operation one program bull A universe of gadgets ndash eg IO devices ndash that do similar things slightly differently
What wersquod like bull To listen to MP3s while reading email bull To access disk network and screen ldquosimultaneouslyrdquo bull To write a single program that does IO with anybodyrsquos disk
Plausible approaches bull An infinite supply of identical computers with uniform high-level peripherals for every conceivable purposehellip or bull An illusion Make one real computer look like many ldquovirtualrdquo ones
Operating Systems
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 3
An OS is the Glue that holds a
computer together
-Mediates between
competing requests
- Resolves
namesbindings
-Maintains
orderfairness
KERNEL - a RESIDENT portion
of the OS that handles the
most common and
fundamental service
requests
virtual vrch-(-)wl vr-chl vr-ch-wal-t-e- vrch-(-)w-le- vrch-(-)le- aj [ME possessed of certain physical virtues fr ML virtualis fr L virtus strengthvirtue being in essence or effect but not in fact - virtuality n
Review Virtual Memory
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 4
Goal create illusion of large virtual address spacebull divide address into (VPNoffset) map to (PPNoffset) or page faultbull use high address bits to select page keep related data on same pagebull use cache (TLB) to speed up mapping mechanismmdashworks wellbull long disk latencies keep working set in physical memory use write-back
D R PPN
VirtualMemory
PhysicalMemory
PAGEMAP
MMU Address Translation
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 5
Look in TLB VPNrarrPPN cacheUsually implemented as a small(16- 64) entry fully-associativecache
virtualpagenumber
32-bit virtual address
Page fault(handled by SW)
Typical Multi-level approach
These pages canbe ldquopaged outrdquo(stored on disk)
Contexts
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 6
THE BIG IDEA Several programs each with their own context may besimultaneously loaded into main memory
We might like to supportmultiple VIRTUAL toPHYSICAL Mappings andthus multiple Contexts
A context is an entire set of mappings from VIRTUAL to PHYSICAL pagenumbers as specified by the contents of the page map
ldquo Context switchrdquoreload the page map
D R PPN
Virtual Memory Physical Memory
PAGEMAP
VirtualMemory
1
VirtualMemory
2
PhysicalMemory
map map
Power of Contexts Sharing a CPU
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 7
1 TIMESHARING among several programs --bull Separate context for each programbull OS loads appropriate context into pagemap when switching
among pgms
2 Separate context for OS ldquoKernelrdquo (eg interrupt handlers)bull ldquoKernelrdquo vs ldquoUserrdquo contextsbull Switch to Kernel context on interruptbull Switch back on interrupt returnTYPICAL HARDWARE SUPPORT 2 HW pagemaps
Every application can bewritten as if it has accessto all of memory withoutconsidering where otherapplications reside
More than Virtual MemoryA VIRTUAL MACHINE
D R PPN
Virtual Memory Physical Memory
PAGEMAP
Building a Virtual Machine
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 8
Goal give each program its own ldquoVIRTUAL MACHINErdquo programs donrsquot ldquoknowrdquoabout each otherhellip
Abstraction create a process which has its own bull machine state R0 hellip R30 bull program (w shared code) bull context (virtual address space) bull virtual IO devices (consolehellip) bull stack
PROCESS 0
VirtualMemor
y
PhysicalMemory
Context 0
PROCESS 1
Context 1
VirtualMemor
y
Building a Virtual Machine
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 9
1 Running in process 02 Stop execution of process 0 either because of explicit yield or some sort of timer interrupt trap to handler code saving current PC in XP3 First save process 0 state (regs context) Then load process 1 state (regs context)4 ldquoReturnrdquo to process 1 just like return from other trap handlers (ie use address in XP) but wersquore returning from a different trap than happened in step 25 Running in process 1
When this process is interruptedWe RETURN to this process
Multiplexing the CPU
Key Technology Interrupts
Vir
tual ti
me
Interrupt HandlingA primitive constrained form of multiprocessing
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 10
BASIC SEQUENCE bull Program A is running when some EVENT happens bull PROCESSOR STATE saved on stack (like CALL) bull The HANDLER program to be run is selected bull HANDLER state (PC etc) installed as new processor state bull HANDLER runs to completion bull State of interrupted program A popped from stack and re-installed JMP returns control to A bull A continues unaware of interruption
ltSPgt
CHARACTERISTICS bull TRANSPARENT to interrupted program bull Handler runs to completion before returning bull Obeys stack discipline handler can borrow stack from interrupted program (and return it unchanged) or use a special handler stack
oldltSPgtSAVEDSTATEOF A
Beta Interrupt Handling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 11
Minimal Implementation bull Check for Interrupt Requests (IRQs) before each instruction fetch bull On IRQ j 1048707 bullcopy PC into Reg[XP] 1048707 bullINSTALL j4 as new PCHandler Coding bull Save state in ldquoUserrdquo structure bull Call C procedure to handle the exception bull re-install saved state from ldquoUserrdquo bull Return to Reg[XP]WHERE to find handlers bull BETA Scheme WIRE IN a low-memory address for each exception handler entry point bull Common alternative WIRE IN the address of a TABLE of handler addresses (ldquointerrupt vectorsrdquo)
User
RESETrarr 0x8000000
SAVEDSTATEOF A
ILLOPrarr 0x8000000
X_ADRrarr 0x8000000
External (Asynchronous)Interrupts
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 12
Example System maintains current time of day (TOD) count at a well-known memory location that can be accessed by programs Butthis value must be updated periodically in response to clock EVENTs ie signal triggered by 60 Hz clock hardware
Program A (Application) bull Executes instructions of the user program bull Doesnt want to know about clock hardware interrupts etc bull Can incorporate TOD into results by examining well-known memory location
Clock Handler bull GUTS Sequence of instructions that increments TOD Written in C bull EntryExit sequences save amp restore interrupted state call the C handler Written as assembler ldquostubsrdquo
Interrupt Handler Coding
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 13
Handler(written in C)
ldquoInterrupt stubrdquo(written in assy)
Simple Timesharing Scheduler
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 14
(PCB = Process Control Block)
Avoiding Re-entrance
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 15
Processor State K-Mode FlagPC31 = 1 for Kernel Mode
Handlers which are interruptable are called RE-ENTRANT and pose special problems Beta like many systems disallows reentrant interrupts Mechanism Uninterruptable ldquoKernel Moderdquo for OS
USER mode(Application)
KERNEL mode(Op Sys)
main() PC=0
PC=1User(savedstate)
ClockHandler
SVCHandler
sInterruptVector
PageFault
Handler
KernelStack
Other K-mode functions eg bull choosing KernalUser context bull Allowing ldquopriviledgedrdquo operations
Polled IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 16
Application code deals directly with IO (eg by busy-waiting)
loop LD(flagr0) BEQ(R0loop) hellip | process keystroke
PROBLEMS bull Uses up (physical) CPU while busy-waiting bull (FIX Multiprocessing codestripping etc) bull Poor system modularity running pgm MUST know about ALL devices bull Uses up CPU cycles even when device is idle
flag
dataCPU
INTERFACE DEVICE
KEY HITFlaglarr1DatalarrASCII
Interrupt-Driven IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 17
OPERATION NO attention to Keyboard during normal operation bull on key strike hardware asserts IRQ to request interrupt bull USER program interrupted PC+4 of interrupted inst saved in XP bull state of USER program saved on KERNEL stack bull KeyboardHandler invoked runs to completion bull state of USER program restored program resumes
TRANSPARENT to USER program
Keyboard Interrupt Handler (in OS KERNEL)
struct Device char Flag Data Keyboard
KeyboardHandler(struct Mstate s) Buffer[inptr] = KeyboardData inptr = (inptr + 1) 100
Assume eachkeyboard hasan associatedbuffer
ReadKey SVC Attempt 1
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 18
A supervisor call (SVC) is an instruction that transfers control to the kernel soit can satisfy some user request Kernel returns to user program whenrequest is complete
First draft of a ReadKey SVC handler returns next keystroke to user
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum while (BufferEmpty(kbdnum)) busy wait loop UserRegs[0] = ReadInputBuffer(kbdnum)
Problem Canrsquot interrupt code running in the supervisor modehellipso the buffer never gets filled
ReadKey SVC Attempt 2
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 19
A keyboard SVC handler (slightly modified eg to support a Virtual Keyboard)
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 else UserRegs[0] = ReadInputBuffer(kbdnum)
Problem The process just wastes its time-slice waiting for someone to hit a key
Thatrsquos afunny way
to writea loop
ReadKey SVC Attempt 3
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 20
BETTER On IO wait YIELD remainder of quantum
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 Scheduler( ) else UserRegs[0] = ReadInputBuffer(kbdnum)
RESULT Better CPU utilization
Does timesharing causes CPU use to be less efficient
bull COST Scheduling context-switching overhead but
bull GAIN Productive use of idle time of one process by running another
Sophisticated Scheduling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 21
To improve efficiency further we can avoid scheduling processes in
prolonged IO wait
bull Processes can be in ACTIVE or WAITING (ldquosleepingrdquo) states
bull Scheduler cycles among ACTIVE PROCESSES only
bull Active process moves to WAITING status when it tries to read
a character and buffer is empty
bull Waiting processes each contain a code (eg in PCB) designating
what they are waiting for (eg keyboard N)
bull Device interrupts (eg on keyboard N) move any processes
waiting on that device to ACTIVE state
UNIX kernel utilities
bull sleep(reason) - Puts CurProc to sleep ldquoReasonrdquo is an arbitrary
binary value giving a condition for reactivation
bull wakeup(reason) -Makes active any process in sleep(reason)
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 22
SVC call from application
INTERRUPT from Keyboard n
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 23
ldquoApplicationsrdquo are quasi-parallel
ldquoPROCESSESrdquo
on
ldquoVIRTUAL MACHINESrdquo
each with
bull- CONTEXT
bull (virtual address space)
bull- Virtual IO devices
OS KERNEL has
bull- Interrupt handlers
bull- SVC (trap) handlers
bull- Scheduler
bull- PCB structures containing the
state of inactive processesDevice
0Device
1Alarm Clock
SVC 0 handler
SVC 1 handler
SchedulerIO Handler IO Handler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler
Why an OS
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 2
What wersquove got bull A Single Sequence Machine capable of doing ONE thing at a time ndash one instruction one IO operation one program bull A universe of gadgets ndash eg IO devices ndash that do similar things slightly differently
What wersquod like bull To listen to MP3s while reading email bull To access disk network and screen ldquosimultaneouslyrdquo bull To write a single program that does IO with anybodyrsquos disk
Plausible approaches bull An infinite supply of identical computers with uniform high-level peripherals for every conceivable purposehellip or bull An illusion Make one real computer look like many ldquovirtualrdquo ones
Operating Systems
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 3
An OS is the Glue that holds a
computer together
-Mediates between
competing requests
- Resolves
namesbindings
-Maintains
orderfairness
KERNEL - a RESIDENT portion
of the OS that handles the
most common and
fundamental service
requests
virtual vrch-(-)wl vr-chl vr-ch-wal-t-e- vrch-(-)w-le- vrch-(-)le- aj [ME possessed of certain physical virtues fr ML virtualis fr L virtus strengthvirtue being in essence or effect but not in fact - virtuality n
Review Virtual Memory
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 4
Goal create illusion of large virtual address spacebull divide address into (VPNoffset) map to (PPNoffset) or page faultbull use high address bits to select page keep related data on same pagebull use cache (TLB) to speed up mapping mechanismmdashworks wellbull long disk latencies keep working set in physical memory use write-back
D R PPN
VirtualMemory
PhysicalMemory
PAGEMAP
MMU Address Translation
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 5
Look in TLB VPNrarrPPN cacheUsually implemented as a small(16- 64) entry fully-associativecache
virtualpagenumber
32-bit virtual address
Page fault(handled by SW)
Typical Multi-level approach
These pages canbe ldquopaged outrdquo(stored on disk)
Contexts
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 6
THE BIG IDEA Several programs each with their own context may besimultaneously loaded into main memory
We might like to supportmultiple VIRTUAL toPHYSICAL Mappings andthus multiple Contexts
A context is an entire set of mappings from VIRTUAL to PHYSICAL pagenumbers as specified by the contents of the page map
ldquo Context switchrdquoreload the page map
D R PPN
Virtual Memory Physical Memory
PAGEMAP
VirtualMemory
1
VirtualMemory
2
PhysicalMemory
map map
Power of Contexts Sharing a CPU
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 7
1 TIMESHARING among several programs --bull Separate context for each programbull OS loads appropriate context into pagemap when switching
among pgms
2 Separate context for OS ldquoKernelrdquo (eg interrupt handlers)bull ldquoKernelrdquo vs ldquoUserrdquo contextsbull Switch to Kernel context on interruptbull Switch back on interrupt returnTYPICAL HARDWARE SUPPORT 2 HW pagemaps
Every application can bewritten as if it has accessto all of memory withoutconsidering where otherapplications reside
More than Virtual MemoryA VIRTUAL MACHINE
D R PPN
Virtual Memory Physical Memory
PAGEMAP
Building a Virtual Machine
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 8
Goal give each program its own ldquoVIRTUAL MACHINErdquo programs donrsquot ldquoknowrdquoabout each otherhellip
Abstraction create a process which has its own bull machine state R0 hellip R30 bull program (w shared code) bull context (virtual address space) bull virtual IO devices (consolehellip) bull stack
PROCESS 0
VirtualMemor
y
PhysicalMemory
Context 0
PROCESS 1
Context 1
VirtualMemor
y
Building a Virtual Machine
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 9
1 Running in process 02 Stop execution of process 0 either because of explicit yield or some sort of timer interrupt trap to handler code saving current PC in XP3 First save process 0 state (regs context) Then load process 1 state (regs context)4 ldquoReturnrdquo to process 1 just like return from other trap handlers (ie use address in XP) but wersquore returning from a different trap than happened in step 25 Running in process 1
When this process is interruptedWe RETURN to this process
Multiplexing the CPU
Key Technology Interrupts
Vir
tual ti
me
Interrupt HandlingA primitive constrained form of multiprocessing
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 10
BASIC SEQUENCE bull Program A is running when some EVENT happens bull PROCESSOR STATE saved on stack (like CALL) bull The HANDLER program to be run is selected bull HANDLER state (PC etc) installed as new processor state bull HANDLER runs to completion bull State of interrupted program A popped from stack and re-installed JMP returns control to A bull A continues unaware of interruption
ltSPgt
CHARACTERISTICS bull TRANSPARENT to interrupted program bull Handler runs to completion before returning bull Obeys stack discipline handler can borrow stack from interrupted program (and return it unchanged) or use a special handler stack
oldltSPgtSAVEDSTATEOF A
Beta Interrupt Handling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 11
Minimal Implementation bull Check for Interrupt Requests (IRQs) before each instruction fetch bull On IRQ j 1048707 bullcopy PC into Reg[XP] 1048707 bullINSTALL j4 as new PCHandler Coding bull Save state in ldquoUserrdquo structure bull Call C procedure to handle the exception bull re-install saved state from ldquoUserrdquo bull Return to Reg[XP]WHERE to find handlers bull BETA Scheme WIRE IN a low-memory address for each exception handler entry point bull Common alternative WIRE IN the address of a TABLE of handler addresses (ldquointerrupt vectorsrdquo)
User
RESETrarr 0x8000000
SAVEDSTATEOF A
ILLOPrarr 0x8000000
X_ADRrarr 0x8000000
External (Asynchronous)Interrupts
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 12
Example System maintains current time of day (TOD) count at a well-known memory location that can be accessed by programs Butthis value must be updated periodically in response to clock EVENTs ie signal triggered by 60 Hz clock hardware
Program A (Application) bull Executes instructions of the user program bull Doesnt want to know about clock hardware interrupts etc bull Can incorporate TOD into results by examining well-known memory location
Clock Handler bull GUTS Sequence of instructions that increments TOD Written in C bull EntryExit sequences save amp restore interrupted state call the C handler Written as assembler ldquostubsrdquo
Interrupt Handler Coding
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 13
Handler(written in C)
ldquoInterrupt stubrdquo(written in assy)
Simple Timesharing Scheduler
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 14
(PCB = Process Control Block)
Avoiding Re-entrance
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 15
Processor State K-Mode FlagPC31 = 1 for Kernel Mode
Handlers which are interruptable are called RE-ENTRANT and pose special problems Beta like many systems disallows reentrant interrupts Mechanism Uninterruptable ldquoKernel Moderdquo for OS
USER mode(Application)
KERNEL mode(Op Sys)
main() PC=0
PC=1User(savedstate)
ClockHandler
SVCHandler
sInterruptVector
PageFault
Handler
KernelStack
Other K-mode functions eg bull choosing KernalUser context bull Allowing ldquopriviledgedrdquo operations
Polled IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 16
Application code deals directly with IO (eg by busy-waiting)
loop LD(flagr0) BEQ(R0loop) hellip | process keystroke
PROBLEMS bull Uses up (physical) CPU while busy-waiting bull (FIX Multiprocessing codestripping etc) bull Poor system modularity running pgm MUST know about ALL devices bull Uses up CPU cycles even when device is idle
flag
dataCPU
INTERFACE DEVICE
KEY HITFlaglarr1DatalarrASCII
Interrupt-Driven IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 17
OPERATION NO attention to Keyboard during normal operation bull on key strike hardware asserts IRQ to request interrupt bull USER program interrupted PC+4 of interrupted inst saved in XP bull state of USER program saved on KERNEL stack bull KeyboardHandler invoked runs to completion bull state of USER program restored program resumes
TRANSPARENT to USER program
Keyboard Interrupt Handler (in OS KERNEL)
struct Device char Flag Data Keyboard
KeyboardHandler(struct Mstate s) Buffer[inptr] = KeyboardData inptr = (inptr + 1) 100
Assume eachkeyboard hasan associatedbuffer
ReadKey SVC Attempt 1
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 18
A supervisor call (SVC) is an instruction that transfers control to the kernel soit can satisfy some user request Kernel returns to user program whenrequest is complete
First draft of a ReadKey SVC handler returns next keystroke to user
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum while (BufferEmpty(kbdnum)) busy wait loop UserRegs[0] = ReadInputBuffer(kbdnum)
Problem Canrsquot interrupt code running in the supervisor modehellipso the buffer never gets filled
ReadKey SVC Attempt 2
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 19
A keyboard SVC handler (slightly modified eg to support a Virtual Keyboard)
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 else UserRegs[0] = ReadInputBuffer(kbdnum)
Problem The process just wastes its time-slice waiting for someone to hit a key
Thatrsquos afunny way
to writea loop
ReadKey SVC Attempt 3
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 20
BETTER On IO wait YIELD remainder of quantum
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 Scheduler( ) else UserRegs[0] = ReadInputBuffer(kbdnum)
RESULT Better CPU utilization
Does timesharing causes CPU use to be less efficient
bull COST Scheduling context-switching overhead but
bull GAIN Productive use of idle time of one process by running another
Sophisticated Scheduling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 21
To improve efficiency further we can avoid scheduling processes in
prolonged IO wait
bull Processes can be in ACTIVE or WAITING (ldquosleepingrdquo) states
bull Scheduler cycles among ACTIVE PROCESSES only
bull Active process moves to WAITING status when it tries to read
a character and buffer is empty
bull Waiting processes each contain a code (eg in PCB) designating
what they are waiting for (eg keyboard N)
bull Device interrupts (eg on keyboard N) move any processes
waiting on that device to ACTIVE state
UNIX kernel utilities
bull sleep(reason) - Puts CurProc to sleep ldquoReasonrdquo is an arbitrary
binary value giving a condition for reactivation
bull wakeup(reason) -Makes active any process in sleep(reason)
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 22
SVC call from application
INTERRUPT from Keyboard n
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 23
ldquoApplicationsrdquo are quasi-parallel
ldquoPROCESSESrdquo
on
ldquoVIRTUAL MACHINESrdquo
each with
bull- CONTEXT
bull (virtual address space)
bull- Virtual IO devices
OS KERNEL has
bull- Interrupt handlers
bull- SVC (trap) handlers
bull- Scheduler
bull- PCB structures containing the
state of inactive processesDevice
0Device
1Alarm Clock
SVC 0 handler
SVC 1 handler
SchedulerIO Handler IO Handler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler
Operating Systems
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 3
An OS is the Glue that holds a
computer together
-Mediates between
competing requests
- Resolves
namesbindings
-Maintains
orderfairness
KERNEL - a RESIDENT portion
of the OS that handles the
most common and
fundamental service
requests
virtual vrch-(-)wl vr-chl vr-ch-wal-t-e- vrch-(-)w-le- vrch-(-)le- aj [ME possessed of certain physical virtues fr ML virtualis fr L virtus strengthvirtue being in essence or effect but not in fact - virtuality n
Review Virtual Memory
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 4
Goal create illusion of large virtual address spacebull divide address into (VPNoffset) map to (PPNoffset) or page faultbull use high address bits to select page keep related data on same pagebull use cache (TLB) to speed up mapping mechanismmdashworks wellbull long disk latencies keep working set in physical memory use write-back
D R PPN
VirtualMemory
PhysicalMemory
PAGEMAP
MMU Address Translation
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 5
Look in TLB VPNrarrPPN cacheUsually implemented as a small(16- 64) entry fully-associativecache
virtualpagenumber
32-bit virtual address
Page fault(handled by SW)
Typical Multi-level approach
These pages canbe ldquopaged outrdquo(stored on disk)
Contexts
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 6
THE BIG IDEA Several programs each with their own context may besimultaneously loaded into main memory
We might like to supportmultiple VIRTUAL toPHYSICAL Mappings andthus multiple Contexts
A context is an entire set of mappings from VIRTUAL to PHYSICAL pagenumbers as specified by the contents of the page map
ldquo Context switchrdquoreload the page map
D R PPN
Virtual Memory Physical Memory
PAGEMAP
VirtualMemory
1
VirtualMemory
2
PhysicalMemory
map map
Power of Contexts Sharing a CPU
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 7
1 TIMESHARING among several programs --bull Separate context for each programbull OS loads appropriate context into pagemap when switching
among pgms
2 Separate context for OS ldquoKernelrdquo (eg interrupt handlers)bull ldquoKernelrdquo vs ldquoUserrdquo contextsbull Switch to Kernel context on interruptbull Switch back on interrupt returnTYPICAL HARDWARE SUPPORT 2 HW pagemaps
Every application can bewritten as if it has accessto all of memory withoutconsidering where otherapplications reside
More than Virtual MemoryA VIRTUAL MACHINE
D R PPN
Virtual Memory Physical Memory
PAGEMAP
Building a Virtual Machine
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 8
Goal give each program its own ldquoVIRTUAL MACHINErdquo programs donrsquot ldquoknowrdquoabout each otherhellip
Abstraction create a process which has its own bull machine state R0 hellip R30 bull program (w shared code) bull context (virtual address space) bull virtual IO devices (consolehellip) bull stack
PROCESS 0
VirtualMemor
y
PhysicalMemory
Context 0
PROCESS 1
Context 1
VirtualMemor
y
Building a Virtual Machine
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 9
1 Running in process 02 Stop execution of process 0 either because of explicit yield or some sort of timer interrupt trap to handler code saving current PC in XP3 First save process 0 state (regs context) Then load process 1 state (regs context)4 ldquoReturnrdquo to process 1 just like return from other trap handlers (ie use address in XP) but wersquore returning from a different trap than happened in step 25 Running in process 1
When this process is interruptedWe RETURN to this process
Multiplexing the CPU
Key Technology Interrupts
Vir
tual ti
me
Interrupt HandlingA primitive constrained form of multiprocessing
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 10
BASIC SEQUENCE bull Program A is running when some EVENT happens bull PROCESSOR STATE saved on stack (like CALL) bull The HANDLER program to be run is selected bull HANDLER state (PC etc) installed as new processor state bull HANDLER runs to completion bull State of interrupted program A popped from stack and re-installed JMP returns control to A bull A continues unaware of interruption
ltSPgt
CHARACTERISTICS bull TRANSPARENT to interrupted program bull Handler runs to completion before returning bull Obeys stack discipline handler can borrow stack from interrupted program (and return it unchanged) or use a special handler stack
oldltSPgtSAVEDSTATEOF A
Beta Interrupt Handling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 11
Minimal Implementation bull Check for Interrupt Requests (IRQs) before each instruction fetch bull On IRQ j 1048707 bullcopy PC into Reg[XP] 1048707 bullINSTALL j4 as new PCHandler Coding bull Save state in ldquoUserrdquo structure bull Call C procedure to handle the exception bull re-install saved state from ldquoUserrdquo bull Return to Reg[XP]WHERE to find handlers bull BETA Scheme WIRE IN a low-memory address for each exception handler entry point bull Common alternative WIRE IN the address of a TABLE of handler addresses (ldquointerrupt vectorsrdquo)
User
RESETrarr 0x8000000
SAVEDSTATEOF A
ILLOPrarr 0x8000000
X_ADRrarr 0x8000000
External (Asynchronous)Interrupts
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 12
Example System maintains current time of day (TOD) count at a well-known memory location that can be accessed by programs Butthis value must be updated periodically in response to clock EVENTs ie signal triggered by 60 Hz clock hardware
Program A (Application) bull Executes instructions of the user program bull Doesnt want to know about clock hardware interrupts etc bull Can incorporate TOD into results by examining well-known memory location
Clock Handler bull GUTS Sequence of instructions that increments TOD Written in C bull EntryExit sequences save amp restore interrupted state call the C handler Written as assembler ldquostubsrdquo
Interrupt Handler Coding
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 13
Handler(written in C)
ldquoInterrupt stubrdquo(written in assy)
Simple Timesharing Scheduler
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 14
(PCB = Process Control Block)
Avoiding Re-entrance
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 15
Processor State K-Mode FlagPC31 = 1 for Kernel Mode
Handlers which are interruptable are called RE-ENTRANT and pose special problems Beta like many systems disallows reentrant interrupts Mechanism Uninterruptable ldquoKernel Moderdquo for OS
USER mode(Application)
KERNEL mode(Op Sys)
main() PC=0
PC=1User(savedstate)
ClockHandler
SVCHandler
sInterruptVector
PageFault
Handler
KernelStack
Other K-mode functions eg bull choosing KernalUser context bull Allowing ldquopriviledgedrdquo operations
Polled IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 16
Application code deals directly with IO (eg by busy-waiting)
loop LD(flagr0) BEQ(R0loop) hellip | process keystroke
PROBLEMS bull Uses up (physical) CPU while busy-waiting bull (FIX Multiprocessing codestripping etc) bull Poor system modularity running pgm MUST know about ALL devices bull Uses up CPU cycles even when device is idle
flag
dataCPU
INTERFACE DEVICE
KEY HITFlaglarr1DatalarrASCII
Interrupt-Driven IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 17
OPERATION NO attention to Keyboard during normal operation bull on key strike hardware asserts IRQ to request interrupt bull USER program interrupted PC+4 of interrupted inst saved in XP bull state of USER program saved on KERNEL stack bull KeyboardHandler invoked runs to completion bull state of USER program restored program resumes
TRANSPARENT to USER program
Keyboard Interrupt Handler (in OS KERNEL)
struct Device char Flag Data Keyboard
KeyboardHandler(struct Mstate s) Buffer[inptr] = KeyboardData inptr = (inptr + 1) 100
Assume eachkeyboard hasan associatedbuffer
ReadKey SVC Attempt 1
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 18
A supervisor call (SVC) is an instruction that transfers control to the kernel soit can satisfy some user request Kernel returns to user program whenrequest is complete
First draft of a ReadKey SVC handler returns next keystroke to user
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum while (BufferEmpty(kbdnum)) busy wait loop UserRegs[0] = ReadInputBuffer(kbdnum)
Problem Canrsquot interrupt code running in the supervisor modehellipso the buffer never gets filled
ReadKey SVC Attempt 2
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 19
A keyboard SVC handler (slightly modified eg to support a Virtual Keyboard)
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 else UserRegs[0] = ReadInputBuffer(kbdnum)
Problem The process just wastes its time-slice waiting for someone to hit a key
Thatrsquos afunny way
to writea loop
ReadKey SVC Attempt 3
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 20
BETTER On IO wait YIELD remainder of quantum
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 Scheduler( ) else UserRegs[0] = ReadInputBuffer(kbdnum)
RESULT Better CPU utilization
Does timesharing causes CPU use to be less efficient
bull COST Scheduling context-switching overhead but
bull GAIN Productive use of idle time of one process by running another
Sophisticated Scheduling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 21
To improve efficiency further we can avoid scheduling processes in
prolonged IO wait
bull Processes can be in ACTIVE or WAITING (ldquosleepingrdquo) states
bull Scheduler cycles among ACTIVE PROCESSES only
bull Active process moves to WAITING status when it tries to read
a character and buffer is empty
bull Waiting processes each contain a code (eg in PCB) designating
what they are waiting for (eg keyboard N)
bull Device interrupts (eg on keyboard N) move any processes
waiting on that device to ACTIVE state
UNIX kernel utilities
bull sleep(reason) - Puts CurProc to sleep ldquoReasonrdquo is an arbitrary
binary value giving a condition for reactivation
bull wakeup(reason) -Makes active any process in sleep(reason)
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 22
SVC call from application
INTERRUPT from Keyboard n
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 23
ldquoApplicationsrdquo are quasi-parallel
ldquoPROCESSESrdquo
on
ldquoVIRTUAL MACHINESrdquo
each with
bull- CONTEXT
bull (virtual address space)
bull- Virtual IO devices
OS KERNEL has
bull- Interrupt handlers
bull- SVC (trap) handlers
bull- Scheduler
bull- PCB structures containing the
state of inactive processesDevice
0Device
1Alarm Clock
SVC 0 handler
SVC 1 handler
SchedulerIO Handler IO Handler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler
Review Virtual Memory
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 4
Goal create illusion of large virtual address spacebull divide address into (VPNoffset) map to (PPNoffset) or page faultbull use high address bits to select page keep related data on same pagebull use cache (TLB) to speed up mapping mechanismmdashworks wellbull long disk latencies keep working set in physical memory use write-back
D R PPN
VirtualMemory
PhysicalMemory
PAGEMAP
MMU Address Translation
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 5
Look in TLB VPNrarrPPN cacheUsually implemented as a small(16- 64) entry fully-associativecache
virtualpagenumber
32-bit virtual address
Page fault(handled by SW)
Typical Multi-level approach
These pages canbe ldquopaged outrdquo(stored on disk)
Contexts
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 6
THE BIG IDEA Several programs each with their own context may besimultaneously loaded into main memory
We might like to supportmultiple VIRTUAL toPHYSICAL Mappings andthus multiple Contexts
A context is an entire set of mappings from VIRTUAL to PHYSICAL pagenumbers as specified by the contents of the page map
ldquo Context switchrdquoreload the page map
D R PPN
Virtual Memory Physical Memory
PAGEMAP
VirtualMemory
1
VirtualMemory
2
PhysicalMemory
map map
Power of Contexts Sharing a CPU
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 7
1 TIMESHARING among several programs --bull Separate context for each programbull OS loads appropriate context into pagemap when switching
among pgms
2 Separate context for OS ldquoKernelrdquo (eg interrupt handlers)bull ldquoKernelrdquo vs ldquoUserrdquo contextsbull Switch to Kernel context on interruptbull Switch back on interrupt returnTYPICAL HARDWARE SUPPORT 2 HW pagemaps
Every application can bewritten as if it has accessto all of memory withoutconsidering where otherapplications reside
More than Virtual MemoryA VIRTUAL MACHINE
D R PPN
Virtual Memory Physical Memory
PAGEMAP
Building a Virtual Machine
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 8
Goal give each program its own ldquoVIRTUAL MACHINErdquo programs donrsquot ldquoknowrdquoabout each otherhellip
Abstraction create a process which has its own bull machine state R0 hellip R30 bull program (w shared code) bull context (virtual address space) bull virtual IO devices (consolehellip) bull stack
PROCESS 0
VirtualMemor
y
PhysicalMemory
Context 0
PROCESS 1
Context 1
VirtualMemor
y
Building a Virtual Machine
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 9
1 Running in process 02 Stop execution of process 0 either because of explicit yield or some sort of timer interrupt trap to handler code saving current PC in XP3 First save process 0 state (regs context) Then load process 1 state (regs context)4 ldquoReturnrdquo to process 1 just like return from other trap handlers (ie use address in XP) but wersquore returning from a different trap than happened in step 25 Running in process 1
When this process is interruptedWe RETURN to this process
Multiplexing the CPU
Key Technology Interrupts
Vir
tual ti
me
Interrupt HandlingA primitive constrained form of multiprocessing
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 10
BASIC SEQUENCE bull Program A is running when some EVENT happens bull PROCESSOR STATE saved on stack (like CALL) bull The HANDLER program to be run is selected bull HANDLER state (PC etc) installed as new processor state bull HANDLER runs to completion bull State of interrupted program A popped from stack and re-installed JMP returns control to A bull A continues unaware of interruption
ltSPgt
CHARACTERISTICS bull TRANSPARENT to interrupted program bull Handler runs to completion before returning bull Obeys stack discipline handler can borrow stack from interrupted program (and return it unchanged) or use a special handler stack
oldltSPgtSAVEDSTATEOF A
Beta Interrupt Handling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 11
Minimal Implementation bull Check for Interrupt Requests (IRQs) before each instruction fetch bull On IRQ j 1048707 bullcopy PC into Reg[XP] 1048707 bullINSTALL j4 as new PCHandler Coding bull Save state in ldquoUserrdquo structure bull Call C procedure to handle the exception bull re-install saved state from ldquoUserrdquo bull Return to Reg[XP]WHERE to find handlers bull BETA Scheme WIRE IN a low-memory address for each exception handler entry point bull Common alternative WIRE IN the address of a TABLE of handler addresses (ldquointerrupt vectorsrdquo)
User
RESETrarr 0x8000000
SAVEDSTATEOF A
ILLOPrarr 0x8000000
X_ADRrarr 0x8000000
External (Asynchronous)Interrupts
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 12
Example System maintains current time of day (TOD) count at a well-known memory location that can be accessed by programs Butthis value must be updated periodically in response to clock EVENTs ie signal triggered by 60 Hz clock hardware
Program A (Application) bull Executes instructions of the user program bull Doesnt want to know about clock hardware interrupts etc bull Can incorporate TOD into results by examining well-known memory location
Clock Handler bull GUTS Sequence of instructions that increments TOD Written in C bull EntryExit sequences save amp restore interrupted state call the C handler Written as assembler ldquostubsrdquo
Interrupt Handler Coding
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 13
Handler(written in C)
ldquoInterrupt stubrdquo(written in assy)
Simple Timesharing Scheduler
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 14
(PCB = Process Control Block)
Avoiding Re-entrance
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 15
Processor State K-Mode FlagPC31 = 1 for Kernel Mode
Handlers which are interruptable are called RE-ENTRANT and pose special problems Beta like many systems disallows reentrant interrupts Mechanism Uninterruptable ldquoKernel Moderdquo for OS
USER mode(Application)
KERNEL mode(Op Sys)
main() PC=0
PC=1User(savedstate)
ClockHandler
SVCHandler
sInterruptVector
PageFault
Handler
KernelStack
Other K-mode functions eg bull choosing KernalUser context bull Allowing ldquopriviledgedrdquo operations
Polled IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 16
Application code deals directly with IO (eg by busy-waiting)
loop LD(flagr0) BEQ(R0loop) hellip | process keystroke
PROBLEMS bull Uses up (physical) CPU while busy-waiting bull (FIX Multiprocessing codestripping etc) bull Poor system modularity running pgm MUST know about ALL devices bull Uses up CPU cycles even when device is idle
flag
dataCPU
INTERFACE DEVICE
KEY HITFlaglarr1DatalarrASCII
Interrupt-Driven IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 17
OPERATION NO attention to Keyboard during normal operation bull on key strike hardware asserts IRQ to request interrupt bull USER program interrupted PC+4 of interrupted inst saved in XP bull state of USER program saved on KERNEL stack bull KeyboardHandler invoked runs to completion bull state of USER program restored program resumes
TRANSPARENT to USER program
Keyboard Interrupt Handler (in OS KERNEL)
struct Device char Flag Data Keyboard
KeyboardHandler(struct Mstate s) Buffer[inptr] = KeyboardData inptr = (inptr + 1) 100
Assume eachkeyboard hasan associatedbuffer
ReadKey SVC Attempt 1
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 18
A supervisor call (SVC) is an instruction that transfers control to the kernel soit can satisfy some user request Kernel returns to user program whenrequest is complete
First draft of a ReadKey SVC handler returns next keystroke to user
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum while (BufferEmpty(kbdnum)) busy wait loop UserRegs[0] = ReadInputBuffer(kbdnum)
Problem Canrsquot interrupt code running in the supervisor modehellipso the buffer never gets filled
ReadKey SVC Attempt 2
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 19
A keyboard SVC handler (slightly modified eg to support a Virtual Keyboard)
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 else UserRegs[0] = ReadInputBuffer(kbdnum)
Problem The process just wastes its time-slice waiting for someone to hit a key
Thatrsquos afunny way
to writea loop
ReadKey SVC Attempt 3
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 20
BETTER On IO wait YIELD remainder of quantum
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 Scheduler( ) else UserRegs[0] = ReadInputBuffer(kbdnum)
RESULT Better CPU utilization
Does timesharing causes CPU use to be less efficient
bull COST Scheduling context-switching overhead but
bull GAIN Productive use of idle time of one process by running another
Sophisticated Scheduling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 21
To improve efficiency further we can avoid scheduling processes in
prolonged IO wait
bull Processes can be in ACTIVE or WAITING (ldquosleepingrdquo) states
bull Scheduler cycles among ACTIVE PROCESSES only
bull Active process moves to WAITING status when it tries to read
a character and buffer is empty
bull Waiting processes each contain a code (eg in PCB) designating
what they are waiting for (eg keyboard N)
bull Device interrupts (eg on keyboard N) move any processes
waiting on that device to ACTIVE state
UNIX kernel utilities
bull sleep(reason) - Puts CurProc to sleep ldquoReasonrdquo is an arbitrary
binary value giving a condition for reactivation
bull wakeup(reason) -Makes active any process in sleep(reason)
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 22
SVC call from application
INTERRUPT from Keyboard n
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 23
ldquoApplicationsrdquo are quasi-parallel
ldquoPROCESSESrdquo
on
ldquoVIRTUAL MACHINESrdquo
each with
bull- CONTEXT
bull (virtual address space)
bull- Virtual IO devices
OS KERNEL has
bull- Interrupt handlers
bull- SVC (trap) handlers
bull- Scheduler
bull- PCB structures containing the
state of inactive processesDevice
0Device
1Alarm Clock
SVC 0 handler
SVC 1 handler
SchedulerIO Handler IO Handler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler
MMU Address Translation
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 5
Look in TLB VPNrarrPPN cacheUsually implemented as a small(16- 64) entry fully-associativecache
virtualpagenumber
32-bit virtual address
Page fault(handled by SW)
Typical Multi-level approach
These pages canbe ldquopaged outrdquo(stored on disk)
Contexts
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 6
THE BIG IDEA Several programs each with their own context may besimultaneously loaded into main memory
We might like to supportmultiple VIRTUAL toPHYSICAL Mappings andthus multiple Contexts
A context is an entire set of mappings from VIRTUAL to PHYSICAL pagenumbers as specified by the contents of the page map
ldquo Context switchrdquoreload the page map
D R PPN
Virtual Memory Physical Memory
PAGEMAP
VirtualMemory
1
VirtualMemory
2
PhysicalMemory
map map
Power of Contexts Sharing a CPU
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 7
1 TIMESHARING among several programs --bull Separate context for each programbull OS loads appropriate context into pagemap when switching
among pgms
2 Separate context for OS ldquoKernelrdquo (eg interrupt handlers)bull ldquoKernelrdquo vs ldquoUserrdquo contextsbull Switch to Kernel context on interruptbull Switch back on interrupt returnTYPICAL HARDWARE SUPPORT 2 HW pagemaps
Every application can bewritten as if it has accessto all of memory withoutconsidering where otherapplications reside
More than Virtual MemoryA VIRTUAL MACHINE
D R PPN
Virtual Memory Physical Memory
PAGEMAP
Building a Virtual Machine
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 8
Goal give each program its own ldquoVIRTUAL MACHINErdquo programs donrsquot ldquoknowrdquoabout each otherhellip
Abstraction create a process which has its own bull machine state R0 hellip R30 bull program (w shared code) bull context (virtual address space) bull virtual IO devices (consolehellip) bull stack
PROCESS 0
VirtualMemor
y
PhysicalMemory
Context 0
PROCESS 1
Context 1
VirtualMemor
y
Building a Virtual Machine
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 9
1 Running in process 02 Stop execution of process 0 either because of explicit yield or some sort of timer interrupt trap to handler code saving current PC in XP3 First save process 0 state (regs context) Then load process 1 state (regs context)4 ldquoReturnrdquo to process 1 just like return from other trap handlers (ie use address in XP) but wersquore returning from a different trap than happened in step 25 Running in process 1
When this process is interruptedWe RETURN to this process
Multiplexing the CPU
Key Technology Interrupts
Vir
tual ti
me
Interrupt HandlingA primitive constrained form of multiprocessing
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 10
BASIC SEQUENCE bull Program A is running when some EVENT happens bull PROCESSOR STATE saved on stack (like CALL) bull The HANDLER program to be run is selected bull HANDLER state (PC etc) installed as new processor state bull HANDLER runs to completion bull State of interrupted program A popped from stack and re-installed JMP returns control to A bull A continues unaware of interruption
ltSPgt
CHARACTERISTICS bull TRANSPARENT to interrupted program bull Handler runs to completion before returning bull Obeys stack discipline handler can borrow stack from interrupted program (and return it unchanged) or use a special handler stack
oldltSPgtSAVEDSTATEOF A
Beta Interrupt Handling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 11
Minimal Implementation bull Check for Interrupt Requests (IRQs) before each instruction fetch bull On IRQ j 1048707 bullcopy PC into Reg[XP] 1048707 bullINSTALL j4 as new PCHandler Coding bull Save state in ldquoUserrdquo structure bull Call C procedure to handle the exception bull re-install saved state from ldquoUserrdquo bull Return to Reg[XP]WHERE to find handlers bull BETA Scheme WIRE IN a low-memory address for each exception handler entry point bull Common alternative WIRE IN the address of a TABLE of handler addresses (ldquointerrupt vectorsrdquo)
User
RESETrarr 0x8000000
SAVEDSTATEOF A
ILLOPrarr 0x8000000
X_ADRrarr 0x8000000
External (Asynchronous)Interrupts
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 12
Example System maintains current time of day (TOD) count at a well-known memory location that can be accessed by programs Butthis value must be updated periodically in response to clock EVENTs ie signal triggered by 60 Hz clock hardware
Program A (Application) bull Executes instructions of the user program bull Doesnt want to know about clock hardware interrupts etc bull Can incorporate TOD into results by examining well-known memory location
Clock Handler bull GUTS Sequence of instructions that increments TOD Written in C bull EntryExit sequences save amp restore interrupted state call the C handler Written as assembler ldquostubsrdquo
Interrupt Handler Coding
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 13
Handler(written in C)
ldquoInterrupt stubrdquo(written in assy)
Simple Timesharing Scheduler
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 14
(PCB = Process Control Block)
Avoiding Re-entrance
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 15
Processor State K-Mode FlagPC31 = 1 for Kernel Mode
Handlers which are interruptable are called RE-ENTRANT and pose special problems Beta like many systems disallows reentrant interrupts Mechanism Uninterruptable ldquoKernel Moderdquo for OS
USER mode(Application)
KERNEL mode(Op Sys)
main() PC=0
PC=1User(savedstate)
ClockHandler
SVCHandler
sInterruptVector
PageFault
Handler
KernelStack
Other K-mode functions eg bull choosing KernalUser context bull Allowing ldquopriviledgedrdquo operations
Polled IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 16
Application code deals directly with IO (eg by busy-waiting)
loop LD(flagr0) BEQ(R0loop) hellip | process keystroke
PROBLEMS bull Uses up (physical) CPU while busy-waiting bull (FIX Multiprocessing codestripping etc) bull Poor system modularity running pgm MUST know about ALL devices bull Uses up CPU cycles even when device is idle
flag
dataCPU
INTERFACE DEVICE
KEY HITFlaglarr1DatalarrASCII
Interrupt-Driven IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 17
OPERATION NO attention to Keyboard during normal operation bull on key strike hardware asserts IRQ to request interrupt bull USER program interrupted PC+4 of interrupted inst saved in XP bull state of USER program saved on KERNEL stack bull KeyboardHandler invoked runs to completion bull state of USER program restored program resumes
TRANSPARENT to USER program
Keyboard Interrupt Handler (in OS KERNEL)
struct Device char Flag Data Keyboard
KeyboardHandler(struct Mstate s) Buffer[inptr] = KeyboardData inptr = (inptr + 1) 100
Assume eachkeyboard hasan associatedbuffer
ReadKey SVC Attempt 1
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 18
A supervisor call (SVC) is an instruction that transfers control to the kernel soit can satisfy some user request Kernel returns to user program whenrequest is complete
First draft of a ReadKey SVC handler returns next keystroke to user
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum while (BufferEmpty(kbdnum)) busy wait loop UserRegs[0] = ReadInputBuffer(kbdnum)
Problem Canrsquot interrupt code running in the supervisor modehellipso the buffer never gets filled
ReadKey SVC Attempt 2
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 19
A keyboard SVC handler (slightly modified eg to support a Virtual Keyboard)
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 else UserRegs[0] = ReadInputBuffer(kbdnum)
Problem The process just wastes its time-slice waiting for someone to hit a key
Thatrsquos afunny way
to writea loop
ReadKey SVC Attempt 3
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 20
BETTER On IO wait YIELD remainder of quantum
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 Scheduler( ) else UserRegs[0] = ReadInputBuffer(kbdnum)
RESULT Better CPU utilization
Does timesharing causes CPU use to be less efficient
bull COST Scheduling context-switching overhead but
bull GAIN Productive use of idle time of one process by running another
Sophisticated Scheduling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 21
To improve efficiency further we can avoid scheduling processes in
prolonged IO wait
bull Processes can be in ACTIVE or WAITING (ldquosleepingrdquo) states
bull Scheduler cycles among ACTIVE PROCESSES only
bull Active process moves to WAITING status when it tries to read
a character and buffer is empty
bull Waiting processes each contain a code (eg in PCB) designating
what they are waiting for (eg keyboard N)
bull Device interrupts (eg on keyboard N) move any processes
waiting on that device to ACTIVE state
UNIX kernel utilities
bull sleep(reason) - Puts CurProc to sleep ldquoReasonrdquo is an arbitrary
binary value giving a condition for reactivation
bull wakeup(reason) -Makes active any process in sleep(reason)
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 22
SVC call from application
INTERRUPT from Keyboard n
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 23
ldquoApplicationsrdquo are quasi-parallel
ldquoPROCESSESrdquo
on
ldquoVIRTUAL MACHINESrdquo
each with
bull- CONTEXT
bull (virtual address space)
bull- Virtual IO devices
OS KERNEL has
bull- Interrupt handlers
bull- SVC (trap) handlers
bull- Scheduler
bull- PCB structures containing the
state of inactive processesDevice
0Device
1Alarm Clock
SVC 0 handler
SVC 1 handler
SchedulerIO Handler IO Handler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler
Contexts
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 6
THE BIG IDEA Several programs each with their own context may besimultaneously loaded into main memory
We might like to supportmultiple VIRTUAL toPHYSICAL Mappings andthus multiple Contexts
A context is an entire set of mappings from VIRTUAL to PHYSICAL pagenumbers as specified by the contents of the page map
ldquo Context switchrdquoreload the page map
D R PPN
Virtual Memory Physical Memory
PAGEMAP
VirtualMemory
1
VirtualMemory
2
PhysicalMemory
map map
Power of Contexts Sharing a CPU
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 7
1 TIMESHARING among several programs --bull Separate context for each programbull OS loads appropriate context into pagemap when switching
among pgms
2 Separate context for OS ldquoKernelrdquo (eg interrupt handlers)bull ldquoKernelrdquo vs ldquoUserrdquo contextsbull Switch to Kernel context on interruptbull Switch back on interrupt returnTYPICAL HARDWARE SUPPORT 2 HW pagemaps
Every application can bewritten as if it has accessto all of memory withoutconsidering where otherapplications reside
More than Virtual MemoryA VIRTUAL MACHINE
D R PPN
Virtual Memory Physical Memory
PAGEMAP
Building a Virtual Machine
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 8
Goal give each program its own ldquoVIRTUAL MACHINErdquo programs donrsquot ldquoknowrdquoabout each otherhellip
Abstraction create a process which has its own bull machine state R0 hellip R30 bull program (w shared code) bull context (virtual address space) bull virtual IO devices (consolehellip) bull stack
PROCESS 0
VirtualMemor
y
PhysicalMemory
Context 0
PROCESS 1
Context 1
VirtualMemor
y
Building a Virtual Machine
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 9
1 Running in process 02 Stop execution of process 0 either because of explicit yield or some sort of timer interrupt trap to handler code saving current PC in XP3 First save process 0 state (regs context) Then load process 1 state (regs context)4 ldquoReturnrdquo to process 1 just like return from other trap handlers (ie use address in XP) but wersquore returning from a different trap than happened in step 25 Running in process 1
When this process is interruptedWe RETURN to this process
Multiplexing the CPU
Key Technology Interrupts
Vir
tual ti
me
Interrupt HandlingA primitive constrained form of multiprocessing
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 10
BASIC SEQUENCE bull Program A is running when some EVENT happens bull PROCESSOR STATE saved on stack (like CALL) bull The HANDLER program to be run is selected bull HANDLER state (PC etc) installed as new processor state bull HANDLER runs to completion bull State of interrupted program A popped from stack and re-installed JMP returns control to A bull A continues unaware of interruption
ltSPgt
CHARACTERISTICS bull TRANSPARENT to interrupted program bull Handler runs to completion before returning bull Obeys stack discipline handler can borrow stack from interrupted program (and return it unchanged) or use a special handler stack
oldltSPgtSAVEDSTATEOF A
Beta Interrupt Handling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 11
Minimal Implementation bull Check for Interrupt Requests (IRQs) before each instruction fetch bull On IRQ j 1048707 bullcopy PC into Reg[XP] 1048707 bullINSTALL j4 as new PCHandler Coding bull Save state in ldquoUserrdquo structure bull Call C procedure to handle the exception bull re-install saved state from ldquoUserrdquo bull Return to Reg[XP]WHERE to find handlers bull BETA Scheme WIRE IN a low-memory address for each exception handler entry point bull Common alternative WIRE IN the address of a TABLE of handler addresses (ldquointerrupt vectorsrdquo)
User
RESETrarr 0x8000000
SAVEDSTATEOF A
ILLOPrarr 0x8000000
X_ADRrarr 0x8000000
External (Asynchronous)Interrupts
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 12
Example System maintains current time of day (TOD) count at a well-known memory location that can be accessed by programs Butthis value must be updated periodically in response to clock EVENTs ie signal triggered by 60 Hz clock hardware
Program A (Application) bull Executes instructions of the user program bull Doesnt want to know about clock hardware interrupts etc bull Can incorporate TOD into results by examining well-known memory location
Clock Handler bull GUTS Sequence of instructions that increments TOD Written in C bull EntryExit sequences save amp restore interrupted state call the C handler Written as assembler ldquostubsrdquo
Interrupt Handler Coding
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 13
Handler(written in C)
ldquoInterrupt stubrdquo(written in assy)
Simple Timesharing Scheduler
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 14
(PCB = Process Control Block)
Avoiding Re-entrance
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 15
Processor State K-Mode FlagPC31 = 1 for Kernel Mode
Handlers which are interruptable are called RE-ENTRANT and pose special problems Beta like many systems disallows reentrant interrupts Mechanism Uninterruptable ldquoKernel Moderdquo for OS
USER mode(Application)
KERNEL mode(Op Sys)
main() PC=0
PC=1User(savedstate)
ClockHandler
SVCHandler
sInterruptVector
PageFault
Handler
KernelStack
Other K-mode functions eg bull choosing KernalUser context bull Allowing ldquopriviledgedrdquo operations
Polled IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 16
Application code deals directly with IO (eg by busy-waiting)
loop LD(flagr0) BEQ(R0loop) hellip | process keystroke
PROBLEMS bull Uses up (physical) CPU while busy-waiting bull (FIX Multiprocessing codestripping etc) bull Poor system modularity running pgm MUST know about ALL devices bull Uses up CPU cycles even when device is idle
flag
dataCPU
INTERFACE DEVICE
KEY HITFlaglarr1DatalarrASCII
Interrupt-Driven IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 17
OPERATION NO attention to Keyboard during normal operation bull on key strike hardware asserts IRQ to request interrupt bull USER program interrupted PC+4 of interrupted inst saved in XP bull state of USER program saved on KERNEL stack bull KeyboardHandler invoked runs to completion bull state of USER program restored program resumes
TRANSPARENT to USER program
Keyboard Interrupt Handler (in OS KERNEL)
struct Device char Flag Data Keyboard
KeyboardHandler(struct Mstate s) Buffer[inptr] = KeyboardData inptr = (inptr + 1) 100
Assume eachkeyboard hasan associatedbuffer
ReadKey SVC Attempt 1
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 18
A supervisor call (SVC) is an instruction that transfers control to the kernel soit can satisfy some user request Kernel returns to user program whenrequest is complete
First draft of a ReadKey SVC handler returns next keystroke to user
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum while (BufferEmpty(kbdnum)) busy wait loop UserRegs[0] = ReadInputBuffer(kbdnum)
Problem Canrsquot interrupt code running in the supervisor modehellipso the buffer never gets filled
ReadKey SVC Attempt 2
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 19
A keyboard SVC handler (slightly modified eg to support a Virtual Keyboard)
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 else UserRegs[0] = ReadInputBuffer(kbdnum)
Problem The process just wastes its time-slice waiting for someone to hit a key
Thatrsquos afunny way
to writea loop
ReadKey SVC Attempt 3
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 20
BETTER On IO wait YIELD remainder of quantum
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 Scheduler( ) else UserRegs[0] = ReadInputBuffer(kbdnum)
RESULT Better CPU utilization
Does timesharing causes CPU use to be less efficient
bull COST Scheduling context-switching overhead but
bull GAIN Productive use of idle time of one process by running another
Sophisticated Scheduling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 21
To improve efficiency further we can avoid scheduling processes in
prolonged IO wait
bull Processes can be in ACTIVE or WAITING (ldquosleepingrdquo) states
bull Scheduler cycles among ACTIVE PROCESSES only
bull Active process moves to WAITING status when it tries to read
a character and buffer is empty
bull Waiting processes each contain a code (eg in PCB) designating
what they are waiting for (eg keyboard N)
bull Device interrupts (eg on keyboard N) move any processes
waiting on that device to ACTIVE state
UNIX kernel utilities
bull sleep(reason) - Puts CurProc to sleep ldquoReasonrdquo is an arbitrary
binary value giving a condition for reactivation
bull wakeup(reason) -Makes active any process in sleep(reason)
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 22
SVC call from application
INTERRUPT from Keyboard n
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 23
ldquoApplicationsrdquo are quasi-parallel
ldquoPROCESSESrdquo
on
ldquoVIRTUAL MACHINESrdquo
each with
bull- CONTEXT
bull (virtual address space)
bull- Virtual IO devices
OS KERNEL has
bull- Interrupt handlers
bull- SVC (trap) handlers
bull- Scheduler
bull- PCB structures containing the
state of inactive processesDevice
0Device
1Alarm Clock
SVC 0 handler
SVC 1 handler
SchedulerIO Handler IO Handler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler
Power of Contexts Sharing a CPU
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 7
1 TIMESHARING among several programs --bull Separate context for each programbull OS loads appropriate context into pagemap when switching
among pgms
2 Separate context for OS ldquoKernelrdquo (eg interrupt handlers)bull ldquoKernelrdquo vs ldquoUserrdquo contextsbull Switch to Kernel context on interruptbull Switch back on interrupt returnTYPICAL HARDWARE SUPPORT 2 HW pagemaps
Every application can bewritten as if it has accessto all of memory withoutconsidering where otherapplications reside
More than Virtual MemoryA VIRTUAL MACHINE
D R PPN
Virtual Memory Physical Memory
PAGEMAP
Building a Virtual Machine
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 8
Goal give each program its own ldquoVIRTUAL MACHINErdquo programs donrsquot ldquoknowrdquoabout each otherhellip
Abstraction create a process which has its own bull machine state R0 hellip R30 bull program (w shared code) bull context (virtual address space) bull virtual IO devices (consolehellip) bull stack
PROCESS 0
VirtualMemor
y
PhysicalMemory
Context 0
PROCESS 1
Context 1
VirtualMemor
y
Building a Virtual Machine
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 9
1 Running in process 02 Stop execution of process 0 either because of explicit yield or some sort of timer interrupt trap to handler code saving current PC in XP3 First save process 0 state (regs context) Then load process 1 state (regs context)4 ldquoReturnrdquo to process 1 just like return from other trap handlers (ie use address in XP) but wersquore returning from a different trap than happened in step 25 Running in process 1
When this process is interruptedWe RETURN to this process
Multiplexing the CPU
Key Technology Interrupts
Vir
tual ti
me
Interrupt HandlingA primitive constrained form of multiprocessing
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 10
BASIC SEQUENCE bull Program A is running when some EVENT happens bull PROCESSOR STATE saved on stack (like CALL) bull The HANDLER program to be run is selected bull HANDLER state (PC etc) installed as new processor state bull HANDLER runs to completion bull State of interrupted program A popped from stack and re-installed JMP returns control to A bull A continues unaware of interruption
ltSPgt
CHARACTERISTICS bull TRANSPARENT to interrupted program bull Handler runs to completion before returning bull Obeys stack discipline handler can borrow stack from interrupted program (and return it unchanged) or use a special handler stack
oldltSPgtSAVEDSTATEOF A
Beta Interrupt Handling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 11
Minimal Implementation bull Check for Interrupt Requests (IRQs) before each instruction fetch bull On IRQ j 1048707 bullcopy PC into Reg[XP] 1048707 bullINSTALL j4 as new PCHandler Coding bull Save state in ldquoUserrdquo structure bull Call C procedure to handle the exception bull re-install saved state from ldquoUserrdquo bull Return to Reg[XP]WHERE to find handlers bull BETA Scheme WIRE IN a low-memory address for each exception handler entry point bull Common alternative WIRE IN the address of a TABLE of handler addresses (ldquointerrupt vectorsrdquo)
User
RESETrarr 0x8000000
SAVEDSTATEOF A
ILLOPrarr 0x8000000
X_ADRrarr 0x8000000
External (Asynchronous)Interrupts
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 12
Example System maintains current time of day (TOD) count at a well-known memory location that can be accessed by programs Butthis value must be updated periodically in response to clock EVENTs ie signal triggered by 60 Hz clock hardware
Program A (Application) bull Executes instructions of the user program bull Doesnt want to know about clock hardware interrupts etc bull Can incorporate TOD into results by examining well-known memory location
Clock Handler bull GUTS Sequence of instructions that increments TOD Written in C bull EntryExit sequences save amp restore interrupted state call the C handler Written as assembler ldquostubsrdquo
Interrupt Handler Coding
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 13
Handler(written in C)
ldquoInterrupt stubrdquo(written in assy)
Simple Timesharing Scheduler
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 14
(PCB = Process Control Block)
Avoiding Re-entrance
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 15
Processor State K-Mode FlagPC31 = 1 for Kernel Mode
Handlers which are interruptable are called RE-ENTRANT and pose special problems Beta like many systems disallows reentrant interrupts Mechanism Uninterruptable ldquoKernel Moderdquo for OS
USER mode(Application)
KERNEL mode(Op Sys)
main() PC=0
PC=1User(savedstate)
ClockHandler
SVCHandler
sInterruptVector
PageFault
Handler
KernelStack
Other K-mode functions eg bull choosing KernalUser context bull Allowing ldquopriviledgedrdquo operations
Polled IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 16
Application code deals directly with IO (eg by busy-waiting)
loop LD(flagr0) BEQ(R0loop) hellip | process keystroke
PROBLEMS bull Uses up (physical) CPU while busy-waiting bull (FIX Multiprocessing codestripping etc) bull Poor system modularity running pgm MUST know about ALL devices bull Uses up CPU cycles even when device is idle
flag
dataCPU
INTERFACE DEVICE
KEY HITFlaglarr1DatalarrASCII
Interrupt-Driven IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 17
OPERATION NO attention to Keyboard during normal operation bull on key strike hardware asserts IRQ to request interrupt bull USER program interrupted PC+4 of interrupted inst saved in XP bull state of USER program saved on KERNEL stack bull KeyboardHandler invoked runs to completion bull state of USER program restored program resumes
TRANSPARENT to USER program
Keyboard Interrupt Handler (in OS KERNEL)
struct Device char Flag Data Keyboard
KeyboardHandler(struct Mstate s) Buffer[inptr] = KeyboardData inptr = (inptr + 1) 100
Assume eachkeyboard hasan associatedbuffer
ReadKey SVC Attempt 1
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 18
A supervisor call (SVC) is an instruction that transfers control to the kernel soit can satisfy some user request Kernel returns to user program whenrequest is complete
First draft of a ReadKey SVC handler returns next keystroke to user
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum while (BufferEmpty(kbdnum)) busy wait loop UserRegs[0] = ReadInputBuffer(kbdnum)
Problem Canrsquot interrupt code running in the supervisor modehellipso the buffer never gets filled
ReadKey SVC Attempt 2
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 19
A keyboard SVC handler (slightly modified eg to support a Virtual Keyboard)
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 else UserRegs[0] = ReadInputBuffer(kbdnum)
Problem The process just wastes its time-slice waiting for someone to hit a key
Thatrsquos afunny way
to writea loop
ReadKey SVC Attempt 3
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 20
BETTER On IO wait YIELD remainder of quantum
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 Scheduler( ) else UserRegs[0] = ReadInputBuffer(kbdnum)
RESULT Better CPU utilization
Does timesharing causes CPU use to be less efficient
bull COST Scheduling context-switching overhead but
bull GAIN Productive use of idle time of one process by running another
Sophisticated Scheduling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 21
To improve efficiency further we can avoid scheduling processes in
prolonged IO wait
bull Processes can be in ACTIVE or WAITING (ldquosleepingrdquo) states
bull Scheduler cycles among ACTIVE PROCESSES only
bull Active process moves to WAITING status when it tries to read
a character and buffer is empty
bull Waiting processes each contain a code (eg in PCB) designating
what they are waiting for (eg keyboard N)
bull Device interrupts (eg on keyboard N) move any processes
waiting on that device to ACTIVE state
UNIX kernel utilities
bull sleep(reason) - Puts CurProc to sleep ldquoReasonrdquo is an arbitrary
binary value giving a condition for reactivation
bull wakeup(reason) -Makes active any process in sleep(reason)
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 22
SVC call from application
INTERRUPT from Keyboard n
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 23
ldquoApplicationsrdquo are quasi-parallel
ldquoPROCESSESrdquo
on
ldquoVIRTUAL MACHINESrdquo
each with
bull- CONTEXT
bull (virtual address space)
bull- Virtual IO devices
OS KERNEL has
bull- Interrupt handlers
bull- SVC (trap) handlers
bull- Scheduler
bull- PCB structures containing the
state of inactive processesDevice
0Device
1Alarm Clock
SVC 0 handler
SVC 1 handler
SchedulerIO Handler IO Handler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler
Building a Virtual Machine
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 8
Goal give each program its own ldquoVIRTUAL MACHINErdquo programs donrsquot ldquoknowrdquoabout each otherhellip
Abstraction create a process which has its own bull machine state R0 hellip R30 bull program (w shared code) bull context (virtual address space) bull virtual IO devices (consolehellip) bull stack
PROCESS 0
VirtualMemor
y
PhysicalMemory
Context 0
PROCESS 1
Context 1
VirtualMemor
y
Building a Virtual Machine
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 9
1 Running in process 02 Stop execution of process 0 either because of explicit yield or some sort of timer interrupt trap to handler code saving current PC in XP3 First save process 0 state (regs context) Then load process 1 state (regs context)4 ldquoReturnrdquo to process 1 just like return from other trap handlers (ie use address in XP) but wersquore returning from a different trap than happened in step 25 Running in process 1
When this process is interruptedWe RETURN to this process
Multiplexing the CPU
Key Technology Interrupts
Vir
tual ti
me
Interrupt HandlingA primitive constrained form of multiprocessing
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 10
BASIC SEQUENCE bull Program A is running when some EVENT happens bull PROCESSOR STATE saved on stack (like CALL) bull The HANDLER program to be run is selected bull HANDLER state (PC etc) installed as new processor state bull HANDLER runs to completion bull State of interrupted program A popped from stack and re-installed JMP returns control to A bull A continues unaware of interruption
ltSPgt
CHARACTERISTICS bull TRANSPARENT to interrupted program bull Handler runs to completion before returning bull Obeys stack discipline handler can borrow stack from interrupted program (and return it unchanged) or use a special handler stack
oldltSPgtSAVEDSTATEOF A
Beta Interrupt Handling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 11
Minimal Implementation bull Check for Interrupt Requests (IRQs) before each instruction fetch bull On IRQ j 1048707 bullcopy PC into Reg[XP] 1048707 bullINSTALL j4 as new PCHandler Coding bull Save state in ldquoUserrdquo structure bull Call C procedure to handle the exception bull re-install saved state from ldquoUserrdquo bull Return to Reg[XP]WHERE to find handlers bull BETA Scheme WIRE IN a low-memory address for each exception handler entry point bull Common alternative WIRE IN the address of a TABLE of handler addresses (ldquointerrupt vectorsrdquo)
User
RESETrarr 0x8000000
SAVEDSTATEOF A
ILLOPrarr 0x8000000
X_ADRrarr 0x8000000
External (Asynchronous)Interrupts
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 12
Example System maintains current time of day (TOD) count at a well-known memory location that can be accessed by programs Butthis value must be updated periodically in response to clock EVENTs ie signal triggered by 60 Hz clock hardware
Program A (Application) bull Executes instructions of the user program bull Doesnt want to know about clock hardware interrupts etc bull Can incorporate TOD into results by examining well-known memory location
Clock Handler bull GUTS Sequence of instructions that increments TOD Written in C bull EntryExit sequences save amp restore interrupted state call the C handler Written as assembler ldquostubsrdquo
Interrupt Handler Coding
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 13
Handler(written in C)
ldquoInterrupt stubrdquo(written in assy)
Simple Timesharing Scheduler
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 14
(PCB = Process Control Block)
Avoiding Re-entrance
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 15
Processor State K-Mode FlagPC31 = 1 for Kernel Mode
Handlers which are interruptable are called RE-ENTRANT and pose special problems Beta like many systems disallows reentrant interrupts Mechanism Uninterruptable ldquoKernel Moderdquo for OS
USER mode(Application)
KERNEL mode(Op Sys)
main() PC=0
PC=1User(savedstate)
ClockHandler
SVCHandler
sInterruptVector
PageFault
Handler
KernelStack
Other K-mode functions eg bull choosing KernalUser context bull Allowing ldquopriviledgedrdquo operations
Polled IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 16
Application code deals directly with IO (eg by busy-waiting)
loop LD(flagr0) BEQ(R0loop) hellip | process keystroke
PROBLEMS bull Uses up (physical) CPU while busy-waiting bull (FIX Multiprocessing codestripping etc) bull Poor system modularity running pgm MUST know about ALL devices bull Uses up CPU cycles even when device is idle
flag
dataCPU
INTERFACE DEVICE
KEY HITFlaglarr1DatalarrASCII
Interrupt-Driven IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 17
OPERATION NO attention to Keyboard during normal operation bull on key strike hardware asserts IRQ to request interrupt bull USER program interrupted PC+4 of interrupted inst saved in XP bull state of USER program saved on KERNEL stack bull KeyboardHandler invoked runs to completion bull state of USER program restored program resumes
TRANSPARENT to USER program
Keyboard Interrupt Handler (in OS KERNEL)
struct Device char Flag Data Keyboard
KeyboardHandler(struct Mstate s) Buffer[inptr] = KeyboardData inptr = (inptr + 1) 100
Assume eachkeyboard hasan associatedbuffer
ReadKey SVC Attempt 1
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 18
A supervisor call (SVC) is an instruction that transfers control to the kernel soit can satisfy some user request Kernel returns to user program whenrequest is complete
First draft of a ReadKey SVC handler returns next keystroke to user
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum while (BufferEmpty(kbdnum)) busy wait loop UserRegs[0] = ReadInputBuffer(kbdnum)
Problem Canrsquot interrupt code running in the supervisor modehellipso the buffer never gets filled
ReadKey SVC Attempt 2
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 19
A keyboard SVC handler (slightly modified eg to support a Virtual Keyboard)
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 else UserRegs[0] = ReadInputBuffer(kbdnum)
Problem The process just wastes its time-slice waiting for someone to hit a key
Thatrsquos afunny way
to writea loop
ReadKey SVC Attempt 3
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 20
BETTER On IO wait YIELD remainder of quantum
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 Scheduler( ) else UserRegs[0] = ReadInputBuffer(kbdnum)
RESULT Better CPU utilization
Does timesharing causes CPU use to be less efficient
bull COST Scheduling context-switching overhead but
bull GAIN Productive use of idle time of one process by running another
Sophisticated Scheduling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 21
To improve efficiency further we can avoid scheduling processes in
prolonged IO wait
bull Processes can be in ACTIVE or WAITING (ldquosleepingrdquo) states
bull Scheduler cycles among ACTIVE PROCESSES only
bull Active process moves to WAITING status when it tries to read
a character and buffer is empty
bull Waiting processes each contain a code (eg in PCB) designating
what they are waiting for (eg keyboard N)
bull Device interrupts (eg on keyboard N) move any processes
waiting on that device to ACTIVE state
UNIX kernel utilities
bull sleep(reason) - Puts CurProc to sleep ldquoReasonrdquo is an arbitrary
binary value giving a condition for reactivation
bull wakeup(reason) -Makes active any process in sleep(reason)
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 22
SVC call from application
INTERRUPT from Keyboard n
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 23
ldquoApplicationsrdquo are quasi-parallel
ldquoPROCESSESrdquo
on
ldquoVIRTUAL MACHINESrdquo
each with
bull- CONTEXT
bull (virtual address space)
bull- Virtual IO devices
OS KERNEL has
bull- Interrupt handlers
bull- SVC (trap) handlers
bull- Scheduler
bull- PCB structures containing the
state of inactive processesDevice
0Device
1Alarm Clock
SVC 0 handler
SVC 1 handler
SchedulerIO Handler IO Handler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler
Building a Virtual Machine
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 9
1 Running in process 02 Stop execution of process 0 either because of explicit yield or some sort of timer interrupt trap to handler code saving current PC in XP3 First save process 0 state (regs context) Then load process 1 state (regs context)4 ldquoReturnrdquo to process 1 just like return from other trap handlers (ie use address in XP) but wersquore returning from a different trap than happened in step 25 Running in process 1
When this process is interruptedWe RETURN to this process
Multiplexing the CPU
Key Technology Interrupts
Vir
tual ti
me
Interrupt HandlingA primitive constrained form of multiprocessing
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 10
BASIC SEQUENCE bull Program A is running when some EVENT happens bull PROCESSOR STATE saved on stack (like CALL) bull The HANDLER program to be run is selected bull HANDLER state (PC etc) installed as new processor state bull HANDLER runs to completion bull State of interrupted program A popped from stack and re-installed JMP returns control to A bull A continues unaware of interruption
ltSPgt
CHARACTERISTICS bull TRANSPARENT to interrupted program bull Handler runs to completion before returning bull Obeys stack discipline handler can borrow stack from interrupted program (and return it unchanged) or use a special handler stack
oldltSPgtSAVEDSTATEOF A
Beta Interrupt Handling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 11
Minimal Implementation bull Check for Interrupt Requests (IRQs) before each instruction fetch bull On IRQ j 1048707 bullcopy PC into Reg[XP] 1048707 bullINSTALL j4 as new PCHandler Coding bull Save state in ldquoUserrdquo structure bull Call C procedure to handle the exception bull re-install saved state from ldquoUserrdquo bull Return to Reg[XP]WHERE to find handlers bull BETA Scheme WIRE IN a low-memory address for each exception handler entry point bull Common alternative WIRE IN the address of a TABLE of handler addresses (ldquointerrupt vectorsrdquo)
User
RESETrarr 0x8000000
SAVEDSTATEOF A
ILLOPrarr 0x8000000
X_ADRrarr 0x8000000
External (Asynchronous)Interrupts
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 12
Example System maintains current time of day (TOD) count at a well-known memory location that can be accessed by programs Butthis value must be updated periodically in response to clock EVENTs ie signal triggered by 60 Hz clock hardware
Program A (Application) bull Executes instructions of the user program bull Doesnt want to know about clock hardware interrupts etc bull Can incorporate TOD into results by examining well-known memory location
Clock Handler bull GUTS Sequence of instructions that increments TOD Written in C bull EntryExit sequences save amp restore interrupted state call the C handler Written as assembler ldquostubsrdquo
Interrupt Handler Coding
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 13
Handler(written in C)
ldquoInterrupt stubrdquo(written in assy)
Simple Timesharing Scheduler
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 14
(PCB = Process Control Block)
Avoiding Re-entrance
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 15
Processor State K-Mode FlagPC31 = 1 for Kernel Mode
Handlers which are interruptable are called RE-ENTRANT and pose special problems Beta like many systems disallows reentrant interrupts Mechanism Uninterruptable ldquoKernel Moderdquo for OS
USER mode(Application)
KERNEL mode(Op Sys)
main() PC=0
PC=1User(savedstate)
ClockHandler
SVCHandler
sInterruptVector
PageFault
Handler
KernelStack
Other K-mode functions eg bull choosing KernalUser context bull Allowing ldquopriviledgedrdquo operations
Polled IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 16
Application code deals directly with IO (eg by busy-waiting)
loop LD(flagr0) BEQ(R0loop) hellip | process keystroke
PROBLEMS bull Uses up (physical) CPU while busy-waiting bull (FIX Multiprocessing codestripping etc) bull Poor system modularity running pgm MUST know about ALL devices bull Uses up CPU cycles even when device is idle
flag
dataCPU
INTERFACE DEVICE
KEY HITFlaglarr1DatalarrASCII
Interrupt-Driven IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 17
OPERATION NO attention to Keyboard during normal operation bull on key strike hardware asserts IRQ to request interrupt bull USER program interrupted PC+4 of interrupted inst saved in XP bull state of USER program saved on KERNEL stack bull KeyboardHandler invoked runs to completion bull state of USER program restored program resumes
TRANSPARENT to USER program
Keyboard Interrupt Handler (in OS KERNEL)
struct Device char Flag Data Keyboard
KeyboardHandler(struct Mstate s) Buffer[inptr] = KeyboardData inptr = (inptr + 1) 100
Assume eachkeyboard hasan associatedbuffer
ReadKey SVC Attempt 1
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 18
A supervisor call (SVC) is an instruction that transfers control to the kernel soit can satisfy some user request Kernel returns to user program whenrequest is complete
First draft of a ReadKey SVC handler returns next keystroke to user
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum while (BufferEmpty(kbdnum)) busy wait loop UserRegs[0] = ReadInputBuffer(kbdnum)
Problem Canrsquot interrupt code running in the supervisor modehellipso the buffer never gets filled
ReadKey SVC Attempt 2
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 19
A keyboard SVC handler (slightly modified eg to support a Virtual Keyboard)
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 else UserRegs[0] = ReadInputBuffer(kbdnum)
Problem The process just wastes its time-slice waiting for someone to hit a key
Thatrsquos afunny way
to writea loop
ReadKey SVC Attempt 3
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 20
BETTER On IO wait YIELD remainder of quantum
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 Scheduler( ) else UserRegs[0] = ReadInputBuffer(kbdnum)
RESULT Better CPU utilization
Does timesharing causes CPU use to be less efficient
bull COST Scheduling context-switching overhead but
bull GAIN Productive use of idle time of one process by running another
Sophisticated Scheduling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 21
To improve efficiency further we can avoid scheduling processes in
prolonged IO wait
bull Processes can be in ACTIVE or WAITING (ldquosleepingrdquo) states
bull Scheduler cycles among ACTIVE PROCESSES only
bull Active process moves to WAITING status when it tries to read
a character and buffer is empty
bull Waiting processes each contain a code (eg in PCB) designating
what they are waiting for (eg keyboard N)
bull Device interrupts (eg on keyboard N) move any processes
waiting on that device to ACTIVE state
UNIX kernel utilities
bull sleep(reason) - Puts CurProc to sleep ldquoReasonrdquo is an arbitrary
binary value giving a condition for reactivation
bull wakeup(reason) -Makes active any process in sleep(reason)
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 22
SVC call from application
INTERRUPT from Keyboard n
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 23
ldquoApplicationsrdquo are quasi-parallel
ldquoPROCESSESrdquo
on
ldquoVIRTUAL MACHINESrdquo
each with
bull- CONTEXT
bull (virtual address space)
bull- Virtual IO devices
OS KERNEL has
bull- Interrupt handlers
bull- SVC (trap) handlers
bull- Scheduler
bull- PCB structures containing the
state of inactive processesDevice
0Device
1Alarm Clock
SVC 0 handler
SVC 1 handler
SchedulerIO Handler IO Handler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler
Interrupt HandlingA primitive constrained form of multiprocessing
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 10
BASIC SEQUENCE bull Program A is running when some EVENT happens bull PROCESSOR STATE saved on stack (like CALL) bull The HANDLER program to be run is selected bull HANDLER state (PC etc) installed as new processor state bull HANDLER runs to completion bull State of interrupted program A popped from stack and re-installed JMP returns control to A bull A continues unaware of interruption
ltSPgt
CHARACTERISTICS bull TRANSPARENT to interrupted program bull Handler runs to completion before returning bull Obeys stack discipline handler can borrow stack from interrupted program (and return it unchanged) or use a special handler stack
oldltSPgtSAVEDSTATEOF A
Beta Interrupt Handling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 11
Minimal Implementation bull Check for Interrupt Requests (IRQs) before each instruction fetch bull On IRQ j 1048707 bullcopy PC into Reg[XP] 1048707 bullINSTALL j4 as new PCHandler Coding bull Save state in ldquoUserrdquo structure bull Call C procedure to handle the exception bull re-install saved state from ldquoUserrdquo bull Return to Reg[XP]WHERE to find handlers bull BETA Scheme WIRE IN a low-memory address for each exception handler entry point bull Common alternative WIRE IN the address of a TABLE of handler addresses (ldquointerrupt vectorsrdquo)
User
RESETrarr 0x8000000
SAVEDSTATEOF A
ILLOPrarr 0x8000000
X_ADRrarr 0x8000000
External (Asynchronous)Interrupts
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 12
Example System maintains current time of day (TOD) count at a well-known memory location that can be accessed by programs Butthis value must be updated periodically in response to clock EVENTs ie signal triggered by 60 Hz clock hardware
Program A (Application) bull Executes instructions of the user program bull Doesnt want to know about clock hardware interrupts etc bull Can incorporate TOD into results by examining well-known memory location
Clock Handler bull GUTS Sequence of instructions that increments TOD Written in C bull EntryExit sequences save amp restore interrupted state call the C handler Written as assembler ldquostubsrdquo
Interrupt Handler Coding
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 13
Handler(written in C)
ldquoInterrupt stubrdquo(written in assy)
Simple Timesharing Scheduler
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 14
(PCB = Process Control Block)
Avoiding Re-entrance
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 15
Processor State K-Mode FlagPC31 = 1 for Kernel Mode
Handlers which are interruptable are called RE-ENTRANT and pose special problems Beta like many systems disallows reentrant interrupts Mechanism Uninterruptable ldquoKernel Moderdquo for OS
USER mode(Application)
KERNEL mode(Op Sys)
main() PC=0
PC=1User(savedstate)
ClockHandler
SVCHandler
sInterruptVector
PageFault
Handler
KernelStack
Other K-mode functions eg bull choosing KernalUser context bull Allowing ldquopriviledgedrdquo operations
Polled IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 16
Application code deals directly with IO (eg by busy-waiting)
loop LD(flagr0) BEQ(R0loop) hellip | process keystroke
PROBLEMS bull Uses up (physical) CPU while busy-waiting bull (FIX Multiprocessing codestripping etc) bull Poor system modularity running pgm MUST know about ALL devices bull Uses up CPU cycles even when device is idle
flag
dataCPU
INTERFACE DEVICE
KEY HITFlaglarr1DatalarrASCII
Interrupt-Driven IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 17
OPERATION NO attention to Keyboard during normal operation bull on key strike hardware asserts IRQ to request interrupt bull USER program interrupted PC+4 of interrupted inst saved in XP bull state of USER program saved on KERNEL stack bull KeyboardHandler invoked runs to completion bull state of USER program restored program resumes
TRANSPARENT to USER program
Keyboard Interrupt Handler (in OS KERNEL)
struct Device char Flag Data Keyboard
KeyboardHandler(struct Mstate s) Buffer[inptr] = KeyboardData inptr = (inptr + 1) 100
Assume eachkeyboard hasan associatedbuffer
ReadKey SVC Attempt 1
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 18
A supervisor call (SVC) is an instruction that transfers control to the kernel soit can satisfy some user request Kernel returns to user program whenrequest is complete
First draft of a ReadKey SVC handler returns next keystroke to user
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum while (BufferEmpty(kbdnum)) busy wait loop UserRegs[0] = ReadInputBuffer(kbdnum)
Problem Canrsquot interrupt code running in the supervisor modehellipso the buffer never gets filled
ReadKey SVC Attempt 2
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 19
A keyboard SVC handler (slightly modified eg to support a Virtual Keyboard)
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 else UserRegs[0] = ReadInputBuffer(kbdnum)
Problem The process just wastes its time-slice waiting for someone to hit a key
Thatrsquos afunny way
to writea loop
ReadKey SVC Attempt 3
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 20
BETTER On IO wait YIELD remainder of quantum
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 Scheduler( ) else UserRegs[0] = ReadInputBuffer(kbdnum)
RESULT Better CPU utilization
Does timesharing causes CPU use to be less efficient
bull COST Scheduling context-switching overhead but
bull GAIN Productive use of idle time of one process by running another
Sophisticated Scheduling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 21
To improve efficiency further we can avoid scheduling processes in
prolonged IO wait
bull Processes can be in ACTIVE or WAITING (ldquosleepingrdquo) states
bull Scheduler cycles among ACTIVE PROCESSES only
bull Active process moves to WAITING status when it tries to read
a character and buffer is empty
bull Waiting processes each contain a code (eg in PCB) designating
what they are waiting for (eg keyboard N)
bull Device interrupts (eg on keyboard N) move any processes
waiting on that device to ACTIVE state
UNIX kernel utilities
bull sleep(reason) - Puts CurProc to sleep ldquoReasonrdquo is an arbitrary
binary value giving a condition for reactivation
bull wakeup(reason) -Makes active any process in sleep(reason)
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 22
SVC call from application
INTERRUPT from Keyboard n
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 23
ldquoApplicationsrdquo are quasi-parallel
ldquoPROCESSESrdquo
on
ldquoVIRTUAL MACHINESrdquo
each with
bull- CONTEXT
bull (virtual address space)
bull- Virtual IO devices
OS KERNEL has
bull- Interrupt handlers
bull- SVC (trap) handlers
bull- Scheduler
bull- PCB structures containing the
state of inactive processesDevice
0Device
1Alarm Clock
SVC 0 handler
SVC 1 handler
SchedulerIO Handler IO Handler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler
Beta Interrupt Handling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 11
Minimal Implementation bull Check for Interrupt Requests (IRQs) before each instruction fetch bull On IRQ j 1048707 bullcopy PC into Reg[XP] 1048707 bullINSTALL j4 as new PCHandler Coding bull Save state in ldquoUserrdquo structure bull Call C procedure to handle the exception bull re-install saved state from ldquoUserrdquo bull Return to Reg[XP]WHERE to find handlers bull BETA Scheme WIRE IN a low-memory address for each exception handler entry point bull Common alternative WIRE IN the address of a TABLE of handler addresses (ldquointerrupt vectorsrdquo)
User
RESETrarr 0x8000000
SAVEDSTATEOF A
ILLOPrarr 0x8000000
X_ADRrarr 0x8000000
External (Asynchronous)Interrupts
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 12
Example System maintains current time of day (TOD) count at a well-known memory location that can be accessed by programs Butthis value must be updated periodically in response to clock EVENTs ie signal triggered by 60 Hz clock hardware
Program A (Application) bull Executes instructions of the user program bull Doesnt want to know about clock hardware interrupts etc bull Can incorporate TOD into results by examining well-known memory location
Clock Handler bull GUTS Sequence of instructions that increments TOD Written in C bull EntryExit sequences save amp restore interrupted state call the C handler Written as assembler ldquostubsrdquo
Interrupt Handler Coding
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 13
Handler(written in C)
ldquoInterrupt stubrdquo(written in assy)
Simple Timesharing Scheduler
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 14
(PCB = Process Control Block)
Avoiding Re-entrance
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 15
Processor State K-Mode FlagPC31 = 1 for Kernel Mode
Handlers which are interruptable are called RE-ENTRANT and pose special problems Beta like many systems disallows reentrant interrupts Mechanism Uninterruptable ldquoKernel Moderdquo for OS
USER mode(Application)
KERNEL mode(Op Sys)
main() PC=0
PC=1User(savedstate)
ClockHandler
SVCHandler
sInterruptVector
PageFault
Handler
KernelStack
Other K-mode functions eg bull choosing KernalUser context bull Allowing ldquopriviledgedrdquo operations
Polled IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 16
Application code deals directly with IO (eg by busy-waiting)
loop LD(flagr0) BEQ(R0loop) hellip | process keystroke
PROBLEMS bull Uses up (physical) CPU while busy-waiting bull (FIX Multiprocessing codestripping etc) bull Poor system modularity running pgm MUST know about ALL devices bull Uses up CPU cycles even when device is idle
flag
dataCPU
INTERFACE DEVICE
KEY HITFlaglarr1DatalarrASCII
Interrupt-Driven IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 17
OPERATION NO attention to Keyboard during normal operation bull on key strike hardware asserts IRQ to request interrupt bull USER program interrupted PC+4 of interrupted inst saved in XP bull state of USER program saved on KERNEL stack bull KeyboardHandler invoked runs to completion bull state of USER program restored program resumes
TRANSPARENT to USER program
Keyboard Interrupt Handler (in OS KERNEL)
struct Device char Flag Data Keyboard
KeyboardHandler(struct Mstate s) Buffer[inptr] = KeyboardData inptr = (inptr + 1) 100
Assume eachkeyboard hasan associatedbuffer
ReadKey SVC Attempt 1
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 18
A supervisor call (SVC) is an instruction that transfers control to the kernel soit can satisfy some user request Kernel returns to user program whenrequest is complete
First draft of a ReadKey SVC handler returns next keystroke to user
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum while (BufferEmpty(kbdnum)) busy wait loop UserRegs[0] = ReadInputBuffer(kbdnum)
Problem Canrsquot interrupt code running in the supervisor modehellipso the buffer never gets filled
ReadKey SVC Attempt 2
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 19
A keyboard SVC handler (slightly modified eg to support a Virtual Keyboard)
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 else UserRegs[0] = ReadInputBuffer(kbdnum)
Problem The process just wastes its time-slice waiting for someone to hit a key
Thatrsquos afunny way
to writea loop
ReadKey SVC Attempt 3
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 20
BETTER On IO wait YIELD remainder of quantum
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 Scheduler( ) else UserRegs[0] = ReadInputBuffer(kbdnum)
RESULT Better CPU utilization
Does timesharing causes CPU use to be less efficient
bull COST Scheduling context-switching overhead but
bull GAIN Productive use of idle time of one process by running another
Sophisticated Scheduling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 21
To improve efficiency further we can avoid scheduling processes in
prolonged IO wait
bull Processes can be in ACTIVE or WAITING (ldquosleepingrdquo) states
bull Scheduler cycles among ACTIVE PROCESSES only
bull Active process moves to WAITING status when it tries to read
a character and buffer is empty
bull Waiting processes each contain a code (eg in PCB) designating
what they are waiting for (eg keyboard N)
bull Device interrupts (eg on keyboard N) move any processes
waiting on that device to ACTIVE state
UNIX kernel utilities
bull sleep(reason) - Puts CurProc to sleep ldquoReasonrdquo is an arbitrary
binary value giving a condition for reactivation
bull wakeup(reason) -Makes active any process in sleep(reason)
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 22
SVC call from application
INTERRUPT from Keyboard n
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 23
ldquoApplicationsrdquo are quasi-parallel
ldquoPROCESSESrdquo
on
ldquoVIRTUAL MACHINESrdquo
each with
bull- CONTEXT
bull (virtual address space)
bull- Virtual IO devices
OS KERNEL has
bull- Interrupt handlers
bull- SVC (trap) handlers
bull- Scheduler
bull- PCB structures containing the
state of inactive processesDevice
0Device
1Alarm Clock
SVC 0 handler
SVC 1 handler
SchedulerIO Handler IO Handler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler
External (Asynchronous)Interrupts
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 12
Example System maintains current time of day (TOD) count at a well-known memory location that can be accessed by programs Butthis value must be updated periodically in response to clock EVENTs ie signal triggered by 60 Hz clock hardware
Program A (Application) bull Executes instructions of the user program bull Doesnt want to know about clock hardware interrupts etc bull Can incorporate TOD into results by examining well-known memory location
Clock Handler bull GUTS Sequence of instructions that increments TOD Written in C bull EntryExit sequences save amp restore interrupted state call the C handler Written as assembler ldquostubsrdquo
Interrupt Handler Coding
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 13
Handler(written in C)
ldquoInterrupt stubrdquo(written in assy)
Simple Timesharing Scheduler
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 14
(PCB = Process Control Block)
Avoiding Re-entrance
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 15
Processor State K-Mode FlagPC31 = 1 for Kernel Mode
Handlers which are interruptable are called RE-ENTRANT and pose special problems Beta like many systems disallows reentrant interrupts Mechanism Uninterruptable ldquoKernel Moderdquo for OS
USER mode(Application)
KERNEL mode(Op Sys)
main() PC=0
PC=1User(savedstate)
ClockHandler
SVCHandler
sInterruptVector
PageFault
Handler
KernelStack
Other K-mode functions eg bull choosing KernalUser context bull Allowing ldquopriviledgedrdquo operations
Polled IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 16
Application code deals directly with IO (eg by busy-waiting)
loop LD(flagr0) BEQ(R0loop) hellip | process keystroke
PROBLEMS bull Uses up (physical) CPU while busy-waiting bull (FIX Multiprocessing codestripping etc) bull Poor system modularity running pgm MUST know about ALL devices bull Uses up CPU cycles even when device is idle
flag
dataCPU
INTERFACE DEVICE
KEY HITFlaglarr1DatalarrASCII
Interrupt-Driven IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 17
OPERATION NO attention to Keyboard during normal operation bull on key strike hardware asserts IRQ to request interrupt bull USER program interrupted PC+4 of interrupted inst saved in XP bull state of USER program saved on KERNEL stack bull KeyboardHandler invoked runs to completion bull state of USER program restored program resumes
TRANSPARENT to USER program
Keyboard Interrupt Handler (in OS KERNEL)
struct Device char Flag Data Keyboard
KeyboardHandler(struct Mstate s) Buffer[inptr] = KeyboardData inptr = (inptr + 1) 100
Assume eachkeyboard hasan associatedbuffer
ReadKey SVC Attempt 1
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 18
A supervisor call (SVC) is an instruction that transfers control to the kernel soit can satisfy some user request Kernel returns to user program whenrequest is complete
First draft of a ReadKey SVC handler returns next keystroke to user
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum while (BufferEmpty(kbdnum)) busy wait loop UserRegs[0] = ReadInputBuffer(kbdnum)
Problem Canrsquot interrupt code running in the supervisor modehellipso the buffer never gets filled
ReadKey SVC Attempt 2
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 19
A keyboard SVC handler (slightly modified eg to support a Virtual Keyboard)
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 else UserRegs[0] = ReadInputBuffer(kbdnum)
Problem The process just wastes its time-slice waiting for someone to hit a key
Thatrsquos afunny way
to writea loop
ReadKey SVC Attempt 3
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 20
BETTER On IO wait YIELD remainder of quantum
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 Scheduler( ) else UserRegs[0] = ReadInputBuffer(kbdnum)
RESULT Better CPU utilization
Does timesharing causes CPU use to be less efficient
bull COST Scheduling context-switching overhead but
bull GAIN Productive use of idle time of one process by running another
Sophisticated Scheduling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 21
To improve efficiency further we can avoid scheduling processes in
prolonged IO wait
bull Processes can be in ACTIVE or WAITING (ldquosleepingrdquo) states
bull Scheduler cycles among ACTIVE PROCESSES only
bull Active process moves to WAITING status when it tries to read
a character and buffer is empty
bull Waiting processes each contain a code (eg in PCB) designating
what they are waiting for (eg keyboard N)
bull Device interrupts (eg on keyboard N) move any processes
waiting on that device to ACTIVE state
UNIX kernel utilities
bull sleep(reason) - Puts CurProc to sleep ldquoReasonrdquo is an arbitrary
binary value giving a condition for reactivation
bull wakeup(reason) -Makes active any process in sleep(reason)
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 22
SVC call from application
INTERRUPT from Keyboard n
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 23
ldquoApplicationsrdquo are quasi-parallel
ldquoPROCESSESrdquo
on
ldquoVIRTUAL MACHINESrdquo
each with
bull- CONTEXT
bull (virtual address space)
bull- Virtual IO devices
OS KERNEL has
bull- Interrupt handlers
bull- SVC (trap) handlers
bull- Scheduler
bull- PCB structures containing the
state of inactive processesDevice
0Device
1Alarm Clock
SVC 0 handler
SVC 1 handler
SchedulerIO Handler IO Handler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler
Interrupt Handler Coding
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 13
Handler(written in C)
ldquoInterrupt stubrdquo(written in assy)
Simple Timesharing Scheduler
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 14
(PCB = Process Control Block)
Avoiding Re-entrance
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 15
Processor State K-Mode FlagPC31 = 1 for Kernel Mode
Handlers which are interruptable are called RE-ENTRANT and pose special problems Beta like many systems disallows reentrant interrupts Mechanism Uninterruptable ldquoKernel Moderdquo for OS
USER mode(Application)
KERNEL mode(Op Sys)
main() PC=0
PC=1User(savedstate)
ClockHandler
SVCHandler
sInterruptVector
PageFault
Handler
KernelStack
Other K-mode functions eg bull choosing KernalUser context bull Allowing ldquopriviledgedrdquo operations
Polled IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 16
Application code deals directly with IO (eg by busy-waiting)
loop LD(flagr0) BEQ(R0loop) hellip | process keystroke
PROBLEMS bull Uses up (physical) CPU while busy-waiting bull (FIX Multiprocessing codestripping etc) bull Poor system modularity running pgm MUST know about ALL devices bull Uses up CPU cycles even when device is idle
flag
dataCPU
INTERFACE DEVICE
KEY HITFlaglarr1DatalarrASCII
Interrupt-Driven IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 17
OPERATION NO attention to Keyboard during normal operation bull on key strike hardware asserts IRQ to request interrupt bull USER program interrupted PC+4 of interrupted inst saved in XP bull state of USER program saved on KERNEL stack bull KeyboardHandler invoked runs to completion bull state of USER program restored program resumes
TRANSPARENT to USER program
Keyboard Interrupt Handler (in OS KERNEL)
struct Device char Flag Data Keyboard
KeyboardHandler(struct Mstate s) Buffer[inptr] = KeyboardData inptr = (inptr + 1) 100
Assume eachkeyboard hasan associatedbuffer
ReadKey SVC Attempt 1
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 18
A supervisor call (SVC) is an instruction that transfers control to the kernel soit can satisfy some user request Kernel returns to user program whenrequest is complete
First draft of a ReadKey SVC handler returns next keystroke to user
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum while (BufferEmpty(kbdnum)) busy wait loop UserRegs[0] = ReadInputBuffer(kbdnum)
Problem Canrsquot interrupt code running in the supervisor modehellipso the buffer never gets filled
ReadKey SVC Attempt 2
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 19
A keyboard SVC handler (slightly modified eg to support a Virtual Keyboard)
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 else UserRegs[0] = ReadInputBuffer(kbdnum)
Problem The process just wastes its time-slice waiting for someone to hit a key
Thatrsquos afunny way
to writea loop
ReadKey SVC Attempt 3
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 20
BETTER On IO wait YIELD remainder of quantum
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 Scheduler( ) else UserRegs[0] = ReadInputBuffer(kbdnum)
RESULT Better CPU utilization
Does timesharing causes CPU use to be less efficient
bull COST Scheduling context-switching overhead but
bull GAIN Productive use of idle time of one process by running another
Sophisticated Scheduling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 21
To improve efficiency further we can avoid scheduling processes in
prolonged IO wait
bull Processes can be in ACTIVE or WAITING (ldquosleepingrdquo) states
bull Scheduler cycles among ACTIVE PROCESSES only
bull Active process moves to WAITING status when it tries to read
a character and buffer is empty
bull Waiting processes each contain a code (eg in PCB) designating
what they are waiting for (eg keyboard N)
bull Device interrupts (eg on keyboard N) move any processes
waiting on that device to ACTIVE state
UNIX kernel utilities
bull sleep(reason) - Puts CurProc to sleep ldquoReasonrdquo is an arbitrary
binary value giving a condition for reactivation
bull wakeup(reason) -Makes active any process in sleep(reason)
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 22
SVC call from application
INTERRUPT from Keyboard n
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 23
ldquoApplicationsrdquo are quasi-parallel
ldquoPROCESSESrdquo
on
ldquoVIRTUAL MACHINESrdquo
each with
bull- CONTEXT
bull (virtual address space)
bull- Virtual IO devices
OS KERNEL has
bull- Interrupt handlers
bull- SVC (trap) handlers
bull- Scheduler
bull- PCB structures containing the
state of inactive processesDevice
0Device
1Alarm Clock
SVC 0 handler
SVC 1 handler
SchedulerIO Handler IO Handler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler
Simple Timesharing Scheduler
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 14
(PCB = Process Control Block)
Avoiding Re-entrance
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 15
Processor State K-Mode FlagPC31 = 1 for Kernel Mode
Handlers which are interruptable are called RE-ENTRANT and pose special problems Beta like many systems disallows reentrant interrupts Mechanism Uninterruptable ldquoKernel Moderdquo for OS
USER mode(Application)
KERNEL mode(Op Sys)
main() PC=0
PC=1User(savedstate)
ClockHandler
SVCHandler
sInterruptVector
PageFault
Handler
KernelStack
Other K-mode functions eg bull choosing KernalUser context bull Allowing ldquopriviledgedrdquo operations
Polled IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 16
Application code deals directly with IO (eg by busy-waiting)
loop LD(flagr0) BEQ(R0loop) hellip | process keystroke
PROBLEMS bull Uses up (physical) CPU while busy-waiting bull (FIX Multiprocessing codestripping etc) bull Poor system modularity running pgm MUST know about ALL devices bull Uses up CPU cycles even when device is idle
flag
dataCPU
INTERFACE DEVICE
KEY HITFlaglarr1DatalarrASCII
Interrupt-Driven IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 17
OPERATION NO attention to Keyboard during normal operation bull on key strike hardware asserts IRQ to request interrupt bull USER program interrupted PC+4 of interrupted inst saved in XP bull state of USER program saved on KERNEL stack bull KeyboardHandler invoked runs to completion bull state of USER program restored program resumes
TRANSPARENT to USER program
Keyboard Interrupt Handler (in OS KERNEL)
struct Device char Flag Data Keyboard
KeyboardHandler(struct Mstate s) Buffer[inptr] = KeyboardData inptr = (inptr + 1) 100
Assume eachkeyboard hasan associatedbuffer
ReadKey SVC Attempt 1
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 18
A supervisor call (SVC) is an instruction that transfers control to the kernel soit can satisfy some user request Kernel returns to user program whenrequest is complete
First draft of a ReadKey SVC handler returns next keystroke to user
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum while (BufferEmpty(kbdnum)) busy wait loop UserRegs[0] = ReadInputBuffer(kbdnum)
Problem Canrsquot interrupt code running in the supervisor modehellipso the buffer never gets filled
ReadKey SVC Attempt 2
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 19
A keyboard SVC handler (slightly modified eg to support a Virtual Keyboard)
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 else UserRegs[0] = ReadInputBuffer(kbdnum)
Problem The process just wastes its time-slice waiting for someone to hit a key
Thatrsquos afunny way
to writea loop
ReadKey SVC Attempt 3
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 20
BETTER On IO wait YIELD remainder of quantum
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 Scheduler( ) else UserRegs[0] = ReadInputBuffer(kbdnum)
RESULT Better CPU utilization
Does timesharing causes CPU use to be less efficient
bull COST Scheduling context-switching overhead but
bull GAIN Productive use of idle time of one process by running another
Sophisticated Scheduling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 21
To improve efficiency further we can avoid scheduling processes in
prolonged IO wait
bull Processes can be in ACTIVE or WAITING (ldquosleepingrdquo) states
bull Scheduler cycles among ACTIVE PROCESSES only
bull Active process moves to WAITING status when it tries to read
a character and buffer is empty
bull Waiting processes each contain a code (eg in PCB) designating
what they are waiting for (eg keyboard N)
bull Device interrupts (eg on keyboard N) move any processes
waiting on that device to ACTIVE state
UNIX kernel utilities
bull sleep(reason) - Puts CurProc to sleep ldquoReasonrdquo is an arbitrary
binary value giving a condition for reactivation
bull wakeup(reason) -Makes active any process in sleep(reason)
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 22
SVC call from application
INTERRUPT from Keyboard n
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 23
ldquoApplicationsrdquo are quasi-parallel
ldquoPROCESSESrdquo
on
ldquoVIRTUAL MACHINESrdquo
each with
bull- CONTEXT
bull (virtual address space)
bull- Virtual IO devices
OS KERNEL has
bull- Interrupt handlers
bull- SVC (trap) handlers
bull- Scheduler
bull- PCB structures containing the
state of inactive processesDevice
0Device
1Alarm Clock
SVC 0 handler
SVC 1 handler
SchedulerIO Handler IO Handler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler
Avoiding Re-entrance
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 15
Processor State K-Mode FlagPC31 = 1 for Kernel Mode
Handlers which are interruptable are called RE-ENTRANT and pose special problems Beta like many systems disallows reentrant interrupts Mechanism Uninterruptable ldquoKernel Moderdquo for OS
USER mode(Application)
KERNEL mode(Op Sys)
main() PC=0
PC=1User(savedstate)
ClockHandler
SVCHandler
sInterruptVector
PageFault
Handler
KernelStack
Other K-mode functions eg bull choosing KernalUser context bull Allowing ldquopriviledgedrdquo operations
Polled IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 16
Application code deals directly with IO (eg by busy-waiting)
loop LD(flagr0) BEQ(R0loop) hellip | process keystroke
PROBLEMS bull Uses up (physical) CPU while busy-waiting bull (FIX Multiprocessing codestripping etc) bull Poor system modularity running pgm MUST know about ALL devices bull Uses up CPU cycles even when device is idle
flag
dataCPU
INTERFACE DEVICE
KEY HITFlaglarr1DatalarrASCII
Interrupt-Driven IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 17
OPERATION NO attention to Keyboard during normal operation bull on key strike hardware asserts IRQ to request interrupt bull USER program interrupted PC+4 of interrupted inst saved in XP bull state of USER program saved on KERNEL stack bull KeyboardHandler invoked runs to completion bull state of USER program restored program resumes
TRANSPARENT to USER program
Keyboard Interrupt Handler (in OS KERNEL)
struct Device char Flag Data Keyboard
KeyboardHandler(struct Mstate s) Buffer[inptr] = KeyboardData inptr = (inptr + 1) 100
Assume eachkeyboard hasan associatedbuffer
ReadKey SVC Attempt 1
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 18
A supervisor call (SVC) is an instruction that transfers control to the kernel soit can satisfy some user request Kernel returns to user program whenrequest is complete
First draft of a ReadKey SVC handler returns next keystroke to user
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum while (BufferEmpty(kbdnum)) busy wait loop UserRegs[0] = ReadInputBuffer(kbdnum)
Problem Canrsquot interrupt code running in the supervisor modehellipso the buffer never gets filled
ReadKey SVC Attempt 2
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 19
A keyboard SVC handler (slightly modified eg to support a Virtual Keyboard)
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 else UserRegs[0] = ReadInputBuffer(kbdnum)
Problem The process just wastes its time-slice waiting for someone to hit a key
Thatrsquos afunny way
to writea loop
ReadKey SVC Attempt 3
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 20
BETTER On IO wait YIELD remainder of quantum
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 Scheduler( ) else UserRegs[0] = ReadInputBuffer(kbdnum)
RESULT Better CPU utilization
Does timesharing causes CPU use to be less efficient
bull COST Scheduling context-switching overhead but
bull GAIN Productive use of idle time of one process by running another
Sophisticated Scheduling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 21
To improve efficiency further we can avoid scheduling processes in
prolonged IO wait
bull Processes can be in ACTIVE or WAITING (ldquosleepingrdquo) states
bull Scheduler cycles among ACTIVE PROCESSES only
bull Active process moves to WAITING status when it tries to read
a character and buffer is empty
bull Waiting processes each contain a code (eg in PCB) designating
what they are waiting for (eg keyboard N)
bull Device interrupts (eg on keyboard N) move any processes
waiting on that device to ACTIVE state
UNIX kernel utilities
bull sleep(reason) - Puts CurProc to sleep ldquoReasonrdquo is an arbitrary
binary value giving a condition for reactivation
bull wakeup(reason) -Makes active any process in sleep(reason)
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 22
SVC call from application
INTERRUPT from Keyboard n
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 23
ldquoApplicationsrdquo are quasi-parallel
ldquoPROCESSESrdquo
on
ldquoVIRTUAL MACHINESrdquo
each with
bull- CONTEXT
bull (virtual address space)
bull- Virtual IO devices
OS KERNEL has
bull- Interrupt handlers
bull- SVC (trap) handlers
bull- Scheduler
bull- PCB structures containing the
state of inactive processesDevice
0Device
1Alarm Clock
SVC 0 handler
SVC 1 handler
SchedulerIO Handler IO Handler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler
Polled IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 16
Application code deals directly with IO (eg by busy-waiting)
loop LD(flagr0) BEQ(R0loop) hellip | process keystroke
PROBLEMS bull Uses up (physical) CPU while busy-waiting bull (FIX Multiprocessing codestripping etc) bull Poor system modularity running pgm MUST know about ALL devices bull Uses up CPU cycles even when device is idle
flag
dataCPU
INTERFACE DEVICE
KEY HITFlaglarr1DatalarrASCII
Interrupt-Driven IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 17
OPERATION NO attention to Keyboard during normal operation bull on key strike hardware asserts IRQ to request interrupt bull USER program interrupted PC+4 of interrupted inst saved in XP bull state of USER program saved on KERNEL stack bull KeyboardHandler invoked runs to completion bull state of USER program restored program resumes
TRANSPARENT to USER program
Keyboard Interrupt Handler (in OS KERNEL)
struct Device char Flag Data Keyboard
KeyboardHandler(struct Mstate s) Buffer[inptr] = KeyboardData inptr = (inptr + 1) 100
Assume eachkeyboard hasan associatedbuffer
ReadKey SVC Attempt 1
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 18
A supervisor call (SVC) is an instruction that transfers control to the kernel soit can satisfy some user request Kernel returns to user program whenrequest is complete
First draft of a ReadKey SVC handler returns next keystroke to user
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum while (BufferEmpty(kbdnum)) busy wait loop UserRegs[0] = ReadInputBuffer(kbdnum)
Problem Canrsquot interrupt code running in the supervisor modehellipso the buffer never gets filled
ReadKey SVC Attempt 2
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 19
A keyboard SVC handler (slightly modified eg to support a Virtual Keyboard)
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 else UserRegs[0] = ReadInputBuffer(kbdnum)
Problem The process just wastes its time-slice waiting for someone to hit a key
Thatrsquos afunny way
to writea loop
ReadKey SVC Attempt 3
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 20
BETTER On IO wait YIELD remainder of quantum
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 Scheduler( ) else UserRegs[0] = ReadInputBuffer(kbdnum)
RESULT Better CPU utilization
Does timesharing causes CPU use to be less efficient
bull COST Scheduling context-switching overhead but
bull GAIN Productive use of idle time of one process by running another
Sophisticated Scheduling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 21
To improve efficiency further we can avoid scheduling processes in
prolonged IO wait
bull Processes can be in ACTIVE or WAITING (ldquosleepingrdquo) states
bull Scheduler cycles among ACTIVE PROCESSES only
bull Active process moves to WAITING status when it tries to read
a character and buffer is empty
bull Waiting processes each contain a code (eg in PCB) designating
what they are waiting for (eg keyboard N)
bull Device interrupts (eg on keyboard N) move any processes
waiting on that device to ACTIVE state
UNIX kernel utilities
bull sleep(reason) - Puts CurProc to sleep ldquoReasonrdquo is an arbitrary
binary value giving a condition for reactivation
bull wakeup(reason) -Makes active any process in sleep(reason)
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 22
SVC call from application
INTERRUPT from Keyboard n
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 23
ldquoApplicationsrdquo are quasi-parallel
ldquoPROCESSESrdquo
on
ldquoVIRTUAL MACHINESrdquo
each with
bull- CONTEXT
bull (virtual address space)
bull- Virtual IO devices
OS KERNEL has
bull- Interrupt handlers
bull- SVC (trap) handlers
bull- Scheduler
bull- PCB structures containing the
state of inactive processesDevice
0Device
1Alarm Clock
SVC 0 handler
SVC 1 handler
SchedulerIO Handler IO Handler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler
Interrupt-Driven IO
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 17
OPERATION NO attention to Keyboard during normal operation bull on key strike hardware asserts IRQ to request interrupt bull USER program interrupted PC+4 of interrupted inst saved in XP bull state of USER program saved on KERNEL stack bull KeyboardHandler invoked runs to completion bull state of USER program restored program resumes
TRANSPARENT to USER program
Keyboard Interrupt Handler (in OS KERNEL)
struct Device char Flag Data Keyboard
KeyboardHandler(struct Mstate s) Buffer[inptr] = KeyboardData inptr = (inptr + 1) 100
Assume eachkeyboard hasan associatedbuffer
ReadKey SVC Attempt 1
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 18
A supervisor call (SVC) is an instruction that transfers control to the kernel soit can satisfy some user request Kernel returns to user program whenrequest is complete
First draft of a ReadKey SVC handler returns next keystroke to user
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum while (BufferEmpty(kbdnum)) busy wait loop UserRegs[0] = ReadInputBuffer(kbdnum)
Problem Canrsquot interrupt code running in the supervisor modehellipso the buffer never gets filled
ReadKey SVC Attempt 2
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 19
A keyboard SVC handler (slightly modified eg to support a Virtual Keyboard)
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 else UserRegs[0] = ReadInputBuffer(kbdnum)
Problem The process just wastes its time-slice waiting for someone to hit a key
Thatrsquos afunny way
to writea loop
ReadKey SVC Attempt 3
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 20
BETTER On IO wait YIELD remainder of quantum
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 Scheduler( ) else UserRegs[0] = ReadInputBuffer(kbdnum)
RESULT Better CPU utilization
Does timesharing causes CPU use to be less efficient
bull COST Scheduling context-switching overhead but
bull GAIN Productive use of idle time of one process by running another
Sophisticated Scheduling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 21
To improve efficiency further we can avoid scheduling processes in
prolonged IO wait
bull Processes can be in ACTIVE or WAITING (ldquosleepingrdquo) states
bull Scheduler cycles among ACTIVE PROCESSES only
bull Active process moves to WAITING status when it tries to read
a character and buffer is empty
bull Waiting processes each contain a code (eg in PCB) designating
what they are waiting for (eg keyboard N)
bull Device interrupts (eg on keyboard N) move any processes
waiting on that device to ACTIVE state
UNIX kernel utilities
bull sleep(reason) - Puts CurProc to sleep ldquoReasonrdquo is an arbitrary
binary value giving a condition for reactivation
bull wakeup(reason) -Makes active any process in sleep(reason)
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 22
SVC call from application
INTERRUPT from Keyboard n
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 23
ldquoApplicationsrdquo are quasi-parallel
ldquoPROCESSESrdquo
on
ldquoVIRTUAL MACHINESrdquo
each with
bull- CONTEXT
bull (virtual address space)
bull- Virtual IO devices
OS KERNEL has
bull- Interrupt handlers
bull- SVC (trap) handlers
bull- Scheduler
bull- PCB structures containing the
state of inactive processesDevice
0Device
1Alarm Clock
SVC 0 handler
SVC 1 handler
SchedulerIO Handler IO Handler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler
ReadKey SVC Attempt 1
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 18
A supervisor call (SVC) is an instruction that transfers control to the kernel soit can satisfy some user request Kernel returns to user program whenrequest is complete
First draft of a ReadKey SVC handler returns next keystroke to user
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum while (BufferEmpty(kbdnum)) busy wait loop UserRegs[0] = ReadInputBuffer(kbdnum)
Problem Canrsquot interrupt code running in the supervisor modehellipso the buffer never gets filled
ReadKey SVC Attempt 2
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 19
A keyboard SVC handler (slightly modified eg to support a Virtual Keyboard)
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 else UserRegs[0] = ReadInputBuffer(kbdnum)
Problem The process just wastes its time-slice waiting for someone to hit a key
Thatrsquos afunny way
to writea loop
ReadKey SVC Attempt 3
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 20
BETTER On IO wait YIELD remainder of quantum
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 Scheduler( ) else UserRegs[0] = ReadInputBuffer(kbdnum)
RESULT Better CPU utilization
Does timesharing causes CPU use to be less efficient
bull COST Scheduling context-switching overhead but
bull GAIN Productive use of idle time of one process by running another
Sophisticated Scheduling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 21
To improve efficiency further we can avoid scheduling processes in
prolonged IO wait
bull Processes can be in ACTIVE or WAITING (ldquosleepingrdquo) states
bull Scheduler cycles among ACTIVE PROCESSES only
bull Active process moves to WAITING status when it tries to read
a character and buffer is empty
bull Waiting processes each contain a code (eg in PCB) designating
what they are waiting for (eg keyboard N)
bull Device interrupts (eg on keyboard N) move any processes
waiting on that device to ACTIVE state
UNIX kernel utilities
bull sleep(reason) - Puts CurProc to sleep ldquoReasonrdquo is an arbitrary
binary value giving a condition for reactivation
bull wakeup(reason) -Makes active any process in sleep(reason)
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 22
SVC call from application
INTERRUPT from Keyboard n
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 23
ldquoApplicationsrdquo are quasi-parallel
ldquoPROCESSESrdquo
on
ldquoVIRTUAL MACHINESrdquo
each with
bull- CONTEXT
bull (virtual address space)
bull- Virtual IO devices
OS KERNEL has
bull- Interrupt handlers
bull- SVC (trap) handlers
bull- Scheduler
bull- PCB structures containing the
state of inactive processesDevice
0Device
1Alarm Clock
SVC 0 handler
SVC 1 handler
SchedulerIO Handler IO Handler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler
ReadKey SVC Attempt 2
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 19
A keyboard SVC handler (slightly modified eg to support a Virtual Keyboard)
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 else UserRegs[0] = ReadInputBuffer(kbdnum)
Problem The process just wastes its time-slice waiting for someone to hit a key
Thatrsquos afunny way
to writea loop
ReadKey SVC Attempt 3
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 20
BETTER On IO wait YIELD remainder of quantum
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 Scheduler( ) else UserRegs[0] = ReadInputBuffer(kbdnum)
RESULT Better CPU utilization
Does timesharing causes CPU use to be less efficient
bull COST Scheduling context-switching overhead but
bull GAIN Productive use of idle time of one process by running another
Sophisticated Scheduling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 21
To improve efficiency further we can avoid scheduling processes in
prolonged IO wait
bull Processes can be in ACTIVE or WAITING (ldquosleepingrdquo) states
bull Scheduler cycles among ACTIVE PROCESSES only
bull Active process moves to WAITING status when it tries to read
a character and buffer is empty
bull Waiting processes each contain a code (eg in PCB) designating
what they are waiting for (eg keyboard N)
bull Device interrupts (eg on keyboard N) move any processes
waiting on that device to ACTIVE state
UNIX kernel utilities
bull sleep(reason) - Puts CurProc to sleep ldquoReasonrdquo is an arbitrary
binary value giving a condition for reactivation
bull wakeup(reason) -Makes active any process in sleep(reason)
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 22
SVC call from application
INTERRUPT from Keyboard n
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 23
ldquoApplicationsrdquo are quasi-parallel
ldquoPROCESSESrdquo
on
ldquoVIRTUAL MACHINESrdquo
each with
bull- CONTEXT
bull (virtual address space)
bull- Virtual IO devices
OS KERNEL has
bull- Interrupt handlers
bull- SVC (trap) handlers
bull- Scheduler
bull- PCB structures containing the
state of inactive processesDevice
0Device
1Alarm Clock
SVC 0 handler
SVC 1 handler
SchedulerIO Handler IO Handler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler
ReadKey SVC Attempt 3
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 20
BETTER On IO wait YIELD remainder of quantum
ReadKEY_h() int kbdnum = ProcTbl[Cur]DPYNum if (BufferEmpty(kbdnum)) UserRegs[XP] = UserRegs[XP]-4 Scheduler( ) else UserRegs[0] = ReadInputBuffer(kbdnum)
RESULT Better CPU utilization
Does timesharing causes CPU use to be less efficient
bull COST Scheduling context-switching overhead but
bull GAIN Productive use of idle time of one process by running another
Sophisticated Scheduling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 21
To improve efficiency further we can avoid scheduling processes in
prolonged IO wait
bull Processes can be in ACTIVE or WAITING (ldquosleepingrdquo) states
bull Scheduler cycles among ACTIVE PROCESSES only
bull Active process moves to WAITING status when it tries to read
a character and buffer is empty
bull Waiting processes each contain a code (eg in PCB) designating
what they are waiting for (eg keyboard N)
bull Device interrupts (eg on keyboard N) move any processes
waiting on that device to ACTIVE state
UNIX kernel utilities
bull sleep(reason) - Puts CurProc to sleep ldquoReasonrdquo is an arbitrary
binary value giving a condition for reactivation
bull wakeup(reason) -Makes active any process in sleep(reason)
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 22
SVC call from application
INTERRUPT from Keyboard n
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 23
ldquoApplicationsrdquo are quasi-parallel
ldquoPROCESSESrdquo
on
ldquoVIRTUAL MACHINESrdquo
each with
bull- CONTEXT
bull (virtual address space)
bull- Virtual IO devices
OS KERNEL has
bull- Interrupt handlers
bull- SVC (trap) handlers
bull- Scheduler
bull- PCB structures containing the
state of inactive processesDevice
0Device
1Alarm Clock
SVC 0 handler
SVC 1 handler
SchedulerIO Handler IO Handler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler
Sophisticated Scheduling
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 21
To improve efficiency further we can avoid scheduling processes in
prolonged IO wait
bull Processes can be in ACTIVE or WAITING (ldquosleepingrdquo) states
bull Scheduler cycles among ACTIVE PROCESSES only
bull Active process moves to WAITING status when it tries to read
a character and buffer is empty
bull Waiting processes each contain a code (eg in PCB) designating
what they are waiting for (eg keyboard N)
bull Device interrupts (eg on keyboard N) move any processes
waiting on that device to ACTIVE state
UNIX kernel utilities
bull sleep(reason) - Puts CurProc to sleep ldquoReasonrdquo is an arbitrary
binary value giving a condition for reactivation
bull wakeup(reason) -Makes active any process in sleep(reason)
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 22
SVC call from application
INTERRUPT from Keyboard n
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 23
ldquoApplicationsrdquo are quasi-parallel
ldquoPROCESSESrdquo
on
ldquoVIRTUAL MACHINESrdquo
each with
bull- CONTEXT
bull (virtual address space)
bull- Virtual IO devices
OS KERNEL has
bull- Interrupt handlers
bull- SVC (trap) handlers
bull- Scheduler
bull- PCB structures containing the
state of inactive processesDevice
0Device
1Alarm Clock
SVC 0 handler
SVC 1 handler
SchedulerIO Handler IO Handler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 22
SVC call from application
INTERRUPT from Keyboard n
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 23
ldquoApplicationsrdquo are quasi-parallel
ldquoPROCESSESrdquo
on
ldquoVIRTUAL MACHINESrdquo
each with
bull- CONTEXT
bull (virtual address space)
bull- Virtual IO devices
OS KERNEL has
bull- Interrupt handlers
bull- SVC (trap) handlers
bull- Scheduler
bull- PCB structures containing the
state of inactive processesDevice
0Device
1Alarm Clock
SVC 0 handler
SVC 1 handler
SchedulerIO Handler IO Handler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler
ReadKey SVC Attempt 4
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 23
ldquoApplicationsrdquo are quasi-parallel
ldquoPROCESSESrdquo
on
ldquoVIRTUAL MACHINESrdquo
each with
bull- CONTEXT
bull (virtual address space)
bull- Virtual IO devices
OS KERNEL has
bull- Interrupt handlers
bull- SVC (trap) handlers
bull- Scheduler
bull- PCB structures containing the
state of inactive processesDevice
0Device
1Alarm Clock
SVC 0 handler
SVC 1 handler
SchedulerIO Handler IO Handler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler
Summary
6004 ndash Fall 2002 11210 L22 ndash Kernel OS 24
Virtual Stuff ndash
bull Memory
bull IO
bull Instructions
bull CPU
Implementation Technology Interrupts
bull Can share stack ndash obeys stack discipline
bull Transparent (well except for XPhellip)
bull Handler coding
Timesharing
bull Separate stack process ndash they donrsquot obey stack discipline
bull Coding trick Interrupt process A return to process B ndash changing
stack (or context) in the scheduler