CS162

Operating Systems and

Systems Programming
Lecture 1
What is an Operating System?
August 30
th
, 2010
Prof. John Kubiatowicz
http://inst.eecs.berkeley.edu/~cs162
Lec 1.2 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Who am I?
Professor John Kubiatowicz (Prof Kubi)
Background in Hardware Design
Alewife project at MIT
Designed CMMU, Modified SPAR C processor
Helped to write operating system
Background in Operating Systems
Worked for Project Athena (MIT)
OS Developer (device drivers,
network file systems)
Worked on Clustered High-Availability systems
(CLAM Associates)
OS lead researcher for the new Berkeley PARLab
(Tessellation OS). More later.
Peer-to-Peer
OceanStore project
Store your data for 1000 years
Tapestry and Bamboo
Find you data around globe
Quantum Computing
Well, this is just cool, but probably not apropos
T
e
s
s
e
l
l
a
t
i
o
n
A
l
e
w
i
f
e
O
c
e
a
n
S
t
o
r
e
Lec 1.3 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Goals for Today
What is an Operating System?
And what is it not?
Examples of Operating Systems design
Why study Operating Systems?
Oh, and How does this class operate?
Interactive is important!
Ask Questions!
Note: Some slides and/or pictures in the following are
adapted from slides 2005 Silberschatz, Galvin, and Gagne. Slides
courtesy of Kubiatowicz, AJ Shankar, George Necula, Alex Aiken,
Eric Brewer, Ras Bodik, Ion Stoica, Doug Tygar, and David Wagner.
Lec 1.4 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Technology Trends: Moores Law
2X transistors/Chip Every 1.5 years
Called Moores Law
Moores Law
Microprocessors have
become smaller, denser,
and more powerful.
Gordon Moore (co-founder of
Intel) predicted in 1965 that the
transistor density of
semiconductor chips would
double roughly every 18
months.
Lec 1.5 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Societal Scale Information Systems
Scalable, Reliable,
Secure Services
MEMS for
Sensor Nets
Internet
Connectivity
Clusters
Massive Cluster
Gigabit Ethernet
Databases
Information Collection
Remote Storage
Online Games
Commerce

The world is a large parallel system

Microprocessors in everything
Vast infrastructure behind them
Lec 1.6 8/30/10 Kubiatowicz CS162 UCB Fall 2010
People-to-Computer Ratio Over Time
Today: Multiple CPUs/person!
Approaching 100s?
From David Culler
Lec 1.7 8/30/10 Kubiatowicz CS162 UCB Fall 2010
1
10
100
1000
10000
1978 1980 1982 1984 1986 1988 1990 1992 1994 1996 1998 2000 2002 2004 2006
P
e
r
f
o
r
m
a
n
c
e

(
v
s
.

V
A
X
-
1
1
/
7
8
0
)
25%/year
52%/year
??%/year
New Challenge: Slowdown in Joys law of Performance
VAX : 25%/year 1978 to 1986
RISC + x86: 52%/year 1986 to 2002
RISC + x86: ??%/year 2002 to present
FromHennessy and Patterson, Computer Architecture: A
Quantitative Approach, 4th edition, Sept. 15, 2006
Sea change in chip
design: multiple cores or
processors per chip
3X
Lec 1.8 8/30/10 Kubiatowicz CS162 UCB Fall 2010
ManyCore Chips: The future is here
ManyCore refers to many processors/chip
64? 128? Hard to say exact boundary
How to program these?
Use 2 CPUs for video/audio
Use 1 for word processor, 1 for browser
76 for virus checking???
Parallelism must be exploited at all levels
Intel 80-core multicore chip (Feb 2007)
80 simple cores
Two FP-engines / core
Mesh-like network
100 million transistors
65nm feature size
Intel Single-Chip Cloud
Computer (August 2010)
24 tiles with two cores/tile
24-router mesh network
4 DDR3 memory controllers
Hardware support for message-passing
Lec 1.9 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Another Challenge: Power Density
Moores Law Extrapolation
Potential power density reaching amazing levels!
Flip side: Battery life very important
Moores law can yield more functionality at equivalent
(or less) total energy consumption
Lec 1.10 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Computer System Organization
Computer-system operation
One or more CPUs, device controllers connect
through common bus providing access to shared
memory
Concurrent execution of CPUs and devices
competing for memory cycles
Lec 1.11 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Functionality comes with great complexity!
Proc
Caches
Busses
Memory
I/O Devices:
Controllers
adapters
Disks
Displays
Keyboards
Networks
Pentium IV Chipset
Lec 1.12 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Sample of Computer Architecture Topics
Instruction Set Architecture
Pipelining, Hazard Resolution,
Superscalar, Reordering,
Prediction, Speculation,
Vector, Dynamic Compilation
Addressing,
Protection,
Exception Handling
L1 Cache
L2 Cache
DRAM
Disks, WORM, Tape
Coherence,
Bandwidth,
Latency
Emerging Technologies
Interleaving
Bus protocols
RAID
VLSI
Input/Output and Storage
Memory
Hierarchy
Pipelining and Instruction
Level Parallelism
Network
Communication
O
t
h
e
r

