Instructor liviu iftode iftode@cs ta nader boushehrinejadmoradi naderb@cs fall 2011
This presentation is the property of its rightful owner.
Sponsored Links
1 / 139

CS 519: Operating System Theory PowerPoint PPT Presentation


  • 37 Views
  • Uploaded on
  • Presentation posted in: General

Instructor: Liviu Iftode ([email protected]) TA: Nader Boushehrinejadmoradi ([email protected]) Fall 2011. CS 519: Operating System Theory. Logistics. Location and schedule: CoRE A, Thursdays from noon to 3 pm Instructor: Liviu Iftode Office: CoRE 311 Office Hours: Thursdays 10-11 am

Download Presentation

CS 519: Operating System Theory

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Instructor liviu iftode iftode@cs ta nader boushehrinejadmoradi naderb@cs fall 2011

Instructor: Liviu Iftode ([email protected])

TA: Nader Boushehrinejadmoradi ([email protected])

Fall 2011

CS 519: Operating System Theory


Logistics

Operating System Theory

Logistics

Location and schedule:

CoRE A, Thursdays from noon to 3 pm

Instructor: Liviu Iftode

Office: CoRE 311

Office Hours: Thursdays 10-11 am

TA: Nader Boushehrinejadmoradi

Office: Hill 353

Office Hours: Wednesdays, 2-4 pm

More information

http://www.cs.rutgers.edu/~iftode/cs519-2011.html

http://sakai.rutgers.edu page for the course


Course overview

Operating System Theory

Course Overview

Goals:

Understand how an operating system works

Learn how OS concepts are implemented in a real operating system

Introduce to systems programming

Learn about performance evaluation

Learn about current trends in OS research


Course structure

Operating System Theory

Course Structure

  • Structure:

    • Each major area:

      • Review basic material

      • Discuss the implementation on xv6

      • Read, present, and discuss interesting papers

    • Programming assignments and project


Suggested studying approach

Suggested Studying Approach

  • Read the assigned chapter and/or code before the lecture and try to understand it

  • Start homework and project right away, systems programming is not easy, it takes a lot of time!

  • Ask questions during the lecture

  • Use the mailing list for discussion, do not be afraid to answer a question posted by your colleague even if you are not sure. This is a way to validate your understanding of the material.


Course topics

Course Topics

  • Processes, threads and synchronization

  • Memory management and virtual memory

  • CPU scheduling

  • File systems and I/O management

  • Distributed systems

  • New trends in OS research


Textbooks required

Operating System Theory

Textbooks - Required

  • Stallings. Operating Systems: Internals and Design Principles, Prentice-Hall.

  • Any recent version will do

  • Papers available on the Web


Textbooks recommended

Operating System Theory

Textbooks - Recommended

  • Andrew Tanenbaum. Distributed Operating Systems, Prentice-Hall.


Mit xv6 os

Operating System Theory

MIT xv6 OS

  • Teaching OS developed by Russ Cox, Frans Kaashoek and Robert Morris from MIT

  • UNIX V6 ported to Intel x86 machines

  • Download source code and lecture materials from xv6 home page at MIT


Course requirements

Operating System Theory

Course Requirements

Prerequisites

Undergraduate OS and computer architecture courses

Good programming skills in C and UNIX

What to expect

Several programming assignments with write-ups

Challenging project (a distributed shared memory protocol)

Midterm and final exams

Substantial reading

Read, understand, and extend/modify xv6 code

Paper presentations


Homework

Operating System Theory

Homework

Goals

Learn to design, implement, and evaluate a significant OS-level software system

Improve systems programming skills: virtual memory, threads, synchronization, sockets, etc

Structure

They are all individual assignments

Software must execute correctly

Performance evaluation

Written report for each assignment


Grading

Operating System Theory

Grading

Midterm25%

Final 25%

Programming assignments and in-class presentations 25%

Project 25%


Today

Operating System Theory

Today

What is an Operating System?

Stallings 2.1-2.4

Architecture refresher …


What is an operating system

Operating System Theory

What is an operating system?

application (user)

operating system

hardware

  • A software layer between the hardware and the application programs/users, which provides a virtual machine interface: easy to use (hides complexity) and safe (prevents and handles errors)

  • Acts as resource manager that allows programs/users to share the hardware resources in a protected way: fair and efficient


How does an os work

Operating System Theory

How does an OS work?

application (user)

system calls

upcalls

hardware independent

OS

commands

interrupts

hardware dependent

hardware

  • Receives requests from the application: system calls

  • Satisfies the requests: may issue commands to hardware

  • Handles hardware interrupts: may upcall the application

  • OS complexity: synchronous calls + asynchronous events


Mechanism and policy

Operating System Theory

Mechanism and Policy

application (user)

operating system: mechanism+policy

hardware

  • Mechanisms: data structures and operations that implement an abstraction (e.g. the buffer cache)

  • Policies: the procedures that guide the selection of a certain course of action from among alternatives (e.g. the replacement policy for the buffer cache)

  • Traditional OS is rigid: mechanism together with policy


Mechanism policy split

Operating System Theory

Mechanism-Policy Split

Single policy often not the best for all cases

Separate mechanisms from policies:

OS provides the mechanism + some policy

Applications may contribute to the policy

Flexibility + efficiency require new OS structures and/or new OS interfaces


Os mechanisms and policies

Operating System Theory

OS Mechanisms and Policies


System abstraction processes

Operating System Theory

user: application

create, kill processes,

inter-process comm.

operating system: process

multiplex resources

hardware: computer

System Abstraction: Processes

A process is a system abstraction:

illusion of being the only job in the system


Processes mechanism and policy

Operating System Theory

