U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science Emery Berger University of Massachusetts, Amherst Operating Systems CMPSCI 377 Lecture 2: OS & Architecture

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 2 Last Class: Introduction Operating system = interface between user & architecture OS history: Change is only constant User-level Applications Operating System Hardware virtual machine interface physical machine interface

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 3 Today: OS & Computer Architecture Modern OS Functionality (brief review) Architecture Basics Hardware Support for OS Features

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 4 Modern OS Functionality Provides support for: Concurrency I/O Device Management Memory Management Files Distributed Systems & Networks

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 5 Concurrency Supports multiple activities, apparently occurring simultaneously Multiple users: Several users work as if each has private machine Multiple processes/threads: One on CPU at a time Multiple active concurrently

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 6 Modern OS Functionality, Cont. I/O CPU works while waiting on slow I/O devices Memory Management Coordinates allocation of RAM Moves data between disk & main memory Files Coordinates how disk space is used Distributed Systems & Networks Lets group of PC’s to work together on distributed h/w

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 7 Operating Systems = Governments Close analogy of operating systems to utopian political systems Libertarianism Socialism Communism

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 8 OS as Utopian Governments Libertarianism: Infinite RAM, CPU Protects users from each other

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 9 OS as Utopian Governments Socialism: Safe & secure communication Protects everyone Fair allocation of resources

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 10 OS as Utopian Governments Communism: To each according to his needs Centralized control Allocates resources efficiently (in theory…) Impossible or too slow without hardware support

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 11 Canonical System Hardware CPU: Processor to perform actual computations I/O devices: terminal, disks, video, printer… Memory: data & programs System Bus: Communication channel between above

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 12 Services & Hardware Support OS ServiceHardware Support ProtectionKernel/User Mode Protected Instructions Base & Limit Registers InterruptsInterrupt Vectors System CallsTrap Instructions I/OInterrupts, Memory-Mapping SynchronizationAtomic Instructions Virtual MemoryTranslation Lookaside Buffers SchedulingTimer

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 13 Protection OS protects users from each other Users cannot read or write other user’s memory Name OS’s that do and don’t do this! Protects self from users Safe from errant or malicious users Privileged instructions (e.g., halt machine) Code & data protected

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 14 Kernel Mode: Privileged Instructions CPU provides “kernel” mode restricted to OS Inaccessible to ordinary users Kernel = core of operating system Privileged instructions & registers: Direct access to I/O Modify page table pointers, TLB Enable & disable interrupts Halt the machine, etc. Indicated by status bit in protected CPU register

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 15 Protecting Memory: Base and Limit Registers Hardware support to protect memory regions Loaded by OS before starting program CPU checks each reference Instruction & data addresses Ensures reference in range

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 16 Hardware Support OS ServiceHardware Support ProtectionKernel/User Mode Protected Instructions Base & Limit Registers InterruptsInterrupt Vectors System CallsTrap Instructions I/OInterrupts, Memory-Mapping SynchronizationAtomic Instructions Virtual MemoryTranslation Lookaside Buffers SchedulingTimer

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 17 Interrupts Polling = “are we there yet?” “no!” (repeat…) Inefficient use of resources Annoys the CPU Interrupt = silence, then: “we’re there” I/O device has own processor When finished, device sends interrupt on bus CPU “handles” interrupt

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 18 CPU Interrupt Handling Handling interrupts: relatively expensive CPU must: Save hardware state Registers, program counter Disable interrupts (why?) Invoke via in-memory interrupt vector (like trap vector, soon) Enable interrupts Restore hardware state Continue execution of interrupted process

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 19 Hardware Support OS ServiceHardware Support ProtectionKernel/User Mode Protected Instructions Base & Limit Registers InterruptsInterrupt Vectors System CallsTrap Instructions I/OInterrupts, Memory-Mapping SynchronizationAtomic Instructions Virtual MemoryTranslation Lookaside Buffers SchedulingTimer

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 20 Traps Special conditions detected by architecture E.g.: page fault, write to read-only page, overflow, system call On detecting trap, hardware must: Save process state (PC, stack, etc.) Transfer control to trap handler (in OS) CPU indexes trap vector by trap number Jumps to address Restore process state and resume

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 21 Memory Traps Special case: trigger trap on write to protected memory area Widely used in operating systems: Debugging Distributed virtual memory Approximating LRU Garbage collection Copy-on-write Pay performance penalty only when needed

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 22 Hardware Support OS ServiceHardware Support ProtectionKernel/User Mode Protected Instructions Base & Limit Registers InterruptsInterrupt Vectors System CallsTrap Instructions I/OInterrupts, Memory-Mapping SynchronizationAtomic Instructions Virtual MemoryTranslation Lookaside Buffers SchedulingTimer

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 23 Memory-Mapped I/O Direct access to I/O controller through memory Reserve area of memory for communication with device (“DMA”) Video RAM: CPU writes frame buffer Video card displays it Fast and convenient

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 24 Hardware Support OS ServiceHardware Support ProtectionKernel/User Mode Protected Instructions Base & Limit Registers InterruptsInterrupt Vectors System CallsTrap Instructions I/OInterrupts, Memory-Mapping SynchronizationAtomic Instructions Virtual MemoryTranslation Lookaside Buffers SchedulingTimer

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 25 Synchronization How can OS synchronize concurrent processes? E.g., multiple threads, processes & interrupts, DMA CPU must provide mechanism for atomicity Series of instructions that execute as one or not at all

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 26 Synchronization: How-To One approach: Disable interrupts Perform action Enable interrupts Advantages: Requires no hardware support Conceptually simple Disadvantages: Could cause starvation

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 27 Synchronization: How-To, II Modern approach: atomic instructions Small set of instructions that cannot be interrupted Examples: Test-and-set (“TST”) if word contains given value, set to new value Compare-and-swap (“CAS”) if word equals value, swap old value with new Intel: LOCK prefix (XCHG, ADD, DEC, etc.) Used to implement locks

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 28 Hardware Support OS ServiceHardware Support ProtectionKernel/User Mode Protected Instructions Base & Limit Registers InterruptsInterrupt Vectors System CallsTrap Instructions I/OInterrupts, Memory-Mapping SynchronizationAtomic Instructions Virtual MemoryTranslation Lookaside Buffers SchedulingTimer

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 29 Virtual Memory Provides illusion of complete access to RAM All addresses translated from physical addresses into virtual addresses OS loads pages from disk as needed Keeps track of which pages are in memory (“in core”) and which are on disk Many benefits, including: Allows users to run programs without loading entire program into RAM May not fit in entirety (think MS Office)

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 30 Translation Lookaside Buffer First virtual memory systems performed address translation in software On every memory access! (s..l..o..w..) Modern CPUs contain hardware to do this: the TLB Hash-based scheme Maps virtual addresses to physical addresses Fast, fully-associative cache Today’s workloads are often “TLB-miss dominated”

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 31 Hardware Support OS ServiceHardware Support ProtectionKernel/User Mode Protected Instructions Base & Limit Registers InterruptsInterrupt Vectors System CallsTrap Instructions I/OInterrupts, Memory-Mapping SynchronizationAtomic Instructions Virtual MemoryTranslation Lookaside Buffers SchedulingTimer

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 32 Scheduling & Timers OS needs timers for: Time of day CPU scheduling Fairness: limited quantum (e.g., 100ms) for each task When quantum expires, switch processes Uses interrupt vector

U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 33 Summary OS relies on hardware for many services Protection Interrupts System Calls Synchronization Virtual memory Timers Otherwise impossible or impractically slow in software