P
r
o
c
e
s
s
o
r
s
Lec 1.13 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Increasing Software Complexity
From MITs 6.033 course
Lec 1.14 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Example: Some Mars Rover (Pathfinder) Requirements
Pathfinder hardware limitations/complexity:
20Mhz processor, 128MB of DRAM, VxWorks OS
cameras, scientific instruments, batteries,
solar panels, and locomotion equipment
Many independent processes work together
Cant hit reset button very easily!
Must reboot itself if necessary
Must always be able to receive commands from Earth
Individual Programs must not interfere
Suppose the MUT (Martian Universal Translator Module) buggy
Better not crash antenna positioning software!
Further, all software may crash occasionally
Automatic restart with diagnostics sent to Earth
Periodic checkpoint of results saved?
Certain functions time critical:
Need to stop before hitting something
Must track orbit of Earth for communication
Lec 1.15 8/30/10 Kubiatowicz CS162 UCB Fall 2010
How do we tame complexity?
Every piece of computer hardware different
Different CPU
Pentium, PowerPC, ColdFire, ARM, MIPS
Different amounts of memory, disk,
Different types of devices
Mice, Keyboards, Sensors, Cameras, Fingerprint
readers
Different networking environment
Cable, DSL, Wireless, Firewalls,
Questions:
Does the programmer need to write a single program
that performs many independent activities?
Does every program have to be altered for every
piece of hardware?
Does a faulty program crash everything?
Does every program have access to all hardware?
Lec 1.16 8/30/10 Kubiatowicz CS162 UCB Fall 2010
OS Tool: Virtual Machine Abstraction
Software Engineering Problem:
Turn hardware/software quirks
what programmers want/need
Optimize for convenience, utilization, security,
reliability, etc
For Any OS area (e.g. file systems, virtual memory,
networking, scheduling):
Whats the hardware interface? (physical reality)
Whats the application interface? (nicer abstraction)
Application
Operating System
Hardware
Physical Machine Interface
Virtual Machine Interface
Lec 1.17 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Interfaces Provide Important Boundaries
Why do interfaces look the way that they do?
History, Functionality, Stupidity, Bugs, Management
CS152 Machine interface
CS160 Human interface
CS169 Software engineering/management
Should responsibilities be pushed across boundaries?
RISC architectures, Graphical Pipeline Architectures
instruction set
software
hardware
Lec 1.18 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Virtual Machines
Software emulation of an abstract machine
Make it look like hardware has features you want
Programs from one hardware & OS on another one
Programming simplicity
Each process thinks it has all memory/CPU time
Each process thinks it owns all devices
Different Devices appear to have same interface
Device Interfaces more powerful than raw hardware
Bitmapped display windowing system
Ethernet card reliable, ordered, networking (TCP/IP)
Fault Isolation
Processes unable to directly impact other processes
Bugs cannot crash whole machine
Protection and Portability
Java interface safe and stable across many platforms
Lec 1.19 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Virtual Machines (cont): Layers of OSs
Useful for OS development
When OS crashes, restricted to one VM
Can aid testing programs on other OSs
Lec 1.20 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Course Administration
Instructor: John Kubiatowicz ([email protected])
673 Soda Hall
Office Hours(Tentative): M/W 2:30pm-3:30pm
TAs: Angela C. Juang (cs162-ta@cory)
Christos Stergiou (cs162-tb@cory)
Hilfi Alkaff (cs162-tc@cory)
Labs: Second floor of Soda Hall
Website: http://inst.eecs.berkeley.edu/~cs162
Mirror: http://www.cs.berkeley.edu/~kubitron/cs162
Webcast: http://webcast.berkeley.edu/courses/index.php
Newsgroup: ucb.class.cs162 (use news.csua.berkeley.edu)
Course Email: [email protected]
Reader: TBA (Stay tuned!)
Lec 1.21 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Class Schedule
Class Time: M/W 4:00-5:30 PM, 277 Cory Hall
Please come to class. Lecture notes do not have everything
in them. The best part of class is the interaction!
Also: 10% of the grade is from class participation (section
and class)
Sections:
Important information is in the sections
The sections assigned to you by Telebears are temporary!
Every member of a project group must be in same section
No sections this week (obviously); start next week
Section Time Location TA
101 F 9:00A-10:00A 85 Evans Christos Stergiou
102 F 10:00A-11:00A 6 Evans Angela Juang
103 F 11:00A-12:00P 2 Evans Angela Juang
104 F 12:00P-1:00P 75 Evans Hilfi Alkaff
105 (New) F 1:00P-2:00P 85 Evans Christos Stergiou
Lec 1.22 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Textbook
Text: Operating Systems Concepts,
8
th
Edition Silbershatz, Galvin, Gagne
Online supplements
See Information link on course website
Includes Appendices, sample problems, etc
Question: need 8
th
edition?
No, but has new material that we may cover
Completely reorganized
Will try to give readings from both the 7
th
and 8
th
editions on the lecture page
Lec 1.23 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Topic Coverage
Textbook: Silberschatz, Galvin, and Gagne,
Operating Systems Concepts, 8
th
Ed., 2008
1 week: Fundamentals (Operating Systems Structures)
1.5 weeks: Process Control and Threads
2.5 weeks: Synchronization and scheduling
2 week: Protection, Address translation, Caching
1 week: Demand Paging
1 week: File Systems
2.5 weeks: Networking and Distributed Systems
1 week: Protection and Security
??: Advanced topics
Lec 1.24 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Grading
Rough Grade Breakdown
One Midterm: 20% each (Perhaps 2?)
One Final: 25%
Four Projects: 50% (i.e. 12.5% each)
Participation: 5%
Four Projects:
Phase I: Build a thread system
Phase II: Implement Multithreading
Phase III: Caching and Virtual Memory
Phase IV: Networking and Distributed Systems
Late Policy:
Each group has 5 slip days.
For Projects, slip days deducted from all partners
10% off per day after slip days exhausted
Lec 1.25 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Group Project Simulates Industrial Environment
Project teams have 4 or 5 members in same
discussion section
Must work in groups in the real world
Communicate with colleagues (team members)
Communication problems are natural
What have you done?
What answers you need from others?
You must document your work!!!
Everyone must keep an on-line notebook
Communicate with supervisor (TAs)
How is the teams plan?
Short progress reports are required:
What is the teams game plan?
What is each members responsibility?
Lec 1.26 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Typical Lecture Format
1-Minute Review
20-Minute Lecture
5- Minute Administrative Matters
25-Minute Lecture
5-Minute Break (water, stretch)
25-Minute Lecture
Instructor will come to class early & stay after to answer
questions
Attention
Time
20 min. Break In Conclusion, ... 25 min. Break 25 min.
Lec 1.27 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Lecture Goal
Interactive!!!
Lec 1.28 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Computing Facilities
Every student who is enrolled should get an
account form at end of lecture
Gives you an account of form cs162-xx@cory
This account is required
Most of your debugging can be done on other EECS
accounts, however
All of the final runs must be done on your cs162-xx
account and must run on the x86 Solaris machines
Make sure to log into your new account this week
and fill out the questions
Project Information:
See the Projects and Nachos link off the course
home page
Newsgroup (ucb.class.cs162):
Read this regularly!
Lec 1.29 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Academic Dishonesty Policy
Copying all or part of another person's work, or using reference
material not specifically allowed, are forms of cheating and will
not be tolerated. A student involved in an incident of cheating will
be notified by the instructor and the following policy will apply:
http://www.eecs.berkeley.edu/Policies/acad.dis.shtml
The instructor may take actions such as:
require repetition of the subject work,
assign an F grade or a 'zero' grade to the subject work,
for serious offenses, assign an F grade for the course.
The instructor must inform the student and the Department Chair
in writing of the incident, the action taken, if any, and the
student's right to appeal to the Chair of the Department
Grievance Committee or to the Director of the Office of Student
Conduct.
The Office of Student Conduct may choose to conduct a formal
hearing on the incident and to assess a penalty for misconduct.
The Department will recommend that students involved in a second
incident of cheating be dismissed from the University.
Lec 1.30 8/30/10 Kubiatowicz CS162 UCB Fall 2010
What does an Operating System do?
Silerschatz and Gavin:
An OS is Similar to a government
Begs the question: does a government do anything useful by
itself?
Coordinator and Traffic Cop:
Manages all resources
Settles conflicting requests for resources
Prevent errors and improper use of the computer
Facilitator:
Provides facilities that everyone needs
Standard Libraries, Windowing systems
Make application programming easier, faster, less error-prone
Some features reflect both tasks:
E.g. File system is needed by everyone (Facilitator)
But File system must be Protected (Traffic Cop)
Lec 1.31 8/30/10 Kubiatowicz CS162 UCB Fall 2010
What is an Operating System, Really?
Most Likely:
Memory Management
I/O Management
CPU Scheduling
Communications? (Does Email belong in OS?)
Multitasking/multiprogramming?
What about?
File System?
Multimedia Support?
User Interface?
Internet Browser?
Is this only interesting to Academics??
Lec 1.32 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Operating System Definition (Cont.)
No universally accepted definition
Everything a vendor ships when you order an
operating system is good approximation
But varies wildly
The one program running at all times on the
computer is the kernel.
Everything else is either a system program (ships
with the operating system) or an application
program
Lec 1.33 8/30/10 Kubiatowicz CS162 UCB Fall 2010
What if we didnt have an Operating System?
Source CodeCompilerObject CodeHardware
How do you get object code onto the hardware?
How do you print out the answer?
Once upon a time, had to Toggle in program in
binary and read out answer from LEDs!
Altair 8080
Lec 1.34 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Simple OS: What if only one application?
Examples:
Very early computers
Early PCs
Embedded controllers (elevators, cars, etc)
OS becomes just a library of standard services
Standard device drivers
Interrupt handlers
Math libraries
Lec 1.35 8/30/10 Kubiatowicz CS162 UCB Fall 2010
MS-DOS Layer Structure
Lec 1.36 8/30/10 Kubiatowicz CS162 UCB Fall 2010
More thoughts on Simple OS
What about Cell-phones, Xboxes, etc?
Is this organization enough?
What about an Android or iPhone phone?
Can OS be encoded in ROM/Flash ROM?
Does OS have to be software?
Can it be Hardware?
Custom Chip with predefined behavior
Are these even OSs?
Lec 1.37 8/30/10 Kubiatowicz CS162 UCB Fall 2010
More complex OS: Multiple Apps
Full Coordination and Protection
Manage interactions between different users
Multiple programs running simultaneously
Multiplex and protect Hardware Resources
CPU, Memory, I/O devices like disks, printers, etc
Facilitator
Still provides Standard libraries, facilities
Would this complexity make sense if there were
only one application that you cared about?
Lec 1.38 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Example: Protecting Processes from Each Other
Problem: Run multiple applications in such a way
that they are protected from one another
Goal:
Keep User Programs from Crashing OS
Keep User Programs from Crashing each other
[Keep Parts of OS from crashing other parts?]
(Some of the required) Mechanisms:
Address Translation
Dual Mode Operation
Simple Policy:
Programs are not allowed to read/write memory of
other Programs or of Operating System
Lec 1.39 8/30/10 Kubiatowicz CS162 UCB Fall 2010
CPU MMU
Virtual
Addresses
Physical
Addresses
Address Translation
Address Space
A group of memory addresses usable by something
Each program (process) and kernel has potentially
different address spaces.
Address Translation:
Translate from Virtual Addresses (emitted by CPU)
into Physical Addresses (of memory)
Mapping often performed in Hardware by Memory
Management Unit (MMU)
Lec 1.40 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Example of Address Translation
Prog 1
Virtual
Address
Space 1
Prog 2
Virtual
Address
Space 2
Code
Data
Heap
Stack
Code
Data
Heap
Stack
Data 2
Stack 1
Heap 1
OS heap &
Stacks
Code 1
Stack 2
Data 1
Heap 2
Code 2
OS code
OS data
Translation Map 1 Translation Map 2
Physical Address Space
Lec 1.41 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Address Translation Details
For now, assume translation happens with table
(called a Page Table):
Translation helps protection:
Control translations, control access
Should Users be able to change Page Table???
Virtual
Address
Page Table
index
into
page
table
V
Access
Rights
PA
V page no. offset
10
table located
in physical
memory
P page no. offset
10
Physical
Address
Lec 1.42 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Dual Mode Operation
Hardware provides at least two modes:
Kernel mode (or supervisor or protected)
User mode: Normal programs executed
Some instructions/ops prohibited in user mode:
Example: cannot modify page tables in user mode
Attempt to modify Exception generated
Transitions from user mode to kernel mode:
System Calls, Interrupts, Other exceptions
Lec 1.43 8/30/10 Kubiatowicz CS162 UCB Fall 2010
UNIX System Structure
User Mode
Kernel Mode
Hardware
Applications
Standard Libs
Lec 1.44 8/30/10 Kubiatowicz CS162 UCB Fall 2010
New Structures for Multicore chips?
Tessellation: The Exploded OS
Normal Components split
into pieces
Device drivers
(Security/Reliability)
Network Services
(Performance)
TCP/IP stack
Firewall
Virus Checking
Intrusion Detection
Persistent Storage
(Performance,
Security, Reliability)
Monitoring services
Performance counters
Introspection
Identity/Environment
services (Security)
Biometric, GPS,
Possession Tracking
Applications Given
Larger Partitions
Freedom to use
resources arbitrarily
Device
Drivers
Video &
Window
Drivers
Firewall
Virus
Intrusion
Monitor
And
Adapt
Persistent
Storage &
File System
HCI/
Voice
Rec
Large Compute-Bound
Application
Real-Time
Application
I
d
e
n
t
i
t
y
Lec 1.45 8/30/10 Kubiatowicz CS162 UCB Fall 2010
OS Systems Principles
OS as illusionist:
Make hardware limitations go away
Provide illusion of dedicated machine with infinite
memory and infinite processors
OS as government:
Protect users from each other
Allocate resources efficiently and fairly
OS as complex system:
Constant tension between simplicity and
functionality or performance
OS as history teacher
Learn from past
Adapt as hardware tradeoffs change
Lec 1.46 8/30/10 Kubiatowicz CS162 UCB Fall 2010
Why Study Operating Systems?
Learn how to build complex systems:
How can you manage complexity for future projects?
Engineering issues:
Why is the web so slow sometimes? Can you fix it?
What features should be in the next mars Rover?
How do large distributed systems work? (Kazaa, etc)
Buying and using a personal computer:
Why different PCs with same CPU behave differently
How to choose a processor (Opteron, Itanium, Celeron,
Pentium, Hexium)? [ Ok, made last one up ]
Should you get Windows XP, 2000, Linux, Mac OS ?
Why does Microsoft have such a bad name?
Business issues:
Should your division buy thin-clients vs PC?
Security, viruses, and worms
What exposure do you have to worry about?
Lec 1.47 8/30/10 Kubiatowicz CS162 UCB Fall 2010
In conclusion
Operating systems provide a virtual machine
abstraction to handle diverse hardware
Operating systems coordinate resources and
protect users from each other
Operating systems simplify application
development by providing standard services
Operating systems can provide an array of fault
containment, fault tolerance, and fault recovery
CS162 combines things from many other areas of
computer science
Languages, data structures, hardware, and
algorithms