Processes: Mechanism and Policy

  • Mechanism:

    • Creation, destruction, suspension, context switch, signaling, IPC, etc.

  • Policy:

    • Minor policy questions:

      • Who can create/destroy/suspend processes?

      • How many active processes can each user have?

    • Major policy question that we will concentrate on:

      • How to share system resources between multiple processes?

      • Typically broken into a number of orthogonal policies for individual resources such as CPU, memory, and disk.


Processor abstraction threads

Operating System Theory

Processor Abstraction: Threads

A thread is a processor abstraction: illusion of having 1 processor per execution context

application: execution context

create, kill, synch.

operating system: thread

context switch

hardware: processor

Process vs. Thread: Process is the unit of resource ownership,

while Thread is the unit of instruction execution.


Threads mechanism and policy

Operating System Theory

Threads: Mechanism and Policy

  • Mechanism:

    • Creation, destruction, suspension, context switch, signaling, synchronization, etc.

  • Policy:

    • How to share the CPU between threads from different processes?

    • How to share the CPU between threads from the same process?


Threads

Operating System Theory

Threads

  • Traditional approach: OS uses a single policy (or at most a fixed set of policies) to schedule all threads in the system. Assume two classes of jobs: interactive and batch.

  • More sophisticated approaches: application-controlled scheduling, reservation-based scheduling, etc


Memory abstraction virtual memory

Operating System Theory

Memory Abstraction: Virtual memory

Virtual memory is a memory abstraction: illusion of large contiguous memory, often more memory than physically available

application: address space

virtual addresses

operating system: virtual memory

physical addresses

hardware: physical memory


Virtual memory mechanism

Operating System Theory

Virtual Memory: Mechanism

  • Mechanism:

    • Virtual-to-physical memory mapping, page-fault, etc.

virtual address spaces

p1

p2

processes:

v-to-p memory mappings

physical memory:


Virtual memory policy

Operating System Theory

Virtual Memory: Policy

  • Policy:

    • How to multiplex a virtual memory that is larger than the physical memory onto what is available?

    • How to share physical memory between multiple processes?


Virtual memory

Operating System Theory

Virtual Memory

  • Traditional approach: OS provides a sufficiently large virtual address space for each running application, does memory allocation and replacement, and may ensure protection

  • More sophisticated approaches: external memory management, huge (64-bit) address space, global virtual address space


Storage abstraction file system

Operating System Theory

Storage Abstraction: File System

A file system is a storage abstraction:

illusion of structured storage space

application/user: copy file1 file2

naming, protection,

operations on files

operating system: files, directories

operations on disk

blocks

hardware: disk


File system

Operating System Theory

File System

  • Mechanism:

    • File creation, deletion, read, write, file-block-to-disk-block mapping, file buffer cache, etc.

  • Policy:

    • Sharing vs. protection?

    • Which block to allocate for new data?

    • File buffer cache management?


File system1

Operating System Theory

File System

  • Traditional approach: OS does disk block allocation and caching (buffer cache), disk operation scheduling, and management of the buffer cache

  • More sophisticated approaches: application-controlled buffer cache replacement, log-based allocation (makes writes fast)


Communication abstraction messaging

Operating System Theory

Communication Abstraction: Messaging

Message passing is a communication abstraction: illusion of reliable (sometimes ordered) msg transport

application: sockets

naming, messages

operating system: TCP/IP protocols

network packets

hardware: network interface


Message passing

Operating System Theory

Message Passing

  • Mechanism:

    • Send, receive, buffering, retransmission, etc.

  • Policy:

    • Congestion control and routing

    • Multiplexing multiple connections onto a single NIC


Message passing1

Operating System Theory

Message Passing

  • Traditional approach: OS provides naming schemes, reliable transport of messages, packet routing to destination

  • More sophisticated approaches: user-level protocols, zero-copy protocols, active messages, memory-mapped communication


Character block devices

Operating System Theory

Character & Block Devices

The device interface gives the illusion that devices support the same API – character stream and block access

application/user: read character

from device

naming, protection,

read, write

operating system: character &

block API

hardware-specific

PIO, interrupt handling, or DMA

hardware: keyboard, mouse,

etc.


Devices

Operating System Theory

Devices

  • Mechanisms

    • Open, close, read, write, ioctl, etc.

    • Buffering

  • Policies

    • Protection

    • Sharing?

    • Scheduling?


Cs 519 operating system theory

Operating System Theory

UNIX

Source: Silberschatz, Galvin, and Gagne 2005


Major issues in os design

Operating System Theory

Major Issues in OS Design

  • Programming API: what should the VM look like?

  • Resource management: how should the hardware resources be multiplexed among multiple users?

  • Sharing: how should resources be shared among multiple users?

  • Protection: how to protect users from each other? How to protect programs from each other? How to protect the OS from applications and users?

  • Communication: how can applications exchange information?

  • Structure: how to organize the OS?

  • Concurrency: how do we deal with the concurrency that is inherent in OS’es?


Major issues in os design1

Operating System Theory

Major Issues in OS Design

  • Performance: how to make it all run fast?

  • Reliability: how do we keep the OS from crashing?

  • Persistence: how can we make data last beyond program execution?

  • Accounting: how do we keep track of resource usage?

  • Distribution: how do we make it easier to use multiple computers in conjunction?

  • Scaling: how do we keep the OS efficient and reliable as the offered load increases (more users, more processes, more processors)?


Architecture refresher

Architecture Refresher


Von neumann machine

Operating System Theory

von Neumann Machine

The first computers (late 40’s) were calculators

The advance was the idea of storing the instructions (coded as numbers) along with the data in the same memory


Conceptual model

Operating System Theory

Conceptual Model

Memory contents

0

CPU

1

2

+

-

*

/

3

4

5

6

7

8

9

Addresses of

memory cells

"big byte array"


