DOC PREVIEW
Berkeley COMPSCI 162 - Lecture Notes

This preview shows page 1-2-3-4-5 out of 15 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

CS162Operating Systems andSystems ProgrammingLecture 2History of the World Parts 1—5 Operating Systems StructuresSeptember 3rd, 2008Prof. John Kubiatowiczhttp://inst.eecs.berkeley.edu/~cs162Lec 2.29/03/08 Kubiatowicz CS162 ©UCB Fall 2008Review: 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):– What’s the hardware interface? (physical reality)– What’s the application interface? (nicer abstraction)ApplicationOperating SystemHardwarePhysical Machine InterfaceVirtual Machine InterfaceLec 2.39/03/08 Kubiatowicz CS162 ©UCB Fall 2008Goals for Today• Finish Protection Example• History of Operating Systems– Really a history of resource-driven choices• Operating Systems Structures• Operating Systems Organizations• Abstractions and layeringNote: Some slides and/or pictures in the following areadapted from slides ©2005 Silberschatz, Galvin, and Gagne Note: Some slides and/or pictures in the following areadapted from slides ©2005 Silberschatz, Galvin, and Gagne. Many slides generated from lecture notes by Joseph.Lec 2.49/03/08 Kubiatowicz CS162 ©UCB Fall 2008Example: 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 SystemLec 2.59/03/08 Kubiatowicz CS162 ©UCB Fall 2008CPUMMUVirtualAddressesPhysicalAddressesExample: 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 2.69/03/08 Kubiatowicz CS162 ©UCB Fall 2008Example: Example of Address TranslationProg 1VirtualAddressSpace 1Prog 2VirtualAddressSpace 2CodeDataHeapStackCodeDataHeapStackData 2Stack 1Heap 1OS heap & StacksCode 1Stack 2Data 1Heap 2Code 2OS codeOS dataTranslation Map 1 Translation Map 2Physical Address SpaceLec 2.79/03/08 Kubiatowicz CS162 ©UCB Fall 2008Example: 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 exceptionsLec 2.89/03/08 Kubiatowicz CS162 ©UCB Fall 2008UNIX System StructureUser ModeKernel ModeHardwareApplicationsStandard LibsLec 2.99/03/08 Kubiatowicz CS162 ©UCB Fall 2008Moore’s Law Change Drives OS ChangeTypical academic computer 1981 vs 20060.2$4,000$25,000≤ 0.1≤ 110s23216110,0001 Gb/s9600 b/s100,0001TB10MB32,7684GB128KB1,2806—40 3200x40.25—0.5103—10 Factor20061981Price#users/machine# addr bitsNet bandwidthDisk capacityDRAM capacityCPU MHz,Cycles/instLec 2.109/03/08 Kubiatowicz CS162 ©UCB Fall 2008Moore’s law effects• Nothing like this in any other area of business• Transportation in over 200 years: – 2 orders of magnitude from horseback @10mph to Concorde @1000mph– Computers do this every decade (at least until 2002)!• What does this mean for us?– Techniques have to vary over time to adapt to changing tradeoffs• I place a lot more emphasis on principles– The key concepts underlying computer systems– Less emphasis on facts that are likely to change over the next few years…• Let’s examine the way changes in $/MIP has radically changed how OS’s workLec 2.119/03/08 Kubiatowicz CS162 ©UCB Fall 2008Dawn of timeENIAC: (1945—1955)• “The machine designed by Drs. Eckert and Mauchlywas a monstrosity. When it was finished, the ENIAC filled an entire room, weighed thirty tons, and consumed two hundred kilowatts of power.”• http://ei.cs.vt.edu/~history/ENIAC.Richey.HTMLLec 2.129/03/08 Kubiatowicz CS162 ©UCB Fall 2008History Phase 1 (1948—1970)Hardware Expensive, Humans Cheap• When computers cost millions of $’s, optimize for more efficient use of the hardware!– Lack of interaction between user and computer• User at console: one user at a time• Batch monitor: load program, run, print• Optimize to better use hardware– When user thinking at console, computer idle⇒BAD!– Feed computer batches and make users wait – Autograder for this course is similar•No protection:what if batch program has bug?Lec 2.139/03/08 Kubiatowicz CS162 ©UCB Fall 2008Core Memories (1950s & 60s)• Core Memory stored data as magnetization in iron rings– Iron “cores” woven into a 2-dimensional mesh of wires– Origin of the term “Dump Core”– Rumor that IBM consulted Life Saver company• See: http://www.columbia.edu/acis/history/core.htmlThe first magnetic core memory, from the IBM 405 Alphabetical Accounting Machine. Lec 2.149/03/08 Kubiatowicz CS162 ©UCB Fall 2008History Phase 1½ (late 60s/early 70s)• Data channels, Interrupts: overlap I/O and compute– DMA – Direct Memory Access for I/O devices– I/O can be completed asynchronously• Multiprogramming: several programs run simultaneously– Small jobs not delayed by large jobs– More overlap between I/O and CPU– Need memory protection between programs and/or OS• Complexity gets out of hand:– Multics: announced in 1963, ran in 1969» 1777 people “contributed to Multics” (30-40 core dev)» Turing award lecture from Fernando Corbató (key researcher): “On building systems that will fail”– OS 360: released with 1000 known bugs (APARs)» “Anomalous Program Activity Report”• OS finally becomes an important science:– How to deal with complexity???– UNIX based on Multics, but vastly simplifiedLec 2.159/03/08 Kubiatowicz CS162 ©UCB Fall 2008A Multics System (Circa 1976)• The 6180 at MIT IPC, skin doors open, circa 1976:– “We usually ran the machine with doors open so the operators could see


View Full Document

Berkeley COMPSCI 162 - Lecture Notes

Documents in this Course
Lecture 1

Lecture 1

12 pages

Nachos

Nachos

41 pages

Security

Security

39 pages

Load more
Download Lecture Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?