CMSC 412 Operating Systems Fall 2002 Liviu Iftode iftode@cs.umd.edu University of Maryland, CMSC 412, Fall 2002 1 Course overview Goals Understand how an operating system works as a mediator between the computer architecture and user programs 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 University of Maryland, CMSC 412, Fall 2002 2 OS Learning project OS Concepts (lectures, textbooks) OS Implementation (source code, project doc) recitations Real OS homeworks (Unix/Linux textbooks) OS Programming (man pages) University of Maryland, CMSC 412, Fall 2002 3 Course Timeline Lecture Concept A Concept B Tu Tu Th Concept C Th Tu Apply A Th Apply B Apply C Lab W W W HW A Due HW BC Due Homework W W Project AB Due Project W University of Maryland, CMSC 412, Fall 2002 4 Suggested Approach Read the assigned chapter from the textbook before the lecture to understand the basic idea and become familiar with the terminology Attend the recitation Start homeworks and project right away, systems programming is not easy ! Ask questions during lecture, recitation. Use the mailing list/newsgroup for discussions, 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. Do not forget, questions and discussions are not graded ! University of Maryland, CMSC 412, Fall 2002 5 Course Outline Processes and process management Threads and thread programming Synchronization and Deadlock Memory management and Virtual Memory CPU Scheduling File systems and I/O Management Networking and Distributed Systems Security University of Maryland, CMSC 412, Fall 2002 6 Course requirements Prerequisites computer architecture good programming skills (C!!, C++, Java) Expected work substantial readings (textbooks and papers) challenging project extended over the entire semester homeworks (require programming) midterm and final exams University of Maryland, CMSC 412, Fall 2002 7 Work Evaluation midterm exam 25% homework 25% project 25% final exam 25% University of Maryland, CMSC 412, Fall 2002 8 Homeworks Goals Deepen the understanding of OS concepts Develop systems programming skills: virtual memory, threads, synchronization, sockets Learn to design, implement, debug and evaluate the performance of an OS-bound program Structure 4-5 homeworks Both theoretical and C-programming problems University of Maryland, CMSC 412, Fall 2002 9 Project Goals learn to design, implement and evaluate basic OS mechanisms and policies Structure individual project multiple phases project report for each phase University of Maryland, CMSC 412, Fall 2002 10 Textbooks Stallings Operating Systems. Internals and Design Principles, 4th Edition, Prentice-Hall, 2001. Silberschatz, Galvin and Gagne, Operating System Concepts, 6th Edition, John Wiley & Sons, 2001. Papers will be made available on the course homepage University of Maryland, CMSC 412, Fall 2002 11 Logistics TAs: Chunyuan Liao Iulian Neamtiu (to be confirmed) Course homepage: http://www.cs.umd.edu/~iftode/cs412/cs412syllabus.htm Preliminary schedule and course notes are already available for the entire semester but they may be updated before each class. Homeworks every other week. A project phase every other week. A mailing list/newsgroup will be announced shortly. University of Maryland, CMSC 412, Fall 2002 12 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 and safe a resource manager that allows programs/users to share the hardware resources: fair and efficient University of Maryland, CMSC 412, Fall 2002 13 How does an OS work application (user) system calls upcalls commands interrupts hardware independent OS 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 University of Maryland, CMSC 412, Fall 2002 14 Files A file is a storage abstraction application/user: copy file1 file2 operating system: files, directories hardware: disk naming, protection, operations on files operations on disk blocks... traditional approach: OS does disk block allocation and caching (buffer cache) , disk operation scheduling and replacement in the buffer cache new approaches: application-controlled cache replacement, log-based allocation (makes writes fast) University of Maryland, CMSC 412, Fall 2002 15 Traditional file system application: read/write files translate file to disk blocks OS: maintains ...buffer cache ... controls disk accesses: read/write blocks hardware: University of Maryland, CMSC 412, Fall 2002 16 Mechanism vs Policy application (user) operating system: mechanism+policy hardware mechanism: data structures and operations that implement the abstraction (e.g. the buffer cache) policy: the procedure that guides 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 University of Maryland, CMSC 412, Fall 2002 17 Mechanism-policy split traditional OS cannot provide the best policy in all cases new OS approaches separate mechanisms from policies: OS provides the mechanism + some policy applications contribute to the policy flexibility+efficiency require new OS structures and/or new OS interfaces University of Maryland, CMSC 412, Fall 2002 18 Application-controlled caching application: read/write files replacement policy translate file to disk blocks OS: maintains ...buffer cache ... controls disk accesses: read/write blocks hardware: University of Maryland, CMSC 412, Fall 2002 19 Processes A process is a processor abstraction user: run application operating system: processes create, kill processes, inter-process comm context switch hardware: processor traditional approach: OS switches processes on the processor (process scheduling), provides inter-process communication and handles exceptions new approaches: application-controlled scheduling, reservation-based scheduling, agile applications University of Maryland, CMSC 412, Fall 2002 20 Traditional approach active processes IPC OS processor OS mediates inter-process communication (IPC) OS schedules processes on the processor application provides hints: priorities University of Maryland, CMSC 412, Fall 2002 21 Hierarchical scheduling processes schedulers OS processor OS schedules schedulers which schedule dependent processes University of Maryland, CMSC 412, Fall 2002 22 Virtual memory Virtual memory is a memory abstraction application: address space virtual addresses operating system: virtual memory physical addresses hardware: physical memory traditional approach: OS provides a sufficiently large virtual address space for each running application, does memory allocation and replacement and may ensure protection new approaches: external memory management, huge (64bit) address space, global memory University of Maryland, CMSC 412, Fall 2002 23 VM: mechanism and policy virtual address spaces p1 p2 processes: v-to-p memory mappings physical memory: processes can run being partially loaded in memory illusion of more memory than physically available: swapping processes can share physical memory if permitted replacement policy can be exposed to the application University of Maryland, CMSC 412, Fall 2002 24 Communication Message passing is a communication abstraction application: sockets naming, messages operating system: TCP/IP protocols network packets hardware: network interface traditional approach: OS provides naming schemes, reliable transport of messages, packet routing to destination new approaches: zero-copy protocols, active messages, memory-mapped communication University of Maryland, CMSC 412, Fall 2002 25 Traditional OS structure monolithic/layered systems one/N layers all executed in “kernel-mode” good performance but rigid user user process system calls OS kernel file system memory system hardware University of Maryland, CMSC 412, Fall 2002 26 Micro-kernel OS client process user mode micro-kernel file server memory server IPC 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 University of Maryland, CMSC 412, Fall 2002 27 Extensible OS kernel process process my memory service default memory service user mode extensible kernel hardware user processes can load customized OS services into the kernel good performance but protection and scalability become problems University of Maryland, CMSC 412, Fall 2002 28 Virtual Machines old concept which is heavily revived today the real hardware in “cloned” in several identical virtual machines OS functionality built on top of the virtual machine user OS on virtual machine allocate resource exokernel hardware University of Maryland, CMSC 412, Fall 2002 29 Computer System Processor: performs data processing Main memory: stores both data and programs, typically volatile Disks: secondary memory devices which provide persistent storage Network interfaces: inter-machine communication Buses: intra-machine communication memory bus (processor-memory) I/O bus (disks, network interfaces, other I/O devices, memory-bus) University of Maryland, CMSC 412, Fall 2002 30 Basic computer structure CPU Memory memory bus I/O bus disk Net interface University of Maryland, CMSC 412, Fall 2002 31 Memory 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 which 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 which are close to locations which were recently accessed (spatial locality) University of Maryland, CMSC 412, Fall 2002 32 Cache design issues cpu word transfer cache block transfer main memory cache size and cache block size mapping: physical/virtual caches, associativity replacement algorithm: LRU write policy: write through/write back University of Maryland, CMSC 412, Fall 2002 33 Memory Hierarchy cpu word transfer cache block transfer main memory page transfer disks decrease cost per bit decrease frequency of access increase capacity increase access time increase size of transfer unit University of Maryland, CMSC 412, Fall 2002 34 Data transfer on the bus CPU cache Memory memory bus I/O bus disk Net interface cache-memory: cache misses, write-through/write-back memory-disk: swapping, paging, file accesses memory-Network Interface : packet send/receive I/O devices to the processor: interrupts University of Maryland, CMSC 412, Fall 2002 35 Direct Memory Access (DMA) bulk data transfer between memory and an I/O device (disk, network interface) initiated by the processor address of the I/O device starting location in memory number of bytes direction of transfer (read/write from/to memory) processor interrupted when the operation completes bus arbitration between cache-memory and DMA transfers memory cache must be consistent with DMA University of Maryland, CMSC 412, Fall 2002 36 Multiprocessors CPU cache CPU cache Memory memory bus I/O bus disk Net interface simple scheme: more than one processor on the same bus memory is shared among processors-- cache consistency bus contention increases -- does not scale alternative (non-bus) system interconnect -- expensive single-image operating systems University of Maryland, CMSC 412, Fall 2002 37 Multicomputers CPU cache CPU cache Memory Memory memory bus memory bus I/O bus I/O bus network disk Net interface Net interface disk network of computers: “share-nothing” -- cheap communication through message-passing: difficult to program challenge: build efficient shared memory abstraction in software each system runs its own operating system University of Maryland, CMSC 412, Fall 2002 38