Operating system perspective

Operating System Theory

Operating System Perspective

A computer is a piece of hardware that runs the fetch-decode-execute loop

Next slides: walk through a very simple computer to illustrate

Machine organization

What the pieces are and how they fit together

The basic fetch-decode-execute loop

How higher-level constructs are translated into machine instructions

At its core, the OS builds what looks like a more sophisticated machine on top of this basic hardware


Fetch decode execute

Operating System Theory

Fetch-Decode-Execute

Computer as a large, general-purpose calculator

Want to program it for multiple functions

All von Neumann computers follow the same loop:

Fetch the next instruction from memory

Decode the instruction to figure out what to do

Execute the instruction and store the result

Instructions are simple. Examples:

Increment the value of a memory cell by 1

Add the contents of memory cells X and Y and store in Z

Multiply contents of memory cells A and B and store in B


Instruction encoding

Operating System Theory

Instruction Encoding

How to represent instructions as numbers?

8 bits

8 bits

8 bits

8 bits

operators

+: 1

-: 2

*: 3

/: 4

operands

destination


Example encoding

Operating System Theory

Example Encoding

Add cell 28 to cell 63 and place result in cell 100:

8 bits

8 bits

8 bits

8 bits

operator

+: 1

-: 2

*: 3

/: 4

source operands

destination

Cell 28

Cell 63

Cell 100

Instruction as a number in:

Decimal: 1:28:63:100

Binary: 00000001:00011100:00111111:01100100

Hexadecimal: 01:1C:3F:64


The program counter

Operating System Theory

The Program Counter

Where is the “next instruction”?

A special memory cell in the CPU called the “program counter" (the PC) points to it

Special-purpose memory in the CPU and devices is called a register

Naïve fetch cycle: Increment the PC by the instruction length (4) after each execute

Assumes all instructions are the same length


Conceptual model1

Operating System Theory

Conceptual Model

Memory

0

operator

1

operand 1

2

operand 2

3

destination

4

5

6

7

8

9

Instruction 0

@ memory

address 0

CPU

+

-

*

/

Arithmetic

Units

Instruction 1

@ memory

address 4

Program

Counter

4


Memory indirection

Operating System Theory

Memory Indirection

How do we access array elements efficiently if all we can do is name a cell?

Modify the operand to allow for fetching an operand "through" a memory location

E.g.: LOAD [5], 2 means fetch the contents of the cell whose address is in cell 5 and put it into cell 2

So, if cell 5 had the number 100, we would place the contents of cell 100 into cell 2

This is called indirection

Fetch the contents of the cell “pointed to” by the cell in the opcode

Use an operand bit to signify if an indirection is desired


Conditionals and looping

Operating System Theory

Conditionals and Looping

Primitive “computers” only followed linear instructions

Breakthrough in early computing was addition of conditionals and branching

Instructions that modify the Program Counter

Conditional instructions

If the content of this cell is [positive, not zero, etc.] execute the instruction or not

Branch Instructions

If the content of this cell is [zero, non zero, etc.], set the PC to this location

jump is an unconditional branch


Example while loop

Operating System Theory

Example: While Loop

while (counter > 0) {

sum = sum + Y[counter];

counter–-;

};

Variables to memory cells: counter is cell 1sum is cell 2index is cell 3Y[0]=cell 4, Y[1]=cell 5…

Memory cell address

Assembly

label

Assembly

"mnemonic"

English

100LOOP:BZ 1,END// Branch to address of END

// if cell 1 is 0.

104ADD 2,[3],2// Add cell 2 and the value

// of the cell pointed to by

// cell 3 then place the

// result in cell 2

108DEC 3// Decrement cell 3 by 1

112DEC 1 // Decrement cell 1 by 1

116 JUMP LOOP// Start executing from the

// address of LOOP

120END: <next code block>


Registers

Operating System Theory

Registers

Architecture rule: large memories are slow, small ones are fast

But everyone wants more memory!

Solution: Put small amount of memory in the CPU for faster operation

Most programs work on only small chunks of memory in a given time period. This is called locality.

So, if we cache the contents of a small number of memory cells in the CPU memory, we might be able to execute many instructions before having to access memory

Small memory in CPU named separately in the instructions from the “main memory”

Small memory in CPU = registers

Large memory = main memory


Register machine model

Operating System Theory

Register Machine Model

Memory

0

CPU

1

+,-,*,/

Arithmetic Units

2

3

Logic Units

<,>,!=

4

Program Counter

8

5

6

register 0

24

7

register 1

100

8

9

register 2

18


Registers cont

Operating System Theory

Registers (cont)

Most CPUs have 16-32 “general-purpose” registers

All look the “same”: combination of operators, operands, and destinations possible

Operands and destination can be in:

Registers only (Sparc, PowerPC, Mips, Alpha)

Registers & 1 memory operand (Intel x86 and clones)

Any combination of registers and memory (Vax)

Only memory operations possible in "register-only" machines are load from and store to memory

Operations 100-1000 times faster when operands are in registers compared to when they are in memory

Save instruction space too

Only address 16-32 registers, not GB of memory


Typical instructions

Operating System Theory

Typical Instructions

Add the contents of register 2 and register 3 and place result in register 5

ADD r2,r3,r5

Add 100 to the PC if register 2 is not zero

Relative branch

BNZ r2,100

Load the contents of memory location whose address is in register 5 into register 6

LDI r5,r6


Memory hierarchy

Operating System Theory

Memory Hierarchy

cpu

word transfer

  • decrease cost per bit

  • decrease frequency of access

  • increase capacity

  • increase access time

  • increase size of transfer unit

cache

block transfer

main memory

page transfer

disks


Memory access costs

Operating System Theory

Memory Access Costs

