prez4_operacni_systemy principles and fundamentals
- 1. Operating Systems: Principles and Practice Original slides by: Tom Anderson https://homes.cs.washington.edu/~tom/Slides/slides.html
- 3. What is an operating system? • Software to manage a computer’s resources for its users and applications
- 4. Operating System Roles • Referee: – Resource allocation among users, applications – Isolation of different users, applications from each other – Communication between users, applications • Illusionist – Each application appears to have the entire machine to itself – Infinite number of processors, (near) infinite amount of memory, reliable storage, reliable network transport • Glue – Libraries, user interface widgets, …
- 5. Example: File Systems • Referee – Prevent users from accessing each other’s files without permission – Even after a file is deleting and its space re-used • Illusionist – Files can grow (nearly) arbitrarily large – Files persist even when the machine crashes in the middle of a save • Glue – Named directories, printf, …
- 6. Question • What (hardware, software) do you need to be able to run an untrustworthy application? – Memory protection – Interrupt running application – Privileged mode (OS)
- 7. Question • How should an operating system allocate processing time between competing uses? – Give the CPU to the first to arrive? – To the one that needs the least resources to complete? To the one that needs the most resources?
- 8. OS Challenges • Reliability – Does the system do what it was designed to do? • Availability – What portion of the time is the system working? – Mean Time To Failure (MTTF), Mean Time to Repair • Security – Can the system be compromised by an attacker? • Privacy – Data is accessible only to authorized users
- 9. OS Challenges • Portability – For programs: • Application programming interface (API) • Abstract virtual machine (AVM) – For the operating system • Hardware abstraction layer
- 10. OS Challenges • Performance – Latency/response time • How long does an operation take to complete? – Throughput • How many operations can be done per unit of time? – Overhead • How much extra work is done by the OS? – Fairness • How equal is the performance received by different users? – Predictability • How consistent is the performance over time?
- 11. Early Operating Systems: Computers Very Expensive • One application at a time – Had complete control of hardware – OS was runtime library – Users would stand in line to use the computer • Batch systems – Keep CPU busy by having a queue of jobs – OS would load next job while current one runs – Users would submit jobs, and wait, and wait, and
- 12. Time-Sharing Operating Systems: Computers and People Expensive • Multiple users on computer at same time – Multiprogramming: run multiple programs at same time – Interactive performance: try to complete everyone’s tasks quickly – As computers became cheaper, more important to optimize for user time, not computer time
- 14. Challenge: Protection • How do we execute code with restricted privileges? – Either because the code is buggy or if it might be malicious • Some examples: – A script running in a web browser – A program you just downloaded off the Internet – A program you just wrote that you haven’t tested yet
- 15. A Problem
- 16. Main Points • Process concept – A process is the OS abstraction for executing a program with limited privileges • Dual-mode operation: user vs. kernel – Kernel-mode: execute with complete privileges – User-mode: execute with fewer privileges • Safe control transfer – How do we switch from one mode to the other?
- 17. Process Abstraction • Process: an instance of a program, running with limited rights – Thread: a sequence of instructions within a process • Potentially many threads per process (for now 1:1) – Address space: set of rights of a process • Memory that the process can access • Other permissions the process has (e.g., which system calls it can make, what files it can access)
- 18. Thought Experiment • How can we implement execution with limited privilege? – Execute each program instruction in a simulator – If the instruction is permitted, do the instruction – Otherwise, stop the process – Basic model in Javascript and other interpreted languages • How do we go faster? – Run the unprivileged code directly on the CPU!
- 19. Hardware Support: Dual-Mode Operation • Kernel mode – Execution with the full privileges of the hardware – Read/write to any memory, access any I/O device, read/write any disk sector, send/read any packet • User mode – Limited privileges – Only those granted by the operating system kernel • On the x86, mode stored in EFLAGS register • On the MIPS, mode in the status register
- 20. A Model of a CPU
- 21. A CPU with Dual-Mode Operation
- 22. Hardware Support: Dual-Mode Operation • Privileged instructions – Available to kernel – Not available to user code • Limits on memory accesses – To prevent user code from overwriting the kernel • Timer – To regain control from a user program in a loop • Safe way to switch from user mode to kernel mode, and vice versa
- 24. Privileged instructions • Examples? – Change mode bit in EFLAGs register! – Change which memory locations a user program can access – Send commands to I/O devices – Read data from/write data to I/O devices – Jump into kernel code
- 25. Mode Switch • From user mode to kernel mode – Interrupts • Triggered by timer and I/O devices – Exceptions • Triggered by unexpected program behavior • Or malicious behavior! – System calls (aka protected procedure call) • Request by program for kernel to do some operation on its behalf • Only limited # of very carefully coded entry points
- 26. Device Interrupts • OS kernel needs to communicate with physical devices • Devices operate asynchronously from the CPU – Polling: Kernel waits until I/O is done – Interrupts: Kernel can do other work in the meantime • Device access to memory – Programmed I/O: CPU reads and writes to device – Direct memory access (DMA) by device – Buffer descriptor: sequence of DMA’s • E.g., packet header and packet body – Queue of buffer descriptors • Buffer descriptor itself is DMA’ed
- 27. System Calls • Creating and managing processes – fork, exec, wait • Performing I/O – open, read, write, close • Communicating between processes – pipe, dup, select, connect
- 28. Mode Switch • From kernel mode to user mode – New process/new thread start • Jump to first instruction in program/thread – Return from interrupt, exception, system call • Resume suspended execution – Process/thread context switch • Resume some other process – User-level upcall (UNIX signal) • Asynchronous notification to user program
- 29. How do we take interrupts safely? • Interrupt vector – Limited number of entry points into kernel • Atomic transfer of control – Single instruction to change: • Program counter • Stack pointer • Memory protection • Kernel/user mode • Transparent restartable execution – User program does not know interrupt occurred
- 30. Interrupt Vector • Table set up by OS kernel; pointers to code to run on different events
- 31. Concurrency
- 32. Motivation • Operating systems (and application programs) often need to be able to handle multiple things happening at the same time – Process execution, interrupts, background tasks, system maintenance • Humans are not very good at keeping track of multiple things happening simultaneously • Threads are an abstraction to help bridge this gap
- 33. Definitions • A thread is a single execution sequence that represents a separately schedulable task – Single execution sequence: familiar programming model – Separately schedulable: OS can run or suspend a thread at any time • Protection is an orthogonal concept – Can have one or many threads per protection domain
- 34. How? • Queue of threads ready to execute – Schedueler select one of them and let it run on processor for a certain time, then switch another – Which one to select? Good question:-) • Responsiveness, throughput, efficiency requirements • Requirements may differ (realtime / batch / interactive) • Priorities (static / dynamic) • Fair share, shortest job first, Round robin,…
- 35. Thread Abstraction • Infinite number of processors • Threads execute with variable speed – Programs must be designed to work with any schedule
- 37. Thread Lifecycle
- 38. Synchronization
- 39. Synchronization Motivation • When threads concurrently read/write shared memory, program behavior is undefined – Two threads write to the same variable; which one should win? • Thread schedule is non-deterministic – Behavior changes when re-run program • Compiler/hardware instruction reordering • Multi-word operations are not atomic
- 40. Too Much Milk Example Person A Person B 12:30 Look in fridge. Out of milk. 12:35 Leave for store. 12:40 Arrive at store. Look in fridge. Out of milk. 12:45 Buy milk. Leave for store. 12:50 Arrive home, put milk away. Arrive at store. 12:55 Buy milk. 1:00 Arrive home, put milk away. Oh no!
- 41. Definitions Race condition: output of a concurrent program depends on the order of operations between threads Mutual exclusion: only one thread does a particular thing at a time – Critical section: piece of code that only one thread can execute at once Lock: prevent someone from doing something – Lock before entering critical section, before accessing shared data – Unlock when leaving, after done accessing shared data – Wait if locked (all synchronization involves waiting!)
- 42. Too Much Milk, Try #1 • Correctness property – Someone buys if needed (liveness) – At most one person buys (safety) • Try #1: leave a note if (!note) if (!milk) { leave note buy milk remove note }
- 43. Too Much Milk, Try #2 Thread A leave note A if (!note B) { if (!milk) buy milk } remove note A Thread B leave note B if (!noteA) { if (!milk) buy milk } remove note B
- 44. Lessons • Solution is complicated – “obvious” code often has bugs • Peterson Algorithm // Indicate the intent to enter the critical section bIWantToEnter = true; // Be polite and act as if it is not our // turn to enter the critical section iWhoseTurn = HIS_TURN; // Wait until the other process either does not // intend to enter the critical section or // acts as if its our turn to enter while (bHeWantsToEnter && (iWhoseTurn != MY_TURN)) { } // Code of critical section comes here ... bIWantToEnter = false;
- 45. Roadmap
- 46. Locks • Lock::acquire – wait until lock is free, then take it • Lock::release – release lock, waking up anyone waiting for it 1. At most one lock holder at a time (safety) 2. If no one holding, acquire gets lock (progress) 3. If all lock holders finish and no higher priority waiters, waiter eventually gets lock (progress)
- 47. Too Much Milk, #4 Locks allow concurrent code to be much simpler: lock.acquire(); if (!milk) buy milk lock.release();
- 48. Virtual Memory
- 49. Simple Memory Protection Base and Bounds
- 50. Towards Virtual Addresses • Problems with base and bounds? – Expandable heap? – Expandable stack? – Memory sharing between processes? – Non-relative addresses – hard to move memory around – Memory fragmentation • How to get more memmory than currently available?
- 51. Virtual Addresses • Translation done in hardware, using a table • Table set up by operating system kernel
- 52. Main Points • Address Translation Concept – How do we convert a virtual address to a physical address? • Flexible Address Translation – Base and bound – Segmentation – Paging – Multilevel translation • Efficient Address Translation – Translation Lookaside Buffers – Virtually and physically addressed caches
- 54. Address Translation Goals • Memory protection • Memory sharing – Shared libraries, interprocess communication • Sparse addresses – Multiple regions of dynamic allocation (heaps/stacks) • Efficiency – Memory placement – Runtime lookup – Compact translation tables • Portability
- 55. Paged Translation • Manage memory in fixed size units, or pages • Finding a free page is easy – Bitmap allocation: 0011111100000001100 – Each bit represents one physical page frame • Each process has its own page table – Stored in physical memory – Hardware registers • pointer to page table start • page table length
- 58. Paging Questions • Can we share memory between processes? – Set entries in both page tables to point to same page frames – Need core map of page frames to track which processes are pointing to which page frames (e.g., reference count) • What if page size is very small? • What if page size is very large? – Internal fragmentation: if we don’t need all of the space inside a fixed size chunk
- 59. Segmentation • Segment is a contiguous region of virtual memory • Each process has a segment table (in hardware) – Entry in table = segment • Segment can be located anywhere in physical memory – Each segment has: start, length, access permission • Processes can share segments – Same start, length, same/different access permissions
- 60. Segmentation
- 61. Segmentation • Pros? – Can share code/data segments between processes – Can protect code segment from being overwritten – Can transparently grow stack/heap as needed – Can detect if need to copy-on-write • Cons? – Complex memory management • Need to find chunk of a particular size – May need to rearrange memory from time to time to make room for new segment or growing segment • External fragmentation: wasted space between chunks
- 62. Paged Segmentation • Process memory is segmented • Segment table entry: – Pointer to page table – Page table length (# of pages in segment) – Access permissions • Page table entry: – Page frame – Access permissions • Share/protection at either page or segment-level
- 64. A Preview: MIPS Address Translation • Software-Loaded Translation lookaside buffer (TLB) – Cache of virtual page -> physical page translations – If TLB hit, physical address – If TLB miss, trap to kernel – Kernel fills TLB with translation and resumes execution • Kernel can implement any page translation – Page tables – Multi-level page tables – Inverted page tables – …
- 65. A Preview: MIPS Lookup
- 66. Page/Cache Replacement Policy • On a page/cache miss, how do we choose which entry to replace? – Assuming the new entry is more likely to be used in the near future – In direct mapped caches, not an issue! • Policy goal: reduce cache misses – Improve expected case performance – Also: reduce likelihood of very poor performance
- 67. A Simple Policy • Random? – Replace a random entry • FIFO? – Replace the entry that has been in the cache the longest time – What could go wrong?
- 68. FIFO in Action Worst case for FIFO is if program strides through memory that is larger than the cache
- 69. MIN, LRU, LFU • MIN – Replace the cache entry that will not be used for the longest time into the future – Optimality proof based on exchange: if evict an entry used sooner, that will trigger an earlier cache miss • Least Recently Used (LRU) – Replace the cache entry that has not been used for the longest time in the past – Approximation of MIN • Least Frequently Used (LFU) – Replace the cache entry used the least often (in the recent past)
- 70. Clock Algorithm: Estimating LRU • Periodically, sweep through all pages • If page is unused, reclaim • If page is used, mark as unused
- 71. Nth Chance: Not Recently Used • Instead of one bit per page, keep an integer – notInUseSince: number of sweeps since last use • Periodically sweep through all page frames if (page is used) { notInUseSince = 0; } else if (notInUseSince < N) { notInUseSince++; } else { reclaim page; }
- 72. Implementation Note • Clock and Nth Chance can run synchronously – In page fault handler, run algorithm to find next page to evict – Might require writing changes back to disk first • Or asynchronously – Create a thread to maintain a pool of recently unused, clean pages – Find recently unused dirty pages, write mods back to disk – Find recently unused clean pages, mark as invalid and move to pool – On page fault, check if requested page is in pool! – If not, evict that page
Editor's Notes
- #4: In some sense, OS is just a software engineering problem: how do you convert what the hardware gives you into something that the application programmers want? For any OS area (file systems, virtual memory, networking, CPU scheduling), begin by asking two questions: what’s the hardware interface? (the physical reality) what’s the application interface? (the nicer abstraction) We’ve broken it down a bit: we have users and their applications. You probably already know about libraries – that applications can be linked with code that helps them do their job, e.g., like the C library, with malloc and free and string operations. But when you write an app, you write it as if it has the entire machine – you don’t need to worry about the fact that there are multiple other apps running at the same time. It doesn’t crash just because one of those other apps has a bug. This interface is an abstract virtual machine – an abstraction that allows programmers to ignore the OS. Much of the OS runs in “kernel mode” – we’ll describe that in the next lecture. That code provides applications the abstraction of their own dedicated hardware. And under all of that is another abstraction, that allows the OS to run on a variety of different hardware – this is the HAL. That way, you can change the underlying hardware, without changing (much of) the OS. Need to have the various layers coordinate – library makes calls into the kernel to do things, like write file data to the disk, or get a network packet. But they run in separate domains. As you look at the code in OS/161, or if you look inside Linux (or any other OS you might find), you’ll see these three categories. Kern – kernel code Userland – system libraries Kern/arch – machine dependent routines, specific to each different type of CPU One of the first questions you’ll see in assignment 0 is: how does a system call work? Where do you find the code to read from a file in userland? Where do you find the code to read from a file in the kernel? Where do you find the machine-specific code to read from the physical disk?
- #5: Each of these points is pretty complex! But we’ll see a lot of examples. 90% of the code in an OS is in the glue – but its mostly easy to understand, so we won’t spend any time on it. Consider the illusion though – you buy a new computer, with more processors than the last one. But you don’t have to get all new software – the OS is the same, the apps are the same, but the system runs faster. How does it do that? You buy more memory – you don’t change the OS, you don’t change the apps, but the system runs faster. How does it do that? Part of the answer is that the OS serves as the referee between applications. How much memory should everyone have? How much of the CPU? The OS also has to isolate the different applications and users from each other – if one app crashes, you don’t want it to require a system reboot. If one user writes a buggy app on attu, you don’t want it to crash the system for everyone else. How is that even possible?
- #6: Ask: Examples of OS as referee? Examples of OS as illusionist?
- #7: Ask audience for ideas – they’ve taken machine structures. Answer: need memory protection, but also ability to interrupt a running job. And to have a privileged mode – capable of changing the memory proection.
- #9: An excuse to define some terms!
- #12: And wait…
- #15: Not just about OS’es; not just bugs
- #16: OK, so you compile your program into an executable image with instructions and data. Which of these is the program? How does it start running? Well, if its Javascript – no compilation step! Just interprets the source code. If its Android, then its compiled into a byte code that is interpreted in software – well, actually, interpreted into short snippets of instructions, with jumps back into the interpreter when done. If it’s attu, then compiled into x86 instructions. What’s to keep the process from overwriting the OS kernel? Or some other process running at the same time? What’s to keep it from overwriting the disk? From reading someone else’s files that are stored on disk?
- #19: Upsides? Downsides to this approach? Essentially what you do in Javascript in a browser – simulate the execution of the script, one line at a time.
- #20: Obviously, you need the part that has full rights to be really reliable!
- #22: Where do interrupts fit in?
- #24: Second thing
- #25: Change mode bit in EFLAGs register! Change which memory locations a user program can access Send commands to I/O devices Read data from/write data to I/O devices Jump into kernel code …
- #26: Might work better starting with interrupts!
- #27: OK, a quick tour of I/O. Without I/O, can’t do much of anything!
- #31: Note: by “processor register” I do not mean %eax. Rather – these are special purpose registers.
- #36: Execution model: each thread runs on a dedicated virtual processor with unpredictable and variable speed.
- #38: Labels should be thread_create() not sthread_create, etc.
- #39: NOTE to instructors: it is helpful to walk through an example such as readers/writers locks for illustrating the use of condition variables. I haven’t included it in these slides, as I usually take a class to do that example on the board – showing what happens as multiple threads stop at various points during the execution and other threads run.
- #40: To solve any of these, you need synchronization. You want program behavior to be a specific function of input – not of the sequence of who went first. You want the behavior to be deterministic – not to vary from run to run Even if you ignore those, the compiler will mess you up bad (compared to what you think will happen) And even If you ignore that, the hardware will mess you up bad.
- #43: What can go wrong? Thread A, Thread B
- #44: What can go wrong? Starvation
- #47: Bounded waiting
- #50: Second thing
- #52: On every instruction! Table of instructions set up by the kernel: similar idea to buffer descriptor queue for I/O
- #56: Simpler, because allows use of a bitmap. What's a bitmap? 001111100000001100 Each bit represents one page of physical memory -- 1 means allocated, 0 means unallocated. Lots simpler than base&bounds or segmentation
- #59: Means lots of space taken up with page table entries.
- #61: This should seem a bit strange: the virtual address space has gaps in it! Each segment gets mapped to contiguous locations in physical memory, but may be gaps between segments. This is a little like walking around in the dark, and there are huge pits in the ground where you die if you step in the pit. But! of course, a correct program will never step off into a pit, so ok. A correct program will never address gaps; if it does, trap to kernel and then core dump. Minor exception: stack, heap can grow. In UNIX, sbrk() increases size of heap segment. For stack, just take fault, system automatically increases size of stack. Detail: Protection mode in segmentation table entries. For example, code segment would be read-only (only execution and loads are allowed). Data and stack segment would be read-write (stores allowed). What must be saved/restored on context switch? Typically, segment table stored in CPU, not in memory, because it’s small. Contents must be saved/restored.