1 / 33

Operating Systems CMPSCI 377 Lecture 2: OS & Architecture

Operating Systems CMPSCI 377 Lecture 2: OS & Architecture. Emery Berger University of Massachusetts, Amherst. Last Class: Introduction. Operating system = interface between user & architecture OS history: Change is only constant. User-level Applications. virtual machine interface.

kasperj
Download Presentation

Operating Systems CMPSCI 377 Lecture 2: OS & Architecture

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Operating SystemsCMPSCI 377Lecture 2: OS & Architecture Emery Berger University of Massachusetts, Amherst

  2. Last Class: Introduction • Operating system =interface between user & architecture • OS history:Change is only constant User-level Applications virtual machine interface Operating System physical machine interface Hardware

  3. Today:OS & Computer Architecture • Modern OS Functionality (brief review) • Architecture Basics • Hardware Support for OS Features

  4. Modern OS Functionality • Provides support for: • Concurrency • I/O Device Management • Memory Management • Files • Distributed Systems & Networks

  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

  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

  7. Operating Systems = Governments • Close analogy of operating systemsto utopian political systems • Libertarianism • Socialism • Communism

  8. OS as Utopian Governments • Libertarianism: • Infinite RAM, CPU • Protects users from each other

  9. OS as Utopian Governments • Socialism: • Safe & secure communication • Protects everyone • Fair allocation of resources

  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

  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

  12. Services & Hardware Support

  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

  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

  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

  16. Hardware Support

  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

  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

  19. Hardware Support

  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

  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

  22. Hardware Support

  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

  24. Hardware Support

  25. Synchronization • How can OS synchronize concurrent processes? • E.g., multiple threads, processes & interrupts, DMA • CPU must providemechanism for atomicity • Series of instructions that execute as one or not at all

  26. Synchronization: How-To • One approach: • Disable interrupts • Perform action • Enable interrupts • Advantages: • Requires no hardware support • Conceptually simple • Disadvantages: • Could cause starvation

  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

  28. Hardware Support

  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)

  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”

  31. Hardware Support

  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

  33. Summary • OS relies on hardware for many services • Protection • Interrupts • System Calls • Synchronization • Virtual memory • Timers • Otherwise impossible or impractically slow in software

More Related