Intel Pentium IV Level Size Assoc Block Access

Extreme Edition Size Time

(3.2 GHz, 32 bits) L1 8KB 4-way 64B 2 cycles

L2 512KB 8-way 64B 19 cycles

L3 2MB 8-way 64B 43 cycles

Mem 206 cycles

AMD Athlon 64 FX-53

(2.4 GHz, 64 bits, L1 128KB 2-way 64B 3 cycles

on-chip mem cntl) L2 1MB 16-way 64B 13 cycles

Mem 125 cycles

Processors introduced in 2003


Memory access costs1

Operating System Theory

Memory Access Costs

Intel Core 2 Quad Level Size Assoc Block Access

Q9450 Size Time

(2.66 GHz, 64 bits) L1 128KB 8-way 64B 3 cycles

shared L2 6MB 24-way 64B 15 cycles

Mem 229 cycles

Quad-core AMD Opteron 2360

(2.5 GHz, 64 bits) L1 128KB 2-way 64B 3 cycles

L2 512KB 16-way 64B 7 cycles

shared L3 2MB 32-way 64B 19 cycles

Mem 356 cycles

Processors introduced in 2008


Hardware caches

Operating System Theory

Hardware Caches

  • Motivated by the mismatch between processor and memory speed

  • Closer to the processor than the main memory

  • Smaller and faster than the main memory

  • Act as “attraction memory”: contains the value of main memory locations that were recently accessed (temporal locality)

  • Transfer between caches and main memory is performed in units called cache blocks/lines

  • Caches contain also the value of memory locations that are close to locations that were recently accessed (spatial locality)


Cache architecture

Operating System Theory

Cache Architecture

2 ways, 6 sets

  • Capacity miss

  • Conflict miss

  • Cold miss

CPU

cache line

L1

L2

associativity

Memory

Cache line ~32-128

Associativity ~2-32


Cache design issues

Operating System Theory

Cache Design Issues

cpu

word transfer

cache

block transfer

main

memory

  • Cache size and cache block size

  • Mapping: physical/virtual caches, associativity

  • Replacement algorithm: direct or LRU

  • Write policy: write through/write back


Abstracting the machine

Operating System Theory

Abstracting the Machine

Bare hardware provides a computation device

How to share this expensive piece of equipment between multiple users?

Sign up during certain hours?

Give program to an operator?

They run it and give you the results

Software to give the illusion of having it all to yourself while actually sharing it with others!

This software is the Operating System

Need hardware support to “virtualize” machine


Architecture features for the os

Operating System Theory

Architecture Features for the OS

Next, we'll look at the mechanisms the hardware designers add to allow OS designers to abstract the basic machine in software

Processor modes

Exceptions

Traps

Interrupts

These require modifications to the basic fetch-decode-execute cycle in hardware


Processor modes

Operating System Theory

Processor Modes

OS code is stored in memory … von Neumann model, remember?

What if a user program modifies OS code or data?

Introduce modes of operation

Instructions can be executed in user mode or system mode

A special register holds which mode the CPU is in

Certain instructions can only be executed when in system mode

Likewise, certain memory locations can only be written when in system mode

Only OS code is executed in system mode

Only OS can modify its memory

The mode register can only be modified in system mode


Simple protection scheme

Operating System Theory

Simple Protection Scheme

Addresses < 100 are reserved for OS use

Mode register provided

zero = SYS = CPU is executing the OS (in system mode)

one = USR = CPU is executing in user mode

Hardware does this check:

On every fetch, if the mode bit is USR and the address is less than 100, then do not execute the instruction

When accessing operands, if the mode bit is USR and the operand address is less than 100, do not execute the instruction

Mode register can only be set if mode is SYS


Simple protection model

Operating System Theory

Simple Protection Model

99

100

101

102

103

104

105

106

CPU

Memory

+,-,*,/

0

Arithmetic Units

Logic Units

<,>,!=

OS

Program Counter

8

User

Registers 0-31

Mode register

0


Fetch decode execute revised

Operating System Theory

Fetch-decode-execute Revised

Fetch:

if ((PC < 100) && (mode register == USR)) then

Error! User tried to access the OS

else

fetch the instruction at the PC

Decode:

if ((destination register == mode) && (mode register == USR)) then

Error! User tried to set the mode register

< more decoding >

Execute:

if ((an operand < 100) && (mode register == USR) then

Error! User tried to access the OS

else

execute the instruction


Exceptions

Operating System Theory

Exceptions

What happens when a user program tries to access memory holding the operating system code or data?

Answer: exceptions

An exception occurs when the CPU encounters an instruction that cannot be executed

Modify fetch-decode-execute loop to jump to a known location in the OS when an exception happens

Different errors jump to different places in the OS (are "vectored" in OS speak)


Fetch decode execute with exceptions

Operating System Theory

Fetch-decode-execute with Exceptions

Fetch:

if ((PC < 100) && (mode register == USR)) then

set the PC = 60

set the mode = SYS

fetch the instruction at the PC

Decode:

if ((destination register == mode) && (mode register == USR)) then

set the PC = 64

set the mode = SYS

goto fetch

< more decoding >

Execute:

< check the operands for a violation >

60 is the well-known entry point

for a memory violation

64 is the well- known entry point

for a mode register violation


Access violations

Operating System Theory

Access Violations

Notice both instruction fetch from memory and data access must be checked

Execute phase must check both operands

Execute phase must check again when performing an indirect load

This is a very primitive memory protection scheme. We'll cover more complex virtual memory mechanisms and policies later in the course


Recovering from exceptions

Operating System Theory

Recovering from Exceptions

The OS can figure out what caused the exception from the entry point

But how can it figure out where in the user program the problem was?

Solution: add another register, the PC’

When an exception occurs, save the current PC to PC’ before loading the PC with a new value

OS can examine the PC' and perform some recovery action

Stop user program and print an error message: error at address PC'

Run a debugger


Fetch decode execute with exceptions recovery

Operating System Theory

Fetch-decode-execute with Exceptions & Recovery

Fetch:

if ((PC < 100) && (mode register == USR)) then

set the PC' = PC

set the PC = 60

set the mode = SYS

Decode:

if ((destination register == mode) && (mode register == USR)) then

set the PC' = PC

set the PC = 64

set the mode = SYS

goto fetch

< more decoding >

Execute:


Traps

Operating System Theory

Traps

Now, we know what happens when a user program illegally tries to access OS code or data

How does a user program legitimately access OS services?

Solution: Trap instruction

A trap is a special instruction that forces the PC to a known address and sets the mode to system mode

Unlike exceptions, traps carry some arguments to the OS

Foundation of the system call


Fetch decode execute with traps

Operating System Theory

Fetch-decode-execute with Traps

Fetch:

if ((PC < 100) && (mode register == USR)) then

< memory exception >

Decode:

if (instruction is a trap) then

set the PC' = PC

set the PC = 68

set the mode = SYS

goto fetch

if ((destination register == mode) && (mode register == USR)) then

< mode exception >

Execute:


Traps1

Operating System Theory

How does the OS know which service the user program wants to invoke on a trap?

User program passes the OS a number that encodes which OS service is desired

This example machine could include the trap ID in the instruction itself:

Most real CPUs have a convention for passing the trap ID in a set of registers

E.g. the user program sets register 0 with the trap ID, then executes the trap instruction

Traps

Trap opcode

Trap service ID


Returning from a trap

Operating System Theory

Returning from a Trap

How to "get back" to user mode and the user's code after a trap?

Set the mode register = USR then set the PC?

But after the mode bit is set to user, exception!

Set the PC, then set the mode bit?

Jump to "user-land", then in kernel mode

Most machines have a "return from exception" instruction

A single hardware instruction:

Sets the PC to PC'

Sets the mode bit to user mode

Traps and exceptions use the same mechanism (RTE)


Fetch decode execute with traps1

Operating System Theory

Fetch-decode-execute with Traps

Fetch:

if ((PC < 100) && (mode register == USR)) then

< memory exception >

Decode:

if (instruction is RTE) then

set the PC = PC'

set the mode = USR

goto fetch

if ((destination register == mode) && (mode register == USR)) then

< mode exception >

Execute:


Interrupts

Operating System Theory

Interrupts

How can we force the CPU back into system mode if the user program is off computing something?

Solution: Interrupts

An interrupt is an external event that causes the CPU to jump to a known address

Link an interrupt to a periodic clock

Modify fetch-decode-execute loop to check an external line set periodically by the clock


Simple interrupt model

Operating System Theory

Simple Interrupt Model

CPU

Memory

+,-,*,/

OS

Arithmetic Units

User

Logic Units

<,>,!=

Program Counter

8

Interrupt line

PC'

Clock

Registers 0-31

Reset line

Mode register

0


The clock

Operating System Theory

The Clock

The clock starts counting to 10 milliseconds

When 10 milliseconds elapse, the clock sets the interrupt line "high" (e.g. sets it to logic 1)

When the CPU toggles the reset line, the clock sets the interrupt line low and starts count to 10 milliseconds again


Fetch decode execute with interrupts

Operating System Theory

Fetch-decode-execute with Interrupts

Fetch:

if (clock interrupt line == 1) then

set the PC' = PC

set the PC = 72

set the mode = SYS

goto fetch

if ((PC < 100) && (mode register == USR)) then

< memory exception >

fetch next instruction

Decode:

if (instruction is a trap) then

< trap exception >

if ((destination register == mode) && (mode register == USR)) then

< mode exception >

< more decoding >

Execute: …


Entry points

Operating System Theory

Entry Points

What are the "entry points" for our little example machine?

60: memory access violation

64: mode register violation

68: User-initiated trap

72: Clock interrupt

Each entry point is typically a jump to some code block in the OS

All real OS’es have a set of entry points for exceptions, traps and interrupts

Sometimes they are combined and software has to figure out what happened.


Saving and restoring context

Operating System Theory

Saving and Restoring Context

Recall the processor state:

PC, PC', R0-R31, mode register

When an entry to the OS happens, we want to start executing the correct routine then return to the user program such that it can continue executing normally

Can't just start using the registers in the OS!

Solution: save/restore the user context

Use the OS memory to save all the CPU state

Before returning to user, reload all the registers and then execute a return from exception instruction


Input and output

Operating System Theory

Input and Output

How can humans get at the data?

How to load programs?

What happens if I turn the machine off?

Can I send the data to another machine?

Solution: add devices to perform these tasks

Keyboards, mice, graphics

Disk drives

Network cards


A simple i o device

Operating System Theory

A Simple I/O device

Network card has 2 registers:

A store into the “transmit” register sends the byte over the wire

Transmit often is written as TX (E.g. TX register)

A load from the “receive” register reads the last byte that was read from the wire

Receive is often written as RX

How does the CPU access these registers?

Solution: map them into the memory space

An instruction that accesses memory cell 98 really accesses the transmit register instead of memory

An instruction that accesses memory cell 99 really accesses the receive register

These registers are said to be memory-mapped


Basic network i o

Operating System Theory

Basic Network I/O

98

Transmit Reg.

99

Receive Reg.

Network card

CPU

Memory

0

+,-,*,/

Arithmetic Units

Logic Units

<,>,!=

Program Counter

8

PC'

Registers 0-31

Clock

Mode register

0

Interrupt line

Reset line


Why memory mapped registers

Operating System Theory

Why Memory-Mapped Registers?

"Stealing" memory space for device registers has 2 functions:

Allows protected access --- only the OS can access the device.

User programs must trap into the OS to access I/O devices because of the normal protection mechanisms in the processor

Why do we want to prevent direct access to devices by user programs?

OS can control devices and move data to/from devices using regular load and store instructions

No changes to the instruction set are required

This is called programmed I/O


Status registers

Operating System Theory

Status Registers

How does the OS know if a new byte has arrived?

How does the OS know when the last byte has been transmitted? (so it can send another one)

Solution: status registers

A status register holds the state of the last I/O operation

Our network card has 1 status register

To transmit, the OS writes a byte into the TX register and sets bit 0 of the status register to 1. When the card has successfully transmitted the byte, it sets bit 0 of the status register back to 0.

When the card receives a byte, it puts the byte in the RX register and sets bit 1 of the status register to 1. After the OS reads this data, it sets bit 1 of the status register back to 0.


Polled i o

Operating System Theory

Polled I/O

To Transmit:

While (status register bit 0 == 1); // wait for card to be ready

TX register = data;

Status reg = status reg | 0x1;// tell card to TX (set bit 0 to 1)

Naïve Receive:

While (status register bit 1 != 1);// wait for data to arrive

Data = RX register;

Status reg = status reg & 0x01;// tell card got data (clear bit 1)

Can’t stall OS waiting to receive!

Solution: poll after the clock ticks

If (status register bit 1 == 1) {

Data = RX register

Status reg = status reg & 0x01;

}


Interrupt driven i o

Operating System Theory

Interrupt-driven I/O

Polling can waste many CPU cycles

On transmit, CPU slows to the speed of the device

Can't block on receive, so tie polling to clock, but wasted work if no RX data

Solution: use interrupts

When network has data to receive, signal an interrupt

When data is done transmitting, signal an interrupt


Polling vs interrupts

Operating System Theory

Polling vs. Interrupts

Why poll at all?

Interrupts have high overhead:

Stop processor

Figure out what caused interrupt

Save user state

Process request

Key factor is frequency of I/O vs. interrupt overhead


Direct memory access dma

Operating System Theory

Direct Memory Access (DMA)

Problem with programmed I/O: CPU must load/store all the data into device registers.

The data is probably in memory anyway!

Solution: more hardware to allow the device to read and write memory just like the CPU

Base + bound or base + count registers in the device

Set base and count registers

Set the start transmit register

I/O device reads memory from base

Interrupts when done


Pio vs dma

Operating System Theory

PIO vs. DMA

Overhead less for PIO than DMA

PIO is a check against the status register, then send or receive

DMA must set up the base, count, check status, take an interrupt

DMA is more efficient at moving data

PIO ties up the CPU for the entire length of the transfer

Size of the transfer becomes the key factor in when to use PIO vs. DMA


Typical i o devices

Operating System Theory

Typical I/O Devices

Disk drives:

Present the CPU with a linear array of fixed-sized blocks that are persistent across power cycles

Network cards:

Allow the CPU to send and receive discrete units of data (packets) across a wire, fiber or radio

Packet sizes 64-8K bytes are typical

Graphics adapters:

Present the CPU with a memory that is turned into pixels on a screen


Recap the i o design space

Operating System Theory

Recap: the I/O design space

Polling vs. interrupts

How does the device notify the processor that an event happened?

Polling: Device is passive, CPU must read/write a register

Interrupt: device signals CPU via an interrupt

Programmed I/O vs. DMA

How does the device send and receive data?

Programmed I/O: CPU must use load/store into the device

DMA: Device reads and writes memory


Practical how to boot

Operating System Theory

Practical: How to boot?

How does a machine start running the operating system in the first place?

The process of starting the OS is called booting

Sequence of hardware + software events form the boot protocol

Boot protocol in modern machines is a 3-stage process

CPU starts executing from a fixed address

Firmware loads the boot loader

Boot loader loads the OS


Boot protocol

Operating System Theory

Boot Protocol

(1) CPU is hard-wired to start executing from a known address in memory

This memory address is typically mapped to solid-state persistent memory (e.g., ROM, EPROM, Flash)

(2) Persistent memory contains the “boot” code

This kind of software is called firmware

On x86, the starting address corresponds to the BIOS (basic input-output system) boot entry point

This code reads 1 block from the disk drive. This block is loaded and then executed. This program is the boot loader.


Boot protocol cont

Operating System Theory

Boot Protocol (cont)‏

(3) The boot loader can then load the rest of the operating system from disk. Note that at this point the OS still is not running

The boot loader can know about multiple operating systems

The boot loader can know about multiple versions of the OS


Why have a boot protocol

Operating System Theory

Why Have A Boot Protocol?

Why not just store the OS into persistent memory?

Separate the OS from the hardware

Multiple OSes or different versions of the OS

Want to boot from different devices

E.g. security via a network boot

OS is pretty big (tens of MBs). Rather not have it as firmware


Basic computer architecture

Operating System Theory

Basic Computer Architecture

Memory

CPU

memory bus

I/O bus

Net interface

Disk

core 1

core 2

core n

Single-CPU-chip computer:

  • Single threaded

  • Multithreaded

  • Multi/many-core


Caching inside a 4 core cpu

Operating System Theory

Caching Inside A 4-Core CPU

Core

Core

Core

Core

Private L1

Caches

(coherence!)

Shared L2

Cache

CPU


Multi cpu chip multiprocessors

Operating System Theory

Multi-CPU-Chip Multiprocessors

CPU

CPU

Memory

cache

cache

memory bus

I/O bus

Last level of hw caching

disk

Net interface

  • Simple scheme (SMP): more than one CPU on the same bus

  • Memory is shared among CPUs -- cache coherence between LLCs

  • Bus contention increases -- does not scale

  • Alternative (non-bus) system interconnect -- complex and expensive

  • SMPs naturally support single-image operating systems


Cache coherent shared memory uma

Operating System Theory

Cache-Coherent Shared-Memory: UMA

Core

Core

Core

Core

Snooping

Caches

Memory


Cc numa multiprocessors

Operating System Theory

CC-NUMA Multiprocessors

Memory

Memory

Mem

Cntrl

Mem

Cntrl

CPU

CPU

cache

cache

memory bus

memory bus

I/O bus

I/O bus

network

disk

disk

  • Non-uniform access to different memories

  • Hardware allows remote memory accesses and maintains cache coherence

  • Scalable interconnect  more scalable than bus-based UMA systems

  • Also naturally supports single-image operating systems

  • Complex hardware coherence protocols


Multicomputers

Operating System Theory

Multicomputers

CPU

CPU

Memory

Memory

cache

cache

memory bus

memory bus

I/O bus

I/O bus

network

disk

Net interface

disk

Net interface

  • Network of computers: “share-nothing” -- cheap

  • Distributed resources: difficult to program

    • Message passing

    • Distributed file system

  • Challenge: build efficient global abstraction in software


Os issues in different architectures

OS Issues in Different Architectures


Uma multiprocessors

Operating System Theory

UMA Multiprocessors

CPU

CPU

Memory

cache

cache

memory bus

I/O bus

disk

Net interface


Uma multiprocessors os issues

Operating System Theory

UMA Multiprocessors: OS Issues

Processes

How to divide processors among multiple processes? Time sharing vs. space sharing

Threads

Synchronization mechanisms based on shared memory

How to schedule threads of a single process on its allocated processors?

Affinity scheduling?


Cc numa multiprocessors1

Operating System Theory

CC-NUMA Multiprocessors

Memory

Memory

Mem

Cntrl

Mem

Cntrl

CPU

CPU

cache

cache

memory bus

memory bus

I/O bus

I/O bus

network

disk

disk

Hardware allows remote memory accesses and

maintains cache coherence through protocol


Cc numa multiprocessors os issues

Operating System Theory

CC-NUMA Multiprocessors: OS Issues

Memory locality!!

Remote memory access up to an order of magnitude more expensive than local access

Thread migration vs. page migration

Page replication

Affinity scheduling


Multicomputers1

Operating System Theory

Multicomputers

CPU

CPU

Memory

Memory

cache

cache

memory bus

memory bus

I/O bus

I/O bus

network

disk

Net interface

disk

Net interface

Share-nothing


Multicomputers os issues

Operating System Theory

Multicomputers: OS Issues

Scheduling

Node allocation? (CPU and memory allocated together)

Process migration?

Software distributed shared-memory (Soft DSM)

Distributed file systems

Low-latency reliable communication


Os structure

OS Structure


Traditional os structure

Operating System Theory

Traditional OS Structure

  • Monolithic/layered systems

    • one/N layers all executed in “kernel-mode”

    • good performance but rigid

user

process

user

system calls

memory

system

file

system

OS kernel

hardware


Micro kernel os

Operating System Theory

Micro-kernel OS

memory

server

client

process

file

server

user mode

IPC

micro-kernel

hardware

  • Client-server model, IPC between clients and servers

  • The micro-kernel provides protected communication

  • OS functions implemented as user-level servers

  • Flexible but efficiency is the problem

  • Easy to extend for distributed systems


Extensible os kernel

Operating System Theory

Extensible OS kernel

process

process

user mode

my

memory

service

default

memory

service

extensible kernel

hardware

  • User processes can load customized OS services into the kernel

  • Good performance and flexibility but protection and scalability become problems


Exokernels

Operating System Theory

Exokernels

user level

allocate resource

OS libraries

exokernel

hardware

  • Kernel provides only a very low-level interface to the hardware

  • Idea is to allow an application to manage its resources (kernel ensures that resource is free and application has right to access it)

  • OS functionality implemented as user-level libraries to simplify programming


Some history

Some History …


Brief os history

Brief OS History

  • In the beginning, there really wasn’t an OS

    • Program binaries were loaded using switches

    • Interface included blinking lights (cool!)

  • Then came batch systems

    • OS was implemented to transfer control from one job to the next

    • OS was always resident in memory

      • Resident monitor

    • Operator provided machine/OS with a stream of programs with delimiters

      • Typically, input device was a card reader, so delimiters were known as control cards


Spooling

Spooling

  • CPUs were much faster than card readers and printers

  • Disks were invented – disks were much faster than card readers and printers

  • So, what do we do? Pipelining … what else?

    • Read job 1 from cards to disk. Run job 1 while reading job 2 from cards to disk; save output of job 1 to disk. Print output of job 1 while running job 2 while reading job 3 from cards to disk. And so on …

    • This is known as spooling: Simultaneous Peripheral Operation On-Line

  • Can use multiple card readers and printers to keep up with CPU if needed

  • Improves both system throughput and response time


Multiprogramming

Multiprogramming

  • CPUs were still idle whenever executing program needs to interact with peripheral device

    • E.g., reading more data from tape

  • Multiprogrammed batch systems were invented

    • Load multiple programs onto disk at the same time (later into memory)

    • Switch from one job to another when the first job performs an I/O operation

    • Overlap I/O of one job with computation of another job

    • Peripherals have to be asynchronous

    • Have to know when I/O operation is done: interrupt vs. polling

  • Increase system throughput, possibly at the expense of response time


Time sharing

Time-Sharing

  • As you can imagine, batching was a big pain

    • You submit a job, you twiddle your thumbs for a while, you get the output, see a bug, try to figure out what went wrong, resubmit the job, etc.

    • Even running production programs was difficult in this environment

  • Technology got better: can now have terminals and support interactive interfaces

  • How to share a machine (remember machines were expensive back then) between multiple people and still maintain interactive user interface?

  • Time-sharing

    • Connect multiple terminals to a single machine

    • Multiplex machine between multiple users

    • Machine has to be fast enough to give illusion that each user has own machine

    • Multics was the first large time-sharing system – mid-1960’s


Parallel os

Parallel OS

  • Some applications comprise tasks that can be executed simultaneously

    • Weather prediction, scientific simulations, recalculation of a spreadsheet

  • Can speedup execution by running these tasks in parallel on many processors

  • Need OS, compiler, and/or language support for dividing programs into multiple parallel activities

  • Need OS support for fast communication and synchronization

  • Many different parallel architectures

  • Main goal is performance


Real time os

Real-Time OS

  • Some applications have time deadlines by when they have to complete certain tasks

  • Hard real-time system

    • Medical imaging systems, industrial control systems, etc.

    • Catastrophic failure if system misses a deadline

      • What happens if collision avoidance software on an oil tanker does not detect another ship before the “turning or breaking” distance of the tanker?

    • Challenge lies in how to meet deadlines with minimal resource waste

  • Soft real-time system

    • Multimedia applications

    • May be annoying but is not catastrophic if a few deadlines are missed

    • Challenge 1: how to meet most deadlines with minimal resource waste

    • Challenge 2: how to load-shed if become overloaded


Distributed os

Distributed OS

  • Clustering

    • Use multiple small machines to handle large service demands

      • Cheaper than using one large machine

      • Better potential for reliability, incremental scalability, and absolute scalability

  • Wide-area distributed systems

    • Allow use of geographically distributed resources

      • E.g., use of a local PC to access web services

      • Don’t have to carry needed information with us

  • Need OS support for communication and sharing of distributed resources

    • E.g., network file systems

  • Want performance (although speedup is not metric of interest here), high reliability, and use of diverse resources


Embedded os

Embedded OS

  • Pervasive computing

    • Right now, cell phones and PDAs

    • Future, computational elements everywhere

  • Characteristics

    • Constrained resources: slow CPU, small memories, no disk, etc.

    • What’s new about this? Isn’t this just like the old computers?

      • Well no, because we want to execute more powerful programs than before

    • How can we execute more powerful programs if our hardware is similar to old hardware?

      • Use many, many of them

      • Augment with services running on powerful machines

  • OS support for power management, mobility, resource discovery, etc.


Virtual machines and hypervisors

Virtual Machines and Hypervisors

  • Popular in the 60’s and 70’s, vanished in the 80’s and 90’s

  • Idea: Partition a physical machine into a number of virtual machines

    • Each virtual machine behaves as a separate computer

    • Can support heterogeneous operating systems (called guest OSes)

    • Provides performance isolation and fault isolation

    • Facilitates virtual machine migration

    • Facilitates server consolidation

  • Hypervisor or Virtual Machine Monitor

    • Underlying software that manages multiple virtual machines


Virtual machines and hypervisors1

Virtual Machines and Hypervisors

Source: Silberschatz, Galvin, and Gagne 2005


Virtual machines another architecture

Virtual Machines: Another Architecture

Source: Silberschatz, Galvin, and Gagne 2005


Backup slides

Operating System Theory

Backup Slides


The unix time sharing system

Operating System Theory

The UNIX Time-sharing System

  • Features

    • Time-sharing system

    • Hierarchical file system

    • System command language (shell)

    • File-based device-independent I/O

  • Versions 1 & 2

    • No multi-programming

    • Ran on PDP-7,9,11


More history

Operating System Theory

More History

Version 4

Ran on PDP-11 (hardware costing < $40k)

Took less than 2 man-years to code

~50KB code size (kernel)

Written in C


File system2

Operating System Theory

File System

Ordinary files (uninterpreted)

Directories

File of files

Organized as a rooted tree

Pathnames (relative and absolute)

Contains links to parent, itself

Multiple links to files can exist

Link - hard (different name for the same file; modifications seen under both names, but erasing one does not affect the other) or symbolic (pointer to a file; erasing the file leaves pointers hanging)


File system contd

Operating System Theory

File System (contd)‏

Special files

Each I/O device associated with a special file

To provide uniform naming and protection model

Uniform I/O


Removable file systems

Operating System Theory

Removable File Systems

  • Tree-structured file hierarchies

  • Mounted on existing space by using mount

  • No links between different file systems


Protection

Operating System Theory

Protection

User id

uid marked on files

Ten protection bits

nine - rwx permissions for user, group & other

setuid bit is used to change user id

Super-user has special uid

exempt from constraints on access


Uniform i o model

Operating System Theory

Uniform I/O Model

Basic system calls

open, close, creat, read, write, seek

Streams of bytes, no records

No locks visible to the user


File system implementation

Operating System Theory

File System Implementation

I-node

contains a short description of one file

direct, single-indirect and double-indirect pointers to disk blocks

I-list

table of i-nodes, indexed by i-number

pathname scanning to determine i-number

Allows simple and efficient fsck

Buffered data

Different disk write policies for data and metadata


Processes

Operating System Theory

Processes

Process

Memory image, register values, status of open files etc.

Memory image consists of text, data, and stack segments

To create new processes

pid = fork()

process splits into two independently executing processes (parent and child)

Pipes used for communication between related processes

exec(file, arg1, ..., argn) used to start another application


The shell

Operating System Theory

The Shell

  • Command-line interpreter

    • cmd arg1 arg2 ... argn

    • i/o redirection

      • <, >

    • filters & pipes

      • ls | more

    • job control

      • cmd &

    • simplified shell =>


  • Login