├── 1-Overview.md ├── 10-Remote-Procedure-Calls.md ├── 11-Distributed-File-Systems.md ├── 12-Distributed-Shared-Systems.md ├── 2-Process-Management.md ├── 3-Threads-and-Concurrency.md ├── 4-Scheduling.md ├── 5-Memory-Management.md ├── 6-Inter-Process-Communication.md ├── 7-Synchronization.md ├── 8-IO-Management.md ├── 9-Virtualization.md ├── README.md └── images ├── README.md ├── access.png ├── apachewebserver.png ├── blockdevicestack.png ├── cachecoherence.png ├── cachecoherence2.png ├── cachingstate.png ├── case1.png ├── case2.png ├── case3.png ├── case4.png ├── causal.png ├── cputs.png ├── deadlock.png ├── demandpaging.png ├── disableis.png ├── eventdrivenmodel.png ├── extremes.png ├── extremes2.png ├── hardwaresupport.png ├── hashingpt.png ├── hierarchicalpt.png ├── hierarchicalpt2.png ├── hosted.png ├── howpcbisused.png ├── hwprotectionlevels.png ├── hypervisor.png ├── hypervisordirect.png ├── interrupts.png ├── interruptsasthreads.png ├── invertedpt.png ├── io.png ├── iointeractions.png ├── iots.png ├── kernelvuserthread.png ├── linuxarch.png ├── manytomany.png ├── manytoone.png ├── marshalling.png ├── messagepassing.png ├── messagepassingipc.png ├── metadata.png ├── mmgoals.png ├── msgq.png ├── mutex.png ├── notation.png ├── onetoone.png ├── osbypass.png ├── pagefaults.png ├── pagetables.png ├── passthrough.png ├── pcb.png ├── pfn.png ├── pfnx86.png ├── pipes.png ├── preemptive.png ├── priority.png ├── process.png ├── processlifecycle.png ├── processvthread.png ├── producerconsumer.png ├── ptcache.png ├── pts.png ├── rpcrequirements.png ├── rpcstructure.png ├── rr1.png ├── rr2.png ├── rr3.png ├── rr4.png ├── segmentation.png ├── segmentationpaging.png ├── seq.png ├── sharedmemory.png ├── sharedmemoryipc.png ├── sharedmmmp.png ├── signals.png ├── sockets.png ├── splitdevicedriver.png ├── strict.png ├── systemcallflowchart.png ├── threadds.png ├── timeslice.png ├── tshandling.png ├── typicaldeviceaccess.png ├── unmarshalling.png ├── userkernelprotectionboundary.png ├── userlevelvkernellevel.png ├── vfs.png ├── virtualization.png └── weak.png /1-Overview.md: -------------------------------------------------------------------------------- 1 | # Operating Systems Overview 2 | 3 |
4 | 5 | **Operating Systems** : 6 | - Direct operational resources [CPU, memory, devices] 7 | - Enforces working policies [Resource usage, access] 8 | - Mitigates difficulty of complex tasks [abstract hardware details (using system calls)] 9 | 10 | ## What is an Operating System? 11 | 12 | * Intermediate between Hardware and Software applications 13 | * Hides hardware complexity (Read/write file storage, send/receive socket network) 14 | * Handles resource management (CPU scheduling, Memory management) 15 | * Provide isolation and protection (allocate different parts of memory to different applications so that applications don't overwrite other memory locations) 16 | 17 | ## Operating System definition: 18 | 19 | An **Operating System** is a layer of systems software that: 20 | * directly has privileged access to the underlying hardware; 21 | * hides the hardware complexity; 22 | * manages hardware on behalf of one or more application according to some predifined policies. 23 | * In addition, it ensures that applications are isolated and protected from one another. 24 | 25 | ## Operating System examples: 26 | 27 | Desktop|Embedded devices 28 | -----------|------------ 29 | Microsoft Windows | Android OS 30 | MAC OS X (BSD) | iOS 31 | LINUX | Symbian 32 | ...|... 33 | 34 | ## OS Elements 35 | 36 | - **Abstractions** (corresponds to applications that OS executes) 37 | - process, thread, file, socket, memory page 38 | - **Mechanisms** (on top of Abstractions) 39 | - create, schedule, open, write, allocate 40 | - **Policies** (how mechanisms are used to manage underlying hardware) 41 | - Least Recently Used (LRU) , Earliest Deadline First (EDF), etc. 42 | 43 | #### Example : 44 | 45 | _Memory Management:_ 46 | 47 | - **Abstractions**: Memory page 48 | - **Mechanisms**: Allocate, map to a process 49 | - **Policies**: LRU 50 | 51 | ## OS Design Principles 52 | 53 | - Seperation of mechanism and policy 54 | - implement flexible mechanisms to support many policies 55 | - e.g. LRU, LFU, random 56 | - Optimize for common case 57 | - Where will the OS be used? 58 | - What will the user want to execute on that machine? 59 | - What are the workload requirements? 60 | 61 | ## User/ Kernel Protection Boundary 62 | 63 | * user-level => applications [underprivileged mode] 64 | * kernel-level => OS Kernel [privileged access, hardware access] 65 | 66 | ![userkernelprotectionboundary](images/userkernelprotectionboundary.png) 67 | 68 | - User-Kernel switch is supported by hardware. 69 | - using trap instructions 70 | - system calls like: 71 | - open (file) 72 | - send (socket) 73 | - malloc (memory) 74 | - signals 75 | 76 | ## System call Flowcart 77 | 78 | ![systemcallflowchart](images/systemcallflowchart.png) 79 | 80 | - To make a system call, an application must: 81 | - write arguments 82 | - save relevant data ast well defined location 83 | - make system calls using system call number 84 | - In synchronous mode : wait until system call completes. 85 | 86 | ## Basic OS services 87 | 88 | * process management 89 | * file management 90 | * device management 91 | * memory management 92 | * storage management 93 | * security 94 | 95 | ## Linux System Calls 96 | 97 | Task|Commands 98 | ------------ | ------------ 99 | Process Control | fork (); exit(); wait(); 100 | File Manipulation | open(); read(); write(); 101 | Device Manipulation | ioctl(); read(); write(); 102 | Information Maintenance | getpid(); alarm(); sleep(); 103 | Communication | pipe(); shmget(); mmap(); 104 | Protection | chmod(); umask(); chown(); 105 | 106 | ## Linux Architecture 107 | 108 | ![linuxarchitecture](images/linuxarch.png) 109 | 110 |
-------------------------------------------------------------------------------- /10-Remote-Procedure-Calls.md: -------------------------------------------------------------------------------- 1 | # Remote Procedure Calls 2 | 3 | Example : GetFile App 4 | 5 | - Client Server 6 | - Create and init sockets 7 | - Allocate and populate buffers 8 | - Include 'protocol' info 9 | - GetFile, size 10 | - Copy data into buffers 11 | - filename, file 12 | * common steps related to remote IPC 13 | 14 | #### Remote Procedure Calls (RPC) 15 | 16 | * Intended to simplify the development of cross address space and cross machine interactions 17 | 18 | **\+** Higher-level interface for data movement and communication
19 | **\+** Error handling
20 | **\+** Hiding complexities of cross machine interactions 21 | 22 | ## RPC requirements 23 | 24 | ![rpcrequirements](images/rpcrequirements.png) 25 | 26 | 1. Client/Server interactions 27 | 2. Procedure Call Interface => RPC 28 | - sync call semantics 29 | 3. Type checking 30 | - error handling 31 | - packet bytes interpretation 32 | 4. Cross machine conversion 33 | - e.g. big/little endian 34 | 5. Higher level protocol 35 | - access control, fault tolerance, different transport protocols 36 | 37 | ## Structure of RPC 38 | 39 | ![rpcstructure](images/rpcstructure.png) 40 | 41 | ## RPC Steps: 42 | 43 | (-1.) register : server registers procedure, arg types, location
44 | (0.) bind : client finds and binds to desired server 45 | 46 | 1. call : client make RPC call; control passed to stub, client code blocks 47 | 2. marshal : client stub "marshals" args (serialize args into buffer) 48 | 3. send : client sends message to server 49 | 4. receive : server receives message; passes message to server stub; access control 50 | 5. unmarshal : server stub "unmarshals" args (extract args from buffer) 51 | 6. actual call : server stub calls local procedure implementation 52 | 7. result : server performs operation and computes result of RPC operation 53 | 54 | (same on return <=) 55 | 56 | ## Interface definition Language (IDL) 57 | 58 | * Used to describe the interface the server expects 59 | - procedure name, args, 2 result types 60 | - version number 61 | 62 | RPC can use IDL that is 63 | 64 | 1. Language agnostic 65 | - XDR in SunRPC 66 | 2. Language specific 67 | - Java in JavaRMI 68 | 69 | ## Marshalling 70 | 71 | ![Marshalling](images/marshalling.png) 72 | 73 | ## Unmarshalling 74 | 75 | ![Unmarshalling](images/unmarshalling.png) 76 | 77 | Marshalling/Unmarshalling routines are provided by RPC system compiler. 78 | 79 | ## Binding and Registry 80 | 81 | * Client determines 82 | - **which** server to connect to? 83 | - service name. version number 84 | - **how** to connect to that server? 85 | - IP address, network protocol 86 | * Registry : database of available services 87 | - search for service name to find server(which) and contact details(how) 88 | - distributed 89 | - any RPC service can register 90 | - machine-specific 91 | - for services running on same machine 92 | - clients must know machine addresses 93 | - registry provides port number needed for connection 94 | * Who can provide a service? 95 | - lookup registry for image processing 96 | * What services do they provide? 97 | - compress/filter.. version number => IDL 98 | * How will they ship package? 99 | - TCP / UDP -> registry 100 | 101 | ## Pointers 102 | 103 | * Procedure interface : foo(int,int) 104 | * in Local Calls : foo(x,y) => okay 105 | * in Remote Calls : foo(x,y) => ? 106 | 107 | here, y points to location in caller address space 108 | 109 | * Solutions: 110 | - No pointers 111 | - Serialize pointers; copy referenced ("points to") data structure to send buffer 112 | 113 | ## Handling Partial Failures 114 | 115 | - Special RPC error notification (signal, exception..) 116 | - Catch all possible ways in which RPC can (partially) fail 117 | 118 | ## RPC Design choice 119 | 120 | * Binding => How to find the server 121 | * IDL => How to talk to server; how to package data 122 | * Pointers as args => Disallow or serialize pointer data 123 | * Partial failures => Special error notifications 124 | 125 |
-------------------------------------------------------------------------------- /11-Distributed-File-Systems.md: -------------------------------------------------------------------------------- 1 | # Distributed File Systems 2 | 3 | - Accessed via well defined interface 4 | - access via Virtual File Systems 5 | - Focus on consistent state 6 | - tracking state, file update, cache coherence 7 | - Mixed distribution models possible 8 | - replicates vs partitioned, peer-like systems 9 | 10 | ## DFS models 11 | 12 | - Client Server on different machines 13 | - File server distributed on multiple machines 14 | - replicated (each server : all files) 15 | - partitioned (each server : parts of files) 16 | - both (files partitioned, each partition replicates) 17 | - Files stored on and served from all machines (peers) 18 | - blurred distinction between clients and servers 19 | 20 | ## Remote File Service : Extremes 21 | 22 | ![extremes](images/extremes.png) 23 | 24 | ![extremes2](images/extremes2.png) 25 | 26 | 1. Extreme1 : Upload/Download 27 | - like FTP, SVN 28 | - **\+** local read/writes at client 29 | - **\-** entire file download/upload evn for small accesses 30 | - **\-** server gives up contro; 31 | 2. Extreme2 : True Remote File Access 32 | - Every access to remote file, nothing done locally 33 | - **\+** file access centralized, easy to reason about consistency 34 | - **\-** every file operation pays network cost, limits server scalablity 35 | 36 | ## Remote File Service : A compromise 37 | 38 | A more practical Remote File access (with Caching) 39 | 40 | 1. Allow clients to store parts of files locally (blocks) 41 | - **\+** low latency on file operations 42 | - **\+** server load reduces => more scalable 43 | 2. Force clients to interact with server (frequently) 44 | - **\+** server has insights into what clients are doing 45 | - **\+** server has control into which accesses can be permitted => easier to maintain consistency 46 | - **\-** server more complex, requires different file sharing semantics 47 | 48 | ## Stateless vs Stateful File server 49 | 50 | Stateless | Stateful 51 | ----------|---------- 52 | Keeps no state; Okay with extreme models, but can't support 'practical' model|Keeps client state needed for 'practical' model to track what is cached/accessed 53 | **\-** Can't support caching and consistency management|**\+** Can support locking, caching, incremental operations 54 | **\-** Every request self-contained. => more bits transferred|**\-** Overheads to maintain state and consistency. Depends on caching mechanism and consistency protocol. 55 | **\+** No resources are used on server side (CPU, MM). On failure just restart|**\-** On failure, need checkpoining and recovery mechanisms 56 | 57 | ## Caching state in a DFS 58 | 59 | * Locally clients maintain portion of state (e.g. file blocks) 60 | * Locally clients perform operations on cached state (e.g. open/read/write) 61 | * requires coherent mechanisms 62 | 63 | ![cachingstate.png](images/cachingstate.png) 64 | 65 | |System|How|When| 66 | |---|----|----| 67 | |SMP|Write-update/Write-invalidate|On write| 68 | |DFS|Client/Server-driven|On demand, periodically, on open..| 69 | 70 | * Files or File blocks can be (with 1 server and multiple clients) cached in: 71 | - in client memory 72 | - on client storage device (HDD/SDD) 73 | - in buffer cache in memory on server 74 | - (usefulness will depend on client load, request interleaving) 75 | 76 | * File Sharing Semantics in DFS 77 | 78 | * Session semantics (between open-close => Session) 79 | - write-back on close(), update on open() 80 | - easy to reason, but may be insufficient 81 | * Periodic updates 82 | - client writes-back periodically 83 | - clients have a "lease" on cached data (not exclusively necessary) 84 | - servers invalidates periodically => provides biunds on "inconsistency" 85 | - augment with flush()/sync() API 86 | * Immutable files => never modify, new files created 87 | * Transactions => all changes atomic 88 | 89 | # Replication vs Partitioning 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 |
ReplicationPartitioning
Each machine holds all filesEach machine has subset of files
AdvantagesLoad balancing, availibility, fault tolerance Availibility vs single server DFS;
Scalability with file system size;
single file writes simpler
DisadvantagesWrite becomes more complex
- Synchronous to all
- or, write to one, then propagate to others
replicas must be reconciled e.g. Voting		On failure, lose portion of data
load balancing harder, if not balanced, then hot-spots possible
113 | 114 | * Can combine both techniques 115 | - Replicate each partition! 116 | 117 |
-------------------------------------------------------------------------------- /12-Distributed-Shared-Systems.md: -------------------------------------------------------------------------------- 1 | # Distributed Shared Memory 2 | 3 | - Must decide placement 4 | - place memory (pages) close to relevant processes 5 | - Must decide migration 6 | - when to copy memory (pages) from remote to local 7 | - Must decide sharing rules 8 | - ensure memory generations are properly ordered 9 | 10 | ## "Peer" Distribution Applications 11 | 12 | * Each node 13 | - "owns" state 14 | - provide service 15 | - all nodes are "peers". 16 | 17 | Examples: Big-data analytics, web searches, context sharing or distributed shared memory (DSM) 18 | 19 | ## Distributed Shared Memory (DSM) 20 | 21 | DSM is a service that manages memory accross multiple nodes so that applications that are running on top will have an illusion that they are running on a shared memory. 22 | 23 | * Each node 24 | - "owns" state => memory 25 | - provide service 26 | - memory read/writes from any nodes 27 | - consistency protocols 28 | - permits scaling beyond single machine memory limits 29 | - more "shared" memory at lower cost 30 | - slower overall memory access 31 | - commodity interconnect technologies support this RDMA(Remote Direct Memory Access) 32 | 33 | ## Hardware vs Software DSM 34 | 35 | * Hardware-supported (expensive!) 36 | - relies on interconnect 37 | - OS manages larger physical memory 38 | - NIC(Network Interface Cards) translate remote memory accesses to messages 39 | - NICs involved in all aspects of memory management; support atomics.. 40 | * Software supported 41 | - everything done by software 42 | - OS,or language runtime 43 | * Hybrid (Software tasks in Hardware) DSM implementations 44 | - prefetch pages 45 | - address translation (easier done in hardware) 46 | - triggering invalidations (easier done in hardware) 47 | 48 | ## DSM Design : Sharing Granularity 49 | 50 | * cache line granularity? 51 | - overheads too high for DSM 52 | - variable granularity [N] 53 | - page granularity [Y] (OS level) 54 | - object granularity [Y] (Language runtime) 55 | - beware of false sharing E.g. x and y shared on same page 56 | 57 | ## What types of applications use DSM? 58 | 59 | Application access algorithm 60 | - Single reader/ single writer (SRSW) 61 | - Multiple readers/ single writer (MRSW) 62 | - Multiple reader/ Multiple writers (MRMW) 63 | 64 | ## Performance considerations 65 | 66 | * DSM performance metric == access latency 67 | * Achieving low latency through 68 | - Migration 69 | - makes sense for SRSW 70 | - requires data movement 71 | - Replication (caching) 72 | - more general 73 | - requires consistency management 74 | * Hence, migration is okay for SRSW but not for all. 75 | * Caching and Replication 76 | - Copies of data to incerease data access 77 | - for many concurrent writes, overheads too high but stil generally better than Migration 78 | 79 | ## Consistency Management 80 | 81 | * In SMP 82 | - write invalidate 83 | - write update 84 | * coherence operations triggered in each write 85 | - overhead too high 86 | * Push invalidations when data is written to 87 | 1. Proactive 88 | 2. Eager 89 | 3. Pessimistic 90 | * Pull modifications information periodically 91 | 1. on demand (reactive) 92 | 2. lazy 93 | 3. optimistic 94 | * when these methods get triggered depends on the consistency model for the shared state 95 | 96 | ## DSM architecture (page-based, OS-supported) 97 | 98 | * Page-based DSM architecture 99 | - distributed nodes, each with own local memory contribution 100 | - pool of pages from all nodes 101 | - each page has IO ("home" node), page frame number 102 | * if MRMW 103 | - need local caches for performances (latency) 104 | - "home" or "manager" node drives coherence operations 105 | - all nodes responsible for part if distributed memory (state) management 106 | * Home node 107 | - keeps state: page accessed, modifications, caching enabled/disabled, locked.. 108 | * Current owner 109 | - owner may not be equal to home node 110 | * Explicit replicas 111 | - for load balancing, performance, or reliability 112 | home, manager node controls memory 113 | 114 | 115 | ## DSM metadata 116 | 117 | ![metadata.png](images/metadata.png) 118 | 119 | ## Implementing DSMs 120 | 121 | * Problem : DSM must intercept access to DSM state 122 | - to send remote messages requesting access 123 | - to trigger coherence messages 124 | - overheads should be avoided for local non-shared state (pages) 125 | - dynamically engage and disengage DSM when necessary 126 | * Solution : Use hardware MMU support! 127 | - trap in OS if mapping invalid or access denied 128 | - remote address mapping -> trap and pass to DSM to send message 129 | - cached content -> trap and pass to DSM to perform memory coherence operations 130 | - other MMU information useful (e.g. Dirty page) 131 | 132 | ## Consistency model 133 | 134 | - Agreement between memory (state) and upper software layers 135 | - Memory behaves correctly if and only if software follows specific rules 136 | - Memory (state) guarantees to behave correctly 137 | - access ordering 138 | - propagation/ visibility of updates 139 | 140 | ### Our notation 141 | 142 | ![notation.png](images/notation.png) 143 | 144 | * R_m1(X) => X was read from memory location m1 145 | * W_m1(Y) => Y was written to memory location m1 146 | 147 | ### Strict Consistency 148 | 149 | Strict Consistency => updates visible everywhere immediately 150 | 151 | ![strict.png](images/strict.png) 152 | 153 | - In practice 154 | - Even on single SMP no guarantees on order without extra locking and synchronization 155 | - in DS, latency and message reorder make this even harder 156 | - Hence almost impossible to guarantee strict consistency 157 | 158 | ### Sequential Consistency 159 | 160 | ![seq.png](images/seq.png) 161 | 162 | Sequential consistency => 163 | 164 | * memory updates from different processors may be arbitrarily interleaved 165 | * All processes will see the same interleaving 166 | * Operations from the same process always appearin order they were issued 167 | 168 | ### Causal Consistency 169 | 170 | ![causal.png](images/causal.png) 171 | 172 | * For writes not causally related, "concurrent" writes doesnt gurantee. 173 | * Don't permit arbitrary ordering from same process writer 174 | 175 | ### Weak Consistency 176 | 177 | ![weak.png](images/weak.png) 178 | 179 | * Use of synchronization 180 | - Synchronization point => operations that are available (R,W,Sync) 181 | - all updates prior to a sync point will be visible 182 | - no guarantee what happens in between 183 | 184 | **\+** limit data movement of coherence operations 185 | 186 | **\-** maintain extra state for additional operations 187 | 188 | * Variations: 189 | - Single sync operation (sync) 190 | - Seperate sync per surface of state (page) 191 | - Seperate "entry/acquire" vs "exit/release" operations 192 |
193 | -------------------------------------------------------------------------------- /2-Process-Management.md: -------------------------------------------------------------------------------- 1 | # Process and Process Management 2 | 3 | **Process**: Instance of an executing program. 4 | 5 | - State of execution 6 | - program counter, stack pointer 7 | - Parts and temporary holding area 8 | - data, register state, occupies state in memory 9 | - May require special hardware 10 | - I/O devices 11 | 12 | Process is a state of a program when executing and loaded in memory (active state) as opposed to application (static state). 13 | 14 | ## What does a process look like? 15 | 16 | ![Process](images/process.png) 17 | 18 | ### Type of state 19 | 20 | - Text and Data 21 | - static state when process loads first 22 | - Heap 23 | - dynamically created during execution 24 | - Stack 25 | - grows and shrinks 26 | - LIFO queue (used to store task checkpoints to resume the original process after switching from another.) 27 | 28 | ## How does the OS know what a process is doing? 29 | 30 | Using: 31 | 32 | * Program counter 33 | * CPU registers 34 | * Stack pointer 35 | 36 | ## Process Control Block (PCB) 37 | 38 | ![PCB](images/pcb.png) 39 | 40 | * PCB created when process is created 41 | * Certain fields are updated when process state change e.g. memory mapping 42 | * or other fields that change very frequently e.g. Program Counter 43 | 44 | ## How is PCB used ? 45 | 46 | ![howpcbisused](images/howpcbisused.png) 47 | 48 | ## Context Switch 49 | 50 | * Mechanism used to switch from the context of one process to another in the CPU. 51 | 52 | - They are expensive! 53 | - direct costs: no of cycles for load and store instructions. 54 | - indirect costs: **COLD** cache (read more [here](http://stackoverflow.com/questions/22756092/what-does-it-mean-by-cold-cache-and-warm-cache-concept)) 55 | - Therefore limit frequency how context switching is done. 56 | 57 | When a cache is **HOT**, most process data is in the cache so the process performance will be at its best. 58 | 59 | Sometimes there are situations where we have to Context Switch (higher priority process, timesharing, etc.) 60 | 61 | ## Process Lifecycle 62 | 63 | ![processlifecycle](images/processlifecycle.png) 64 | 65 | CPU is able to execute a process when the process is in Running or Ready state. 66 | 67 | ## Process Creation 68 | 69 | #### Mechanisms: 70 | 71 | - fork : 72 | - copies the parent PCB into new child PCB 73 | - child contains execution at instruction after fork 74 | 75 | - exec : 76 | - replace child image 77 | - load new program and start from first instruction 78 | 79 | ## What is the role of CPU scheduler? 80 | 81 | CPU scheduler determines which one of the currently ready processes will be dispatched to the CPU to start running, and how long it should run for. 82 | 83 | OS must : 84 | 85 | * preempt => interrupt and save current context 86 | * schedule => run scheduler to choose next process 87 | * dispatch => dispatch process 2 switch into its context 88 | 89 | ## Scheduling design decisions 90 | 91 | ![timeslice](images/timeslice.png) 92 | 93 | * What are the appropriate timeslice values? 94 | * Metrics to choose next process to run? 95 | 96 | ## I/O 97 | 98 | A process can make way in the ready queue in a number of ways. 99 | 100 | ![io](images/io.png) 101 | 102 | ## Can process interact? 103 | 104 | #### Inter Process communication: 105 | 106 | IPC mechanisms: 107 | 108 | - transfer data/info between address space 109 | - maintain protection and isolation 110 | - provide flexibility and performance 111 | 112 | Two types of IPC models: 113 | 114 | #### 1. **Message Passing IPC** 115 | 116 | ![messagepassing](images/messagepassing.png) 117 | 118 | * OS provides communication channel line shared buffer 119 | * Processes can write(send), read(receive) msg to/from channel 120 | 121 | **Advantages**: OS manages the channel
122 | **Disadvantages**: Overheads 123 | 124 | #### 2. **Shared Memory IPC** 125 | 126 | ![sharedmemory](images/sharedmemory.png) 127 | 128 | * OS establishes a shared channel and maps it into each processes' address space 129 | * Processes directly write(send), read(receive) msg to/from this memory 130 | 131 | **Advantages**: OS is out of the way after establishing the shared channel
132 | **Disadvantages**: Re-implementing a lot of code that could have been done by the OS 133 | 134 | Overall, **shared memory** based communication is better if mapping memory between two processes is ammortized over a large number of messages. 135 | 136 |
-------------------------------------------------------------------------------- /3-Threads-and-Concurrency.md: -------------------------------------------------------------------------------- 1 | # Threads and Concurrency 2 | 3 | **Thread**: 4 | 5 | - is an active 6 | - entity executing unit of a process 7 | - works simultaneously with others 8 | - many threads execute together 9 | - requires coordination 10 | - sharing of I/O devices, CPUs, memory 11 | 12 | ## Process vs Thread 13 | 14 | ![processvthread](images/processvthread.png) 15 | 16 | ## Why are threads useful? 17 | 18 | * Parallelization => Speedup 19 | * Specialization => Hot cache 20 | * Efficiency => lower memory requirement & cheaper IPC 21 | * Time for context switch in threads is less, since memory is shared, hence mapping is not required between virtual and physical memory. 22 | - Therefore multithreading can be used to hide latency. 23 | * Benefits to both applicatioons and OS code 24 | - Multithreaded OS kernel 25 | - threads working on behalf of applications 26 | - OS level services like daemons and drivers 27 | 28 | ## What do we need to support threads? 29 | 30 | * Threads data structure 31 | - Identify threads, keep track of resource usage.. 32 | * Mechanisms to create and manage threads 33 | * Mechanisms to safely coordinate among threads running concurrently in the same address space 34 | 35 | ## Concurrency control and Coordination 36 | 37 | - Mutual exclusion 38 | - Exclusive access to only one thread at a time 39 | - **mutex** 40 | - Waiting on other threads 41 | - Specific condition before proceeding 42 | - **condition variable** 43 | - Waking up other threads from wait state 44 | 45 | ## Threads and Threads creation 46 | 47 | - Thread data structure: 48 | - Thread type, Thread ID, PC, SP, registers, stack, attributes. 49 | 50 | - **Fork**(proc, args) 51 | - create a thread 52 | - not UNIX fork 53 | 54 | ``` 55 | t1 = fork(proc, args) 56 | ``` 57 | 58 | - **Join**(thread) 59 | - terminate a thread 60 | 61 | ``` 62 | child_result = join(t1) 63 | ``` 64 | 65 | ### Example: 66 | 67 | ``` 68 | Thread t1; 69 | Shared_List list; 70 | t1 = fork(safe_insert, 4); 71 | safe_insert(6); 72 | join(t1); //Optional 73 | ``` 74 | 75 | The list can be accessed by reading shared variable. 76 | 77 | ## Mutual Exclusion 78 | 79 | - Mutex data structure: 80 | - locked?, owner, blocked_threads 81 | 82 | ``` 83 | lock(mutex){ 84 | //Critical Section 85 | //Only one thread can access at a time 86 | } 87 | unlock(mutex) 88 | ``` 89 | ![mutex](images/mutex.png) 90 | 91 | ## Producer Consumer problem 92 | 93 | What if the processing you wish to perform with mutual exclusion needs to occur under certai conditions? 94 | 95 | For e.g. The producer appends items to a list until the list is full, and the consumer has to print out all the items of the list once the list if full and then empty the list. Thus we have to execute the Consumer thread only under a certain condition (here- when the list becomes empty, print items). 96 | 97 | Solution: Use **Condition Variables** 98 | 99 | - Wait(mutex, condition) 100 | - mutex is automatically released and reaquired on wait 101 | - The consumer applies _Wait_ until the list is full 102 | 103 | - Signal(condition) 104 | - Notify only one thread waiting on condition 105 | - The Producer applies _Signal_ to the Consumer thread when the list is full 106 | - Broadcast(condition) 107 | - Notify all waiting threads 108 | 109 | ![producerconsumer](images/producerconsumer.png) 110 | 111 | ## Readers / Writer problem 112 | 113 | * 0 or more readers can access a resource 114 | * 0 or 1 writer can write the resource concurrently at the same time 115 | 116 | - One solution: 117 | - lock on resource 118 | - good for writer 119 | - too restrictive for readers 120 | 121 | - Better solution: 122 | 123 | ``` 124 | if ((read_count == 0) & (read_count == 0)) 125 | R okay, W okay 126 | if (read_count > 0) 127 | R okay 128 | if (read_count == 1) 129 | R not-okay, W not-okay 130 | ``` 131 | 132 | State of shared resource: 133 | 134 | * free : resource_counter = 0 135 | * reading : resource_counter > 0 136 | * writing : resource_counter = -1 137 | 138 | Thus essentially we can apply mutex on the new proxy 'resource_counter' variable that represents the state of the shared resource. 139 | 140 | ## Avoiding common mistakes 141 | 142 | - keep track of mutex/lock variable used with a resource 143 | - e.g. mutex_type m1; // mutex for file1 144 | - check that you are always and correctly using lock and unlock - Compilers can be used as they generate errors/warnings to correct this type of mistake 145 | - Use a single mutex to access a single resource 146 | - check that you are signalling correct condition 147 | - check that you are not using signal when broadcast is needed 148 | - signal : only 1 thread is will proceed, remaining threads will wait 149 | - check thread execution order to be controlled by signals to condition variables 150 | 151 | ## Spurious(Unnecessary) Wake ups 152 | 153 | When we wake up threads knowing they may not be able to proceed. 154 | 155 | ## Deadlocks 156 | 157 | Two or more competing threads are said to be in a deadlock if they are waiting on each other to complete, but none of them ever do. 158 | 159 | ![deadlock](images/deadlock.png) 160 | 161 | Here T1 and T2 are in deadlock. 162 | 163 | ### How to avoid this? 164 | 165 | 1. Unlock T1 before locking T2 166 | - Fine-grained locking but T1 nad T2 may both be required 167 | 2. Use one mega lock, get all locks upfront, then release at end 168 | - For some applications this may be ok. But generally its too restrictive and limits parallelism 169 | 3. Maintain lock order 170 | - first m_T1 171 | - then m_T2 172 | - this will prevent cycles in wait graph 173 | 174 | A cycle in wait graph is necessary and sufficient for deadlock to occur.
175 | (thread-waiting-on-resource ---edge---> thread-owning-resource) 176 | 177 | * Deadlock prevention => Expensive
178 | Pre-check for cycles and then delay process or change code 179 | 180 | * Deadlock Detection and Recovery => Rollback 181 | 182 | ## Kernel vs User level Threads 183 | 184 | ![kernelvuserthread](images/kernelvuserthread.png) 185 | 186 | Three types of models: 187 | 188 | #### 1. **One to One model**: 189 | 190 | ![onetoone](images/onetoone.png) 191 | 192 | **Advantages**: 193 | 194 | * OS sees threads 195 | * Synchronization 196 | * Blocking 197 | 198 | **Disadvantages**: 199 | 200 | * Must go to OS for all operations 201 | * OS may have limits on policies, threads 202 | * Portability 203 | 204 | #### 2. **Many to One model**: 205 | 206 | ![manytoone](images/manytoone.png) 207 | 208 | **Advantages**: 209 | 210 | * Totally Portable 211 | * Doesn't depend on OS limits and policies 212 | 213 | **Disadvantages**: 214 | 215 | * OS may block entire process if one user-level thread blocks on I/O 216 | 217 | #### 3. **Many to Many model**: 218 | 219 | ![manytomany](images/manytomany.png) 220 | 221 | **Advantages**: 222 | 223 | * Best of both worlds 224 | * Can have bound or unbound threads 225 | 226 | **Disadvantages**: 227 | 228 | * Requires coordination between user and kernel level thread managers 229 | 230 | ## Multithreading patterns 231 | 232 | **1. Boss-Workers pattern** 233 | 234 | * Boss- assigns work 235 | * Workers- perform entire task 236 | 237 | Throughput of system is limited by boss thread. Hence boss thread must be kept efficient. 238 | 239 | Throughput = 1/boss-time-orders 240 | 241 | Boss assigns works by: 242 | 1. Directly signalling specific works 243 | - **\+** workers don't need to sync 244 | - **\-** boss must keep track of everyone 245 | 2. Placing work in queue 246 | - **\+** boss doesn't neeed to know details about workers 247 | - **\-** queue synchronization 248 | 249 | How many workers? 250 | - on demand 251 | - pool of workers 252 | - static vs dynamic (i.e dynamically increasing size according to work) 253 | 254 | **Advantages**: 255 | 256 | * Simplicity 257 | 258 | **Disadvantages**: 259 | 260 | * Thread pool management 261 | * Locality 262 | 263 | **1B. Boss-Workers pattern variant** 264 | 265 | * Here workers are specialized for certain tasks opposite to the previous equally created workers 266 | 267 | **Advantages**: 268 | * Better locality 269 | * Quality of Service management 270 | 271 | **Disadvantages**: 272 | * Load balancing 273 | 274 | **2. Pipeline pattern** 275 | 276 | * Threads assigned one subtask in the system 277 | * Entire task = Pipeline of threads 278 | * Multiple tasks concurrently run in the system, in different pipeline stages 279 | * Throughput depends on weakest link 280 | * Shared buffer based communication between stages 281 | 282 | **3. Layered pattern** 283 | 284 | * Layers of threads are assigned group of related subtasks 285 | * End to end task must pass up and down through all layers 286 | 287 | **Advantages**: 288 | * Specialization 289 | * Less fine-grained than pipeline 290 | 291 | **Disadvantages**: 292 | * Not suitable for all applications 293 | * Synchronization 294 | 295 | ### Example: 296 | 297 | **Q)** For 6 step toy order application we have 2 solutions: 298 | 299 | 1. Boss-workers solution 300 | 2. Pipeline solution 301 | 302 | Both have 6 threads. In the boss-workers solution, a worker produces a toy order in 120 ms. In the pipeline solution, each of 6 stages take 20 ms. 303 | 304 | How long will it take for these solutions to complete 10 toy orders and 11 toy orders? 305 | 306 | **A)** 6 threads means for Boss-workers, 1 thread is for boss, 5 for workers. In pipeline 6 threads are equally used. 307 | 308 | For 10 toy orders: 309 | ``` 310 | Boss-workers(10) = 120 + 120 = 240 ms 311 | Pipeline(10) = 120 + (9*20) = 300 ms 312 | ``` 313 | Here Boss-workers is better than Pipeline. 314 | 315 | For 11 toy orders: 316 | ``` 317 | Boss-workers(11) = 120 + 120 + 120 = 360 ms 318 | Pipeline(11) = 120 + (10*20) = 320 ms 319 | ``` 320 | Here Pipeline is better than Boss-workers. 321 | 322 | This proves that choosing a better pattern depends on the number of threads and the work required to be done. 323 | 324 | ## PThreads 325 | 326 | PThreads == POSIX Threads 327 | 328 | POSIX = Portable OS interface 329 | 330 | ### Compiling PThreads 331 | 332 | 1. #include in main file 333 | 2. Compile source with -lpthread or -pthread 334 | ``` 335 | gcc -o main main.c -lpthread 336 | gcc -o main main.c -pthread 337 | ``` 338 | 3. Check return values of common examples 339 | 340 | 341 | ### PThread mutexes 342 | - to solve mutual exclusion problems among concurrent threads 343 | 344 | ### Safety tips 345 | 346 | * Shared data should always be accessed through single mutex 347 | * Mutex scope must be visible to all 348 | * Globally order locks 349 | - for all threads, lock mutexes in order 350 | * Always unlock a mutex (correctly) 351 | 352 | ## Thread Design Considerations 353 | 354 | ### Kernel vs User Level Threads 355 | 356 | ![userlevelvkernellevel](images/userlevelvkernellevel.png) 357 | 358 | ### Thread related data structures 359 | 360 | ![threadds](images/threadds.png) 361 | 362 | ### Hard vs Light Process states 363 | 364 | PCB is divided into multiple data structures classified as follows: 365 | 366 | - Light Process states 367 | - Signal mask 368 | - System call args 369 | - Heavy Process states 370 | - virtual address mapping 371 | 372 | #### Rationale for Multiple Data Structures: 373 | 374 | |Single PCB |Multiple DS| 375 | |-----------|-----------| 376 | |Large continuos DS|Smaller DS| 377 | |Private for each entity|Easier to share| 378 | |Saved and restored on each context switch|Save and Restore only what needs to change on context switch| 379 | |Update for any changes|User lever library need to only update portion of the state| 380 | 381 | - Thus the following disadvantages for single PCB become advantages for Multiple DS : 382 | * Scalability 383 | * Overheads 384 | * Performance 385 | * Flexibility 386 | 387 | ## Comparison of Interrupts and Signals 388 | 389 | - Handled in specific ways 390 | - interrupt and signal handlers 391 | - Can be ignored 392 | - interrupt and signal mask 393 | - Expected or unexpected 394 | - appear synchronously or asynchronously 395 | 396 | * Difference: 397 | 398 | |Interrupts |Signals| 399 | |-----------|-----------| 400 | |Events generated externally by components other than CPU (I/O devices, timers, other CPUs)|Events triggered by CPU and software running on it| 401 | |Determined based on physical platform|Determined based on OS| 402 | |Appear asynchronously|Appear synchronously or asynchronously| 403 | 404 | - Similarities: 405 | - Have a unique ID depending on h/w or OS 406 | - Can be masked and disabled/suspended via corresponding mask 407 | - per-CPU interrupt mask, preprocess signal mask 408 | - if enabled, trigger corresponding to handler 409 | - interrupt handler set for entire system by OS 410 | - signal handler set on per process basis by process 411 | 412 | > An interrupt is like a snowstorm alarm
413 | > A signal is like a low battery warning 414 | 415 | ### Interrupts 416 | 417 | ![interrupts](images/interrupts.png) 418 | 419 | ### Signals 420 | 421 | ![signals](images/signals.png) 422 | 423 | #### Handlers / Actions 424 | - Default actions 425 | - Terminate, ignore 426 | - Terminate and core dump 427 | - Stop or continue 428 | - Process Installs Handler 429 | - signal(), sigaction() 430 | - for most signals, some cannot be "caught" 431 | - **Synchronous** 432 | - SIGSEGV (access to protected memory) 433 | - SIGFPE (divided by zero) 434 | - SIGKILL (kill, id) 435 | - can be directed to a specific thread 436 | - **Asynchronous*** 437 | - SIGKILL (kill) 438 | - SIGALARM 439 | ### Why disable Interrupts or Signals 440 | 441 | ![disableis](images/disableis.png) 442 | 443 | Here PC: First instruction in handler
444 | SP : thread stack 445 | 446 | To prevent deadlock, 447 | 448 | 1. Keep handler code simple 449 | - avoid mutex 450 | - **\-** too restrictive 451 | 2. Control interruptions by handler code 452 | - Use interrupt/signal masks 453 | - 0011100110.. (0: disabled, 1: enabled) 454 | 455 | ``` 456 | clear_field_in_mask(mask) 457 | lock(mutex) 458 | { 459 | 460 | #disabled => remaining pending 461 | 462 | } 463 | unlock(mutex) 464 | reset_field_in_mask(mask) 465 | 466 | #enabled => execute handler code 467 | ``` 468 | 469 | - Interrupt masks are per CPU 470 | - if mask disables interrupt, hardware interrupt rounting mechanism will not deliver interrupt 471 | 472 | - Signal are per execution context (User-level thread on top of Kernel-level thread) 473 | - if mask disables signal, kernel sees mask and will not interrupt corresponding thread 474 | 475 | ### Types of Signals 476 | 477 | 1. One-shot Signals 478 | - "n signals pending == 1 signal pending" : atleast once 479 | - must be explicitly re-enabled 480 | 2. Realtime Signals 481 | - "if n signals raised, then handler is called n times" 482 | 483 | ### Handling interrupts as threads 484 | 485 | ![interruptsasthreads](images/interruptsasthreads.png) 486 | 487 | but dynamic thread creation is expensive! 488 | 489 | - Dynamic decision 490 | - if handler doesn't lock 491 | - execute on interrupted threads stack 492 | - if handler can block 493 | - turn into real thread 494 | - Optimization 495 | - pre-create and pre-initialize thread structure for interrupt routines 496 | 497 | ### Threads and Signal Handling 498 | 499 | ![tshandling](images/tshandling.png) 500 | 501 | **Case 1 :** 502 | 503 | * User-Level-Thread mask = 1 504 | * Kernel-Level-Thread mask = 1 505 | 506 | ![case1](images/case1.png) 507 | 508 | **Case 2 :** 509 | 510 | * User-Level-Thread mask = 0 511 | * Kernel-Level-Thread mask = 1 512 | * another User-Level-Thread mask = 1 513 | 514 | ![case2](images/case2.png) 515 | 516 | **Case 3 :** 517 | 518 | * User-Level-Thread mask = 0 519 | * Kernel-Level-Thread mask = 1 520 | * another User-Level-Thread mask = 1 521 | * another Kernel-Level-Thread mask = 1 522 | 523 | ![case3](images/case3.png) 524 | 525 | **Case 4 :** 526 | 527 | * User-Level-Thread mask = 0 528 | * Kernel-Level-Thread mask = 1 529 | * all User-Level-Thread mask = 0 530 | 531 | ![case4](images/case4.png) 532 | 533 | **Optimize common case** 534 | 535 | - signals less frequennt than signal mask updates 536 | - system calls avoided 537 | - cheaper to update user-level mask 538 | - signal handling more expensive 539 | 540 | ## Multi-processing vs Multi-threading 541 | 542 | How to best provide concurrency? 543 | 544 | ### Multi-Processing (MP) 545 | 546 | **Advantages**
547 | 548 | * Simple programming 549 | 550 | **Disadvantages**
551 | 552 | * High memory usage 553 | * Costs context switch 554 | * costly to maintain shared state (tricky port setup) 555 | 556 | ### Multi-Threading (MP) 557 | 558 | **Advantages**
559 | 560 | * Shared address space 561 | * Shared state (no sys calls to other threads) 562 | * Cheap context switch 563 | 564 | **Disadvantages**
565 | 566 | * Complex implementation 567 | * Requires synchronization 568 | * Requires underlying support for threads 569 | 570 | ## Event Driven model 571 | 572 | ![eventdrivenmodel](images/eventdrivenmodel.png) 573 | 574 | Features: 575 | 576 | * Single address space 577 | * Single process 578 | * Single thread of control 579 | 580 | Dispatcher : acts as a state machine and accepts any external events 581 | 582 | When call handler => jump to code 583 | 584 | The handler: 585 | 586 | * Runs to completion 587 | * if they need to block 588 | - initiate blocking operation and pass control to dispatch loop 589 | 590 | ### Concurrent execution in Event-driven models 591 | 592 | - MP & MT : 1 request per execution context (process/thread) 593 | - Event Driven : Many requests interleaved in an execution context 594 | - Single thread switches among processing of different requests 595 | - Process requests until wait is necessary 596 | - then switch to another request 597 | 598 | **Advantages**
599 | 600 | * Single address space 601 | * Single flow of control 602 | * Smaller memory requirement 603 | - Event Driven model requires less memory than Boss-workers/Pipeline model, where the extra memory is required for helper thread for concurrent blocking I/O not for all concurrent requests. 604 | * No context switches 605 | * No synchronization 606 | 607 | **Disadvantages**
608 | 609 | * A blocking request/handler will block entire process 610 | 611 | ### Asynchronous I/O operations 612 | 613 | Asynchronous I/O operations fit well with Event-driven models 614 | 615 | Since asynchronous calls are not easily avalible, helpers can be used to implement the async call functionality: 616 | 617 | - designated for blocking I/O operations only 618 | - pipe/socket based communication with event dispatcher 619 | - select()/ poll() still okay 620 | - helper blocks, but main event loop (& process) will not 621 | 622 | ### Asymmetric Multi-Process Event Driven model (AMPED & AMTED) 623 | 624 | **Advantages**
625 | 626 | * Resolve portability limitations of basic event driven model 627 | * Smaller footprint than regular worker thread 628 | 629 | **Disadvantages**
630 | 631 | * Applicability to certain classes of applications 632 | * Event routing on multi CPU systems 633 | 634 | Eg [Apache Web Server](https://en.wikipedia.org/wiki/Apache_HTTP_Server) 635 | 636 | ![apachewebserver.png](images/apachewebserver.png) 637 | 638 | * Core : basic server skeleton 639 | * Modules : per functionality 640 | * Flow of Control : Similar to Event Driven model 641 | * But its an combination of MP + MT, 642 | - each process = boss/worker with dynamic thread pool 643 | - number of processes can also be dynamically adjusted 644 | 645 |
646 | -------------------------------------------------------------------------------- /4-Scheduling.md: -------------------------------------------------------------------------------- 1 | # Scheduling 2 | 3 | Operating System perform scheduling in the following simple ways: 4 | 5 | - Dispatch orders immediately 6 | - scheduling is simple FIFO (First-Come-First-Serve) 7 | - Dispatch simple orders first 8 | - maximize number of orders processed over time 9 | - maximize throughput (SJF) 10 | - Dispatch complex orders first 11 | - maximize utilization of CPU, devices, memory 12 | 13 | ## CPU Scheduler 14 | 15 | - Decides how and when process (and their threads) access shared CPUs 16 | - Schedules tasks running at user level processes/threads as well as kernel level threads 17 | - Chooses one of the ready tasks to run on CPU 18 | - Runs when 19 | - CPU becomes idle 20 | - new task becomes ready 21 | - timeslice expired timeout 22 | 23 | Context switch, enter user mode, set PC and go! <= Thread is dispatched on CPU. 24 | 25 | * Which task should be selected? 26 | - Scheduling policy/algorithm 27 | * How is this done? 28 | - Depends on runqueue data structure 29 | 30 | ### "Run-to-completion" Scheduling 31 | 32 | - Initial assumptions 33 | - group of tasks/jobs 34 | - known execution time 35 | - no preemption 36 | - single CPU 37 | - Metrics 38 | - throughput 39 | - average job completion time 40 | - average job wait time 41 | - CPU utilization 42 | 43 | ## Scheduling algorithms: 44 | 45 | ### 1. First Come First Serve (FCFS) 46 | 47 | * Schedules tasks in order of arrival 48 | 49 | ``` 50 | runqueue = queue(FIFO) 51 | ``` 52 | 53 | If T1, T2, T3 arrive in the given order and T1 has execution time 1s, T2 10s and T3 1s then : 54 | 55 | * Throughput = 3/(1+10+1) = 3/12 = 0.25s 56 | * Average completion time = (1 + 11 + 12)/3 = 8s 57 | * Average wait time = (1+1+11)/3 = 4s 58 | * Starvation NOT possible 59 | 60 | ### 2. Shortest Job First (SJF) 61 | 62 | * Schedules tasks in order of execution time 63 | * Therefore for the above example, T1(1s) > T3(1s) > T2(10s) 64 | * Starvation possible 65 | 66 | ``` 67 | runqueue = ordered(queue) 68 | 69 | //or 70 | 71 | runqueue = tree() 72 | ``` 73 | 74 | For SJF, 75 | 76 | * Throughput = 3/(1+10+1) = 3/12 = 0.25s 77 | * Average completion time = (1 + 2 + 12)/3 = 5s 78 | * Average wait time = (0+1+2)/3 = 1s 79 | 80 | ### Preemptive Scheduling 81 | 82 | * SJF + Preemption 83 | * Starvation is possible 84 | 85 | T2 arrives first. 86 | 87 | ![preemptive](images/preemptive.png) 88 | 89 | ### Priority Scheduling 90 | 91 | * Tasks have different priority levels 92 | * Run highest priority task next (preemption) 93 | * Starvation is possible 94 | 95 | ![priority](images/priority.png) 96 | 97 | ``` 98 | runqueue = per priority_queue() 99 | 100 | //or 101 | 102 | runqueue = tree() ordered on priority 103 | ``` 104 | 105 | * low priority task stuck in runqueue => starvation 106 | * "priority aging" 107 | - priority = f(actual priority, time spent in runqueue) 108 | - eventually tasks will run 109 | - prevents starvation 110 | 111 | ### 3. Round-Robin Scheduling 112 | 113 | * Pick up the first task from queue (like FCFS) 114 | * Task may yield to wait on I/O (unlike FCFCS) 115 | * Starvation is NOT possible 116 | 117 | 118 | ![rr1](images/rr1.png) 119 | 120 | ![rr2](images/rr2.png) 121 | 122 | ![rr3](images/rr3.png) 123 | 124 | ### 4. Shortest Remaining Time First (SRTF) 125 | 126 | * Chooses the process with the shortest CPU burst remaining and executes that one. If processes come in during execution that have less remaining time, the current one is preempted and the new one executed. Therefore, it can lead to starvation. 127 | 128 | #### Timeslicing 129 | 130 | * Timeslice = max amount of uninterrupted time given to a task 131 | * task may run less than timeslice 132 | - has to wait on I/O sync 133 | - will be placed on queue 134 | - higher priority task becomes runnable 135 | * using timeslice tasks are interleaved 136 | - timesharing the CPU 137 | - CPU bound tasks => preemption after timeslice 138 | 139 | ![rr4](images/rr4.png) 140 | 141 | **Advantages**
142 | 143 | * Short tasks finish sooner 144 | * More responsive 145 | * Lengthy I/O operations initiated sooner 146 | - best to keep timeslice > context-switch-time 147 | 148 | **Disdvantages**
149 | 150 | * Overheads 151 | 152 | #### How long should a timeslice be be? 153 | 154 | * should balance benefits and overheads 155 | 156 | ### For CPU bound tasks: 157 | 158 | ![cputs](images/cputs.png) 159 | 160 | * Hence, for CPU bound tasks, larger timeslice values are better 161 | 162 | ### For I/O bound tasks: 163 | 164 | ![iots](images/iots.png) 165 | 166 | * Hence, for I/O bound tasks, smaller timeslice values are better 167 | - Keeps CPU and I/P devices busy, I/O bound tasks run quickly, makes I/O requests responds to a user. 168 | 169 | ### Summary 170 | 171 | * CPU bound tasks prefer longer timeslices 172 | - limits context switching overheads 173 | - keeps CPU utilization and throughput 174 | 175 | * I/O bound tasks prefer smaller timeslices 176 | - However, if all the tasks in contention are I/O bound, it may not make such a difference 177 | - If a portion of them are I/O smaller timeslices keeps CPU and device utilization high 178 | - Provides better user-perceived performance 179 | 180 |
181 | -------------------------------------------------------------------------------- /5-Memory-Management.md: -------------------------------------------------------------------------------- 1 | # Memory Management 2 | 3 | Operating systems: 4 | 5 | - uses intelligently size containers 6 | - memory pages of segments 7 | - Not all parts are needed at once 8 | - tasks operate on subset of memory 9 | - Optimized for performance 10 | - reduce time to access state in memory 11 | - leads to better performance! 12 | 13 | ## Memory Management Goals 14 | 15 | ![mmgoals.png](images/mmgoals.png) 16 | 17 | #### Virtual vs Physical memory 18 | 19 | - Allocate 20 | - allocation, replacement 21 | - Arbitrate 22 | - address translation and validation 23 | 24 | #### Page-based Memory Management 25 | 26 | - Allocate => pages => page frames 27 | - Arbitrate => page tables 28 | 29 | #### Segment-based Memory Management 30 | 31 | - Allocate => segments 32 | - Arbitrate => segment registers 33 | 34 | 35 | ## Hardware Support 36 | 37 | ![hardwaresupport.png](images/hardwaresupport.png) 38 | 39 | ### Memory Management Unit (MMU) 40 | 41 | * translate virtual to physical address 42 | * reports faults (illegal access, permission, not present in memory) 43 | 44 | ### Registers 45 | 46 | * pointers to page tables 47 | * base and limit size, number of segments 48 | 49 | ### Cache 50 | 51 | * Translation lookaside buffer 52 | * Valid VA-PA translations using TLB 53 | 54 | ### Translation 55 | 56 | * Actual PA generation done in hardware 57 | 58 | ## Page Tables 59 | 60 | ![pagetables.png](images/pagetables.png) 61 | 62 | - OS creates page table per process 63 | - On context switch, switch to valid page table 64 | - Updates register that points to correct page table. 65 | E.g CR3 on x86 architecture 66 | 67 | ## Page Table Entry (PTE) 68 | 69 | ![pfn.png](images/pfn.png) 70 | 71 | #### Flags 72 | 73 | * Present (valid/invalid) 74 | * Dirty (written to) 75 | * Accessed (for read or write) 76 | * Protection bits => RWX 77 | 78 | ## Page Table Entry on x86 79 | 80 | ![pfnx86.png](images/pfnx86.png) 81 | 82 | #### Flags 83 | 84 | * Present 85 | * Dirty 86 | * Accessed 87 | * R/W permission bit 0: R only, 1: R/W 88 | * U/S permission bit 0: usermode, 1: superviser mode only 89 | * others: caching related info (write through, caching disabled) 90 | * unused: for future use 91 | 92 | ## Page faults 93 | 94 | ![pagefaults.png](images/pagefaults.png) 95 | 96 | ## Page Table Size 97 | 98 | ![pts.png](images/pts.png) 99 | 100 | * 32 bit architecture 101 | - Page Table Entry (PTE) = 4 Bytes, including PFN + flags 102 | - Virtual Page Number (VPN) = 2^32/page_size 103 | - Page size = 4KB (...8KB, 2MB, 4MB, 1GB) 104 | 105 | Therefore Page Table Size = (2^32 * 2^12)*4B = 4MB (per process) 106 | 107 | * for 64 bit architecture 108 | - Page Table Entry (PTE) = 8 Bytes 109 | - Page size = 4KB 110 | 111 | Page Table Size = (2^64 * 2^12)*8B = 32PB (per process!) 112 | 113 | * processes don't use entire address space 114 | * even on 32 bit architecture, it will not always use all 4GB 115 | 116 | But Page Table assumes an entry per VPN regardless, of whether corresponding virtual memory is needed or not. 117 | 118 | ## Hierarchical Page Tables 119 | 120 | ![hierarchicalpt.png](images/hierarchicalpt.png) 121 | 122 | On malloc, a new internal page table may be allocated. 123 | 124 | #### Address split: 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 |
Page Numberoffset
P1P2d
121010
142 | 143 | * inner table addresses => 2^10 * page_size = 2^10*2^10 = 1MB 144 | * don't need an inner table for each 1MB virtual memory gap 145 | 146 | Additional Layers 147 | 148 | * page table directory pointer (3rd level) 149 | * page table directory map (4th level) 150 | 151 | - Important on 64 bit architectures 152 | - larger and more sparse => larger gaps would save more internal page table components 153 | 154 | ![hierarchicalpt2.png](images/hierarchicalpt2.png) 155 | 156 | ### Tradeoffs of Multilevel Page Tables 157 | 158 | **Advantages**
159 | 160 | * Smaller internal page tables/directories 161 | * Granularity of coverage 162 | - Potentially reduced page table size 163 | 164 | **Disadvantages**
165 | 166 | * More memory accesses required for translation 167 | * increased translation latency 168 | 169 | ## Overheads of Address Translation 170 | 171 | For each memory reference : 172 | 173 | Single level page table|Four level page table 174 | ---------|----------- 175 | x1 access to PTE|x4 accesses to PTE 176 | x1 access to mem|x1 access to mem 177 | 178 | which results in slowdown. 179 | 180 | ## Page Table Cache 181 | 182 | ![ptcache.png](images/ptcache.png) 183 | 184 | #### Translation Lookaside Buffer 185 | 186 | - MMU level address translation cache 187 | - On TLB miss => page table access from memory 188 | - has protection/validity bits 189 | - small number of cached address => high TLB hit rate 190 | - temporal and spatial locality 191 | 192 | * Example 193 | - x86 Core i7 194 | - per core : 64-entry data TLB
128-entry instruction TLB 195 | - 512-entry shared second-level TLB 196 | 197 | ### Inverted Page Tables 198 | 199 | ![invertedpt.png](images/invertedpt.png) 200 | 201 | ### Hashing Page Tables 202 | 203 | ![hashingpt.png](images/hashingpt.png) 204 | 205 | ## Segmentation 206 | 207 | Segmentation is the process of mapping virtual to physical memory using segments. 208 | 209 | * Segments: arbitrary granularity (size) 210 | - e.g. code, heap, data, stack.. 211 | - address = segment - selector + offset 212 | * Segment 213 | - contiguous physical memory 214 | - segment size = segment base + limit registers 215 | 216 | ![segmentation.png](images/segmentation.png) 217 | 218 | #### Segmentation + Paging 219 | 220 | ![segmentationpaging.png](images/segmentationpaging.png) 221 | 222 | ## Page Size 223 | 224 | * 10 bit offset => 1 KB page size [2^10] 225 | * 12 bit offset => 4 KB page size [2^12] 226 | 227 | In real world examples, 228 | 229 | * Linux/x86 : 4 KB, 2MB, 1GB 230 | * Solaris/Sparse: 8kB, 4MB, 2GB 231 | 232 | ||Large|Huge| 233 | |----|-----| 234 | |page size|2 MB|1 GB| 235 | |offset bits|21 bits|30 bits| 236 | |reduction factor on page table size|x512|x1024| 237 | 238 | **Advantages**
239 | 240 | * larger pages 241 | - fewer page table entries, smaller page tables, more TLB hits 242 | 243 | **Disadvantages**
244 | 245 | * internal fragmentation => wastes memory 246 | 247 | ## Memory Allocation 248 | 249 | * Memory allocator 250 | - determines VA to PA mapping 251 | - address translation, page tables 252 | => simply determine PA from VA and check validity/permsissions 253 | 254 | * Kernel Level Allocators 255 | - kernel state, static process state 256 | * User Level Allocators 257 | - dynamic process state (heap), malloc/free 258 | - e.g. d/malloc, jemalloc, Hoard, tcmalloc 259 | 260 | ## Demand Paging 261 | 262 | * Virtual Memory >> Physical Memory 263 | - virtual memory page is not always in physical memory 264 | - physical page frame saved and restored to/from secondary storage 265 | 266 | ### Demand paging: 267 | 268 | - pages swapped in/out of memory & a swap partition (e.g. on a disk) 269 | 270 | ![demandpaging.png](images/demandpaging.png) 271 | 272 | * Original PA != PA after swapping 273 | - if page is "pinned", swapping is disabled 274 | 275 | #### When pages should be swapped? 276 | 277 | - page(out) daemon 278 | - when memory usage is above threshold 279 | - when CPU usage is below threshold 280 | 281 | #### Which page should be swapped out? 282 | 283 | - pages that won't be used 284 | - history based prediction 285 | - Least Recently Used (LRU policy). Access bit tracks if page is referenced. 286 | - page that don't need to be written out 287 | - Dirty bit to track if modified 288 | - avoid non-swappable pages 289 | 290 | ## Checkpointing 291 | 292 | * Failure and Recovery management technique 293 | - periodically save process state 294 | - failure may be unavoidable but can restart from checkpoint, so recovery would be faster 295 | 296 | #### Simple Approach 297 | 298 | - pause and save 299 | 300 | #### Better Approach 301 | 302 | - write-protect and copy everything at once 303 | - copy diffs of dirties pages for incremental checkpoints 304 | - rebuild from multiple diffs, or in background 305 | 306 | Checkpointing can also be used in other services: 307 | 308 | * Debugging 309 | - Rewind-Replay 310 | - rewind = restart from checkpoint 311 | - gradually go back to earlier checkpoints until error is found 312 | 313 | * Migration 314 | - continue on another machine 315 | - disaster recovery 316 | - consolidation 317 | - repeated checkpoints in a fast loop until pause and copy becomes acceptable (or unavoidable) 318 | 319 |
-------------------------------------------------------------------------------- /6-Inter-Process-Communication.md: -------------------------------------------------------------------------------- 1 | # Inter Process Communication 2 | 3 | - Processes share memory 4 | - data in shared messages 5 | - Processes exchange messages 6 | - message passing via sockets 7 | - Requires synchronization 8 | - mutex, waiting 9 | 10 | **Inter Process Communication**(IPC) is an OS supported mechanism for interaction among processes (coordination and communication) 11 | 12 | - Message Passing 13 | - e.g. sockets, pips, msgs, queues 14 | - Memory based IPC 15 | - shared memory, memory mapped files 16 | - Higher level semantics 17 | - files, [RPC](10-Remote-Procedure-Calls.md) 18 | - Synchronization primitives 19 | 20 | ## Message Passing 21 | 22 | * Send/Receive messages 23 | * OS creates and maintains a channel 24 | - buffer, FIFO queue 25 | * OS provides interfaces to processes 26 | - a port 27 | - processes send/write messages to this port 28 | - processes receive/read messages from this port 29 | 30 | ![messagepassingipc.png](images/messagepassingipc.png) 31 | 32 | * Kernel required to 33 | - establish communication 34 | - perform each IPC operation 35 | - send: system call + data copy 36 | - receive: system call + data copy 37 | * Request-response: 38 | 4x user/ kernel crossings +
39 | 4x data copies 40 | 41 | **Advantages**
42 | 43 | * simplicity : kernel does channel management and synchronization 44 | 45 | **Disadvantages**
46 | 47 | * Overheads 48 | 49 | ### Forms of Message Passing IPC 50 | 51 | #### 1. Pipes 52 | 53 | - Carry byte stream between 2 process 54 | - e.g connect output from 1 process to input of another 55 | 56 | ![pipes.png](images/pipes.png) 57 | 58 | #### 2. Message queues 59 | 60 | - Carry "messages" among processes 61 | - OS management includes priorities, scheduling of message delivery 62 | - APIs : Sys-V and POSIX 63 | 64 | ![msgq.png](images/msgq.png) 65 | 66 | #### 3. Sockets 67 | 68 | - send() and recv() : pass message buffers 69 | - socket() : create kernel level socket buffer 70 | - associated neccessary kernel processing (TCP-IP,..) 71 | - If different machines, channel between processes and network devices 72 | - If same machine, bypass full protocol stack 73 | 74 | ![sockets.png](images/sockets.png) 75 | 76 | ## Shared Memory IPC 77 | 78 | * read and write to shared memory region 79 | * OS establishes shared channel between the processes 80 | 1. physical pages mapped into virtual address space 81 | 2. VA(P1) and VA(P2) map to same physical address 82 | 3. VA(P1) != VA(P2) 83 | 4. physical mempry doesn't need to be contiguous 84 | * APIs : SysV, POSIX, memory mapped files, Android ashmem 85 | 86 | ![sharedmemoryipc.png](images/sharedmemoryipc.png) 87 | 88 | **Advantages**
89 | 90 | * System calls only for setup data copies potentially reduced (but not eliminated) 91 | 92 | **Disdvantages**
93 | 94 | * explicit synchronization 95 | * communication protocol, shared buffer management 96 | - programmer's responsibility 97 | 98 | ## Which is better? 99 | 100 | **Overheads for** 101 | 1. Message Passing : must perform multiple copies 102 | 2. Shared Memory : must establish all mappings among processes' address space and shared memory pages 103 | 104 | Thus, it depends. 105 | 106 | ## Copy vs Map 107 | 108 | Goal for both is to transfer data from one into target saddress space 109 | 110 | Copy (Message Passing) | Map (Shared Memory) 111 | ----------------|----------------- 112 | CPU cycles to copy data to/from port | CPU cycles to map memory into address space 113 | |CPU to copy data to channel 114 | |If channel setup once, use many times (good payoff) 115 | |Can perform well for 1 time use 116 | 117 | * Large Data: t(Copy) >> t(Map) 118 | - e.g. tradeoff exercised in Window "Local" Procedure Calls (LPC) 119 | 120 | ## Shared Memory and Synchronization 121 | 122 | Use threads accessing shared state in a single addressing space, but for process 123 | 124 | Synchronization method: 125 | 126 | 1. mechanism supported by processing threading library (pthreads) 127 | 2. OS supported IPC for sync 128 | 129 | Either method must coordinate 130 | 131 | * no of concurrent access to shared segment 132 | * when data is available and ready for consumption 133 | 134 | ### IPC Synchronization 135 | 136 | Message Queues| Semaphores 137 | -------------|------------- 138 | Implement "mutual exclusion" via send/receive | OS supported synchronization construct 139 | |binary construct (either allow process or not) 140 | |Like mutex, if value = 0, stop; if value = 1, decrement(lock) and proceed 141 | 142 |
143 | -------------------------------------------------------------------------------- /7-Synchronization.md: -------------------------------------------------------------------------------- 1 | # Synchronization 2 | 3 | Waiting for other processes, so that they can continue working together 4 | 5 | - may repeatedly check to continue 6 | - sync using spinlocks 7 | - may wait for a signal to continue 8 | - sync using mutexes and condition vatiables 9 | - waiting hurts performance 10 | - CPUs wste cycles for checking; cache effects 11 | 12 | ## Limitation of mutextes and condition variables 13 | 14 | - Error prone/correctness/ease of use 15 | - unlock wrong mutex, signal wrong condition variable 16 | - Lack of expressive power 17 | - helper variables for access or priority control 18 | 19 | Low-level support: hardware atmoic instructions 20 | 21 | ## Synchronization constructs 22 | 23 | 1. Spinlocks (basic sync construct) 24 | - Spinlock is like a mutex 25 | - mutual exclusion 26 | - lock and unlock(free) 27 | - but, lock == busy => spinning 28 | 2. Semaphores 29 | - common sync construct in OS kernels 30 | - like a traffic light: Stop and Go 31 | - like mutex, but more general 32 | 33 | Semaphore == integer value 34 | 35 | * on init 36 | - assigned a max value (positive int) => max count 37 | * on try(wait) 38 | - if non-zero, decrement and proceed => counting semaphore 39 | * if initialized with 1 40 | - semaphore == mutex(binary semaphore) 41 | * on exit(post) 42 | - increment 43 | 44 | ## Syncing different types of accesses 45 | 46 | ### Reader/Writer locks 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 |
read (don't modify)write (always modify)
shared accessexclusive access
58 | 59 | * RW locks 60 | - specify type of access, then lock behaves accordingly 61 | 62 | ### Monitors (highlevel construct) 63 | - shared resource 64 | - entry resource 65 | - possible condition variables 66 | * On entry: 67 | - lock, check 68 | * On exit: 69 | - unlock, check, signal 70 | 71 | ### More synchroniaztion constructs 72 | * serializers 73 | * path expressions 74 | * barriers 75 | * rendezvous points 76 | * optimistic wait-free sync (RCU) [Read Copy Update] 77 | 78 | All need hardware support. 79 | 80 | ## Need for hardware support 81 | 82 | - Problem 83 | - concurrent check/update on different CPUs can overlap 84 | 85 | ### Atomic instructions 86 | Critical section with hardware supported synchronization 87 | 88 | #### Hardware specific 89 | * test-and-set 90 | - returns(tests) original values and sets new-value!= 1 (busy) automatically 91 | - first thread: test-and-set(lock) => 0 : free 92 | - next ones: test-and-set(lock) => 1 busy 93 | - reset lock to 1, but that's okay 94 | - **\+** : Latency 95 | - **\+** : minimal (Atomic) 96 | - **\+** : Delay potentially min 97 | - **\-** : Contention processors go to memory on each spin 98 | - To reduce contention, introduce delay 99 | - Static(based on a fixed value) or Dynamic(backoff based, random delay) 100 | 101 | 102 | * read-and-increment 103 | * compare-and-swap 104 | 105 | #### Guarantees 106 | * atomicity 107 | * mutual exclusion 108 | * queue all concurrent instructions but one 109 | 110 | 111 | ### Shared Memory Multiprocessors 112 | 113 | Also called symmetric multiprocessors (SMP) 114 | 115 | ![sharedmmmp](images/sharedmmmp.png) 116 | 117 | * Caches 118 | - hide memory latency, "memory" further away due to contention 119 | - no-write, write-through, write-back 120 | 121 | ### Cache Coherence 122 | 123 | ![cachecoherence](images/cachecoherence.png) 124 | 125 | ![cachecoherence2](images/cachecoherence2.png) 126 | 127 |
128 | 129 | 130 | 131 | 132 | -------------------------------------------------------------------------------- /8-IO-Management.md: -------------------------------------------------------------------------------- 1 | # I/O Management 2 | 3 | Operating system 4 | 5 | - Has protocols 6 | - Interfaces for device I/O 7 | - Has dedicated handlers 8 | - Device drivers, interrupt handlers 9 | - Decouple I/O details from core processing 10 | - abstract I/O device detail from applications 11 | 12 | ## I/O Device Features 13 | 14 | - Control registers (accessed by CPU) 15 | - Command 16 | - Data Transfers 17 | - Status 18 | - Microcontroller : device's CPU 19 | - On device memory 20 | - Other logic 21 | - e.g. analog to digital 22 | 23 | ## Device drivers 24 | 25 | - per each device type 26 | - responsible for device access management and control 27 | - provided by device manufacturers per OS /version 28 | - each OS standardizes interfaces 29 | - device independence 30 | - device diversity 31 | 32 | ## Types of devices 33 | 34 | - Block 35 | - e.g. disk 36 | - read/write blocks of data 37 | - direct access to arbitrary block 38 | - Character 39 | - e.g. keyboard 40 | - get/put character 41 | - Network devices 42 | 43 | OS representation of a device : special device file 44 | 45 | UNIX like systems: 46 | 47 | * /dev 48 | * tmpfs 49 | * devfs 50 | 51 | Linux supports a number of pseudo "virtual" devices that provide special functionality to a system. 52 | 53 | ## CPU device interactions 54 | 55 | ![iointeractions.png](images/iointeractions.png) 56 | 57 | access device registers : memory load/store 58 | 59 | 1. Memory mapped I/0 60 | - part of 'host' physical memory dedicated for device interactions 61 | - Base Address Registers (BAR) 62 | 2. I/O Port 63 | - dedicated in low instructions for device access 64 | - target device (I/0 port) and value in register 65 | 66 | ## Path from Device to CPU 67 | 68 | 1. Interrupt 69 | - Overhead: Interrupt handling steps 70 | - \+: Can be generated as soon as possible 71 | 2. Polling 72 | - Overhead: Delay or CPU overhead 73 | - when convenient for OS 74 | 75 | ## Device access : Programmed I/O (PIO) 76 | 77 | - No additional hardware support 78 | - CPU "programs" the device 79 | - via command registers 80 | - data movement 81 | - E.g. NIC(Network Interface Card) 82 | - data = network packet 83 | - Write command to request packet information 84 | - Copy packet to data registers 85 | - Repeat until packet sent 86 | 87 | E.g. 1500B packet; 8 byte registers or bus => 1(for bus command) + 188(for data) = 189 CPU store instructions 88 | 89 | ## Direct Memory Access (DMA) 90 | 91 | - Relies on DMA controller 92 | - CPU "programs" the device 93 | - via command registers 94 | - via DMA controls 95 | - E.g. NIC (data = network packet) 96 | - Write command to request packet information 97 | - Configure DMA controller with in memory address and size of packet buffer 98 | 99 | E.g. 1500B packet; 8 byte registers or bus => 1(for bus command) + 1(for DMA configuration) = total 2 CPU store instructions. Less steps, but DMA configuration is more complex. 100 | 101 | For DMAs 102 | - data buffer must be in physical memory until transfer completes 103 | - pinning regions (non-swappable) 104 | 105 | ## Typical Device Access 106 | 107 | ![typicaldeviceaccess.png](images/typicaldeviceaccess.png) 108 | 109 | - System call 110 | - In-kernel stack 111 | - Driver Invocation 112 | - Device request configuration 113 | - Device performs request 114 | 115 | ### OS bypass 116 | 117 | ![osbypass.png](images/osbypass.png) 118 | 119 | - device registers/data 120 | - directly available 121 | - OS configures 122 | - then gets out of the way 123 | - "user level driver" 124 | - in library 125 | - OS retains coarse-grain control 126 | - relies on device features 127 | - sufficient registers 128 | - demux capability 129 | 130 | ## What happens to a calling thread? 131 | 132 | ![access.png](images/access.png) 133 | 134 | * Synchronous I/O operations 135 | - process blocks 136 | * Asynchronous I/O operations 137 | - process continues 138 | - Later, process checks and retrieves result 139 | - OR 140 | - process is notified that operation is completed and results are ready 141 | 142 | ## Block Device Stack 143 | 144 | Block device typical storage for files: 145 | 146 | ![blockdevicestack.png](images/blockdevicestack.png) 147 | 148 | - processes use files => logical storage unit 149 | - kernel file system (KFS) 150 | - where how to find and access file 151 | - OS specifies interface 152 | - generic block layer 153 | - OS standardized block interface 154 | - Device driver 155 | 156 | ## Virtual File System 157 | 158 | ![vfs.png](images/vfs.png) 159 | 160 | ### Virtual File System Abstractions 161 | 162 | * File : Elements on which the VFS operates 163 | * File Descriptor : OS representation of file 164 | - open, read, write, send file , lock, close 165 | * inode : Persistent representation of file "index" 166 | - list of all data blocks 167 | - device, permissions, size 168 | * dentry : Directory entry, corresponding to the single path component, 169 | - dentry cache 170 | * super block : file system specific information regarding the File System layout 171 | 172 | ### VFS on disk 173 | 174 | * File : data blocks on disk 175 | * inode : track file blocks 176 | - also resides on disk in some block 177 | * super block : overall map of disk blocks 178 | - inode blocks 179 | - data blocks 180 | - free blocks 181 | 182 | ### Inodes 183 | 184 | Index of all disk blocks corresponding to a file 185 | 186 | * File : identified by inode 187 | * inode : list of all blocks + other metadata 188 | 189 | **\+**: Easy to perform sequential or random access
190 | **\-**: Limit on file size 191 | 192 | ### Inodes with indirect pointers 193 | 194 | * Index of all disk blocks corresponding to a file 195 | * Index contain: 196 | - metadata 197 | - pointers to blocks 198 | * Direct pointer : Points to data block 199 | - 1 KB per entry 200 | * Indirect pointer : Points to block of pointers 201 | - 256 KB per entry 202 | * Double Indirect pointer : Points to block of block of pointers 203 | - 64 MB per entry 204 | 205 | **\+**: Small inode => large file size
206 | **\-**: File access slowdown 207 | 208 | ## Disk access optimizations 209 | 210 | Reducing file access overheads 211 | 212 | 1. Caching/buffering : reducenumber of disk accesses 213 | - buffer cache in main menu 214 | - read/write from cache 215 | - periodically flush to disk - fsync() 216 | 2. I/O scheduling : reduce disk head movement 217 | - maximize sequential vs random access 218 | 3. Prefetching : increases cache hits 219 | - leverages locality 220 | 4. Journaling/logging: reduce random access (ext3, ext4) 221 | - "describe" write in log : block, offset, value.. 222 | - periodically apply updates to proper disk locations 223 | 224 |
225 | 226 | 227 | 228 | 229 | 230 | 231 | 232 | 233 | 234 | 235 | -------------------------------------------------------------------------------- /9-Virtualization.md: -------------------------------------------------------------------------------- 1 | # Virtualization 2 | 3 | Virtualization allows concurrent execution of multiple OSs and their applications on the same physical machine. 4 | 5 | ![virtualization.png](images/virtualization.png) 6 | 7 | * Virtual resources : each OS thinks that ot "owns" hardware resources 8 | * Virtual machine (VM) : OS + applications + virtual resources (guest domain) 9 | * Virtualization layer : management of physical hardware (virtual machine monitor, hypervisor) 10 | 11 | ## Defining Virtual Machine 12 | 13 | A Virtual Machine is an efficient, isolated duplicate of the real machine. 14 | 15 | * Supported by a Virtual Machine Monitor (VMM): 16 | 1. provides environment essentially identical with the original machine 17 | 2. programs show only minor decrease in speed at worst 18 | 3. VMM is in complete control of the system resources 19 | 20 | ## VMM goals 21 | 22 | * Fidelity 23 | * Performance 24 | * Safety and Isolation 25 | 26 | ## Virtualization advantages 27 | 28 | * consolidation 29 | - decrease cost, improve manageability 30 | * migration 31 | - availibility, reliability 32 | * security, debugging, support for legacy OS 33 | 34 | ## Two main Virtualization Models: 35 | 36 | ### 1. Bare-metal or Hypervisor based (Type 1) 37 | 38 | ![hypervisor.png](images/hypervisor.png) 39 | 40 | * VMM (hypervisor) manages all hardware resources abd supports execution of VMs 41 | * privileged, secure VM to deal with devices (and other configuration and management tasks) 42 | * Adopted by Xen(Opensource or Citriol Xen Server) and ESX (VMware) 43 | 44 | ### 1. Hosted (Type 2) 45 | 46 | ![hosted.png](images/hosted.png) 47 | 48 | * Host owns all hardware 49 | * Special VMM modle provides hardware interfaces to VMs and deals with VM context switching 50 | 51 | ## Virtualization requirements 52 | 53 | * Present virtual platform interface to VMs 54 | - virtualize CPU, memory, devices 55 | * Provide isolation across VMs 56 | - preemption, MMU for address translation and validation 57 | * Protect guest OS from applications 58 | - can't run guest OS and applications at same protection level 59 | * Protect VMs from guest OS 60 | - can't run guest OS and VMMs at same protection level 61 | 62 | ## Hardware protection levels 63 | 64 | Commodity hardware has more than two protection levels 65 | 66 | ![hwprotectionlevels](images/hwprotectionlevels.png) 67 | 68 | * x86 has 4 protection levels (rings) 69 | - ring 3 : lowest privilege (applications) 70 | - ring 1 : OS 71 | - ring 0 : highest privilege (hypervisor) 72 | * and 2 protection modes 73 | - non root : VMs 74 | - ring 3 : apps 75 | - ring 0 : OS 76 | - root : 77 | - ring 0 : hypervisor 78 | 79 | ## Process Virtualization (Trap-and-Emulate) 80 | 81 | - Guest instruments 82 | - executed directly by hardware 83 | - for non-privileged operations : hardware speeds => efficiency 84 | - for privileged operations : trap to hypervisor 85 | - Hypervisor determines what needs to be done: 86 | - if illegal operation : terminate VM 87 | - if legal operation : emulate the behaviour the guest OS was expecting from the hardware 88 | 89 | ## Problems with Trap-and-Emulate 90 | 91 | - 17 privileged information do not trao but fail silently 92 | - Hypervisor doesn't know, so it doesn't try to change settings 93 | - OS doesn't know, so assumes change was successful 94 | 95 | ## Binary Translation 96 | 97 | **Goal** : Full Virtualization i.e. guest OS is not modified 98 | 99 | **Approach** : Dynamic Binary Translation 100 | 101 | 1. Inspect code blocks to be executed 102 | 2. If needed, translate to alternate instruction sequence 103 | - e.g. to emulate desired behaviour, possibly avoid traps 104 | 3. Otherwise run at hardware speeds 105 | - cache translated blocks to ammortize translation costs 106 | 107 | ## Paravirtualization 108 | 109 | **Goal** : Performance; give up on modified guest OSs 110 | 111 | **Approach** : Paravirtualization : modify guest OSs so that 112 | 113 | - it knows it is running virtualized 114 | - it makes explicit calls to hyperisor (hypercalls) 115 | - hypercalls (~ system calls) 116 | - package context information 117 | - specify desired hypercall 118 | - trap to VMM 119 | - Xen : opensource hypervisor 120 | 121 | ## Memory virtualization 122 | 123 | * Full virtualization 124 | - all guests expect contiguous physical memory starting at 0 125 | - virtual vs physical vs machine addresses and page frame numbers 126 | - still leverages hardware (MMU, TLB..) 127 | * Option 1 128 | - guest page table : VA => PA 129 | - hypervisor : PA => MA 130 | - too expensive! 131 | * Option 2 132 | - guest page tables : VA => PA 133 | - hypervisor shadow PT : VA => MA 134 | - hypervisor maintains consistence 135 | - e.g. invalidate on context switch, write protect guest PT to track new mappings 136 | * Paravirtualized 137 | - guest aware of virtualization 138 | - no longer strict requirement on contiguous physical memory starting at 0 139 | - explicitly registers page tables with hypervisor 140 | - can "batch" page tables updates to reduce VM exits 141 | - other optimazations 142 | 143 | Overheads eliminated or reduced on newer platforms 144 | 145 | ## Device Virtualization 146 | 147 | * For CPUs and Memory 148 | - less diversity, Intruction-Set-Architecture(ISA) level 149 | - Standardization of interface 150 | * For Devices 151 | - high diversity 152 | - lack of standard specification of device interface and behaviour 153 | 154 | #### 3 key models for Device Virtualization: 155 | 156 | ### 1. Pass through model 157 | 158 | Approach: VMM-level-driver configures device access permissions 159 | 160 | ![passthrough.png](images/passthrough.png) 161 | 162 | **Advantages**
163 | 164 | * VM provided with exclusive and direct (VMM bypass) access to the device 165 | 166 | **Disadvantages**
167 | 168 | * Device sharing difficult 169 | * VMM must have exact type of device as what VM expects 170 | * VM migration tricky 171 | 172 | ### 2. Hypervisor - Direct model 173 | 174 | Approach: 175 | 176 | - VMM interrupts all device accesses 177 | - Emulate device operations 178 | - translate to generic I/O operations 179 | - traverse VMM-resident I/O stack 180 | - invoke VMM-resident driver 181 | 182 | ![hypervisordirect.png](images/hypervisordirect.png) 183 | 184 | **Advantages**
185 | 186 | * VM decoupled from physical device 187 | * Sharing, migration, dealing with device specifics 188 | 189 | **Disadvantages**
190 | 191 | * Latency of device operations 192 | * Device driver ecosystem complexities in Hypervisor 193 | 194 | ### 3. Split Device-Driver model 195 | 196 | Approach: 197 | 198 | - Device access control split between 199 | - Emulate device operations 200 | - front-end driver in guest VM (device API) 201 | - back-end driver in service VM (or Host) 202 | - modified guest drivers 203 | - i.e. limited to paravirtualized guests 204 | 205 | ![splitdevicedriver.png](images/splitdevicedriver.png) 206 | 207 | **Advantages**
208 | 209 | * Eliminate emulation overhead 210 | * Allow for better management of shared devices 211 | 212 |
213 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 |
2 | 3 | # :books: Operating Systems Notes 4 | 5 | This repository contains documentation regarding all the important OS concepts and notes taken down by me while undertaking the Operating Systems course at my undergraduate school and also the [Introduction to Operating Systems](https://www.udacity.com/course/introduction-to-operating-systems--ud923) course at Udacity. The repo contains summarized information and key points regarding the main OS concepts. 6 | 7 | You can use these notes as references to quickly revise the basic fundamentals of Operating Systems. 8 | 9 |
10 | 11 | The notes cover the following concepts: 12 | 13 | 14 | |Operating System Concepts:| 15 | |--------------------------------------| 16 | |[1: Operating Systems Overview](1-Overview.md)| 17 | |[2: Processes and Process Management](2-Process-Management.md)| 18 | |[3: Threads and Concurrency](3-Threads-and-Concurrency.md)| 19 | |[4: Scheduling](4-Scheduling.md)| 20 | |[5: Memory Management](5-Memory-Management.md)| 21 | |[6: Inter-Process Communication](6-Inter-Process-Communication.md)| 22 | |[7: Synchronization](7-Synchronization.md)| 23 | |[8: I/O Management](8-IO-Management.md)| 24 | |[9: Virtualization](9-Virtualization.md)| 25 | |[10: Remote Procedure Calls](10-Remote-Procedure-Calls.md)| 26 | |[11: Distributed File Systems](11-Distributed-File-Systems.md)| 27 | |[12: Distributed Shared Memory](12-Distributed-Shared-Systems.md)| 28 | 29 | 30 | ## References : 31 | 32 | * [Introduction to Operating Systems](https://www.udacity.com/course/introduction-to-operating-systems--ud923) course at Udacity. 33 | * OS course at my undergraduate university. 34 | * Operating System Concepts by Silberschatz, Galvin and Gagne, 9th Edition Textbook. 35 | 36 |
37 | 38 | Contributions are most welcome! :) 39 | 40 |
41 | -------------------------------------------------------------------------------- /images/README.md: -------------------------------------------------------------------------------- 1 | # Image References : 2 | 3 | The images in the documentation are taken from the [Introduction to Operating Systems](https://www.udacity.com/course/introduction-to-operating-systems--ud923) course at Udacity as screenshots so as to improve the notes and also provide visual aid to understand the concepts quickly and effectively. 4 | 5 | 6 |
-------------------------------------------------------------------------------- /images/access.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/access.png -------------------------------------------------------------------------------- /images/apachewebserver.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/apachewebserver.png -------------------------------------------------------------------------------- /images/blockdevicestack.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/blockdevicestack.png -------------------------------------------------------------------------------- /images/cachecoherence.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/cachecoherence.png -------------------------------------------------------------------------------- /images/cachecoherence2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/cachecoherence2.png -------------------------------------------------------------------------------- /images/cachingstate.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/cachingstate.png -------------------------------------------------------------------------------- /images/case1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/case1.png -------------------------------------------------------------------------------- /images/case2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/case2.png -------------------------------------------------------------------------------- /images/case3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/case3.png -------------------------------------------------------------------------------- /images/case4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/case4.png -------------------------------------------------------------------------------- /images/causal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/causal.png -------------------------------------------------------------------------------- /images/cputs.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/cputs.png -------------------------------------------------------------------------------- /images/deadlock.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/deadlock.png -------------------------------------------------------------------------------- /images/demandpaging.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/demandpaging.png -------------------------------------------------------------------------------- /images/disableis.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/disableis.png -------------------------------------------------------------------------------- /images/eventdrivenmodel.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/eventdrivenmodel.png -------------------------------------------------------------------------------- /images/extremes.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/extremes.png -------------------------------------------------------------------------------- /images/extremes2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/extremes2.png -------------------------------------------------------------------------------- /images/hardwaresupport.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/hardwaresupport.png -------------------------------------------------------------------------------- /images/hashingpt.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/hashingpt.png -------------------------------------------------------------------------------- /images/hierarchicalpt.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/hierarchicalpt.png -------------------------------------------------------------------------------- /images/hierarchicalpt2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/hierarchicalpt2.png -------------------------------------------------------------------------------- /images/hosted.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/hosted.png -------------------------------------------------------------------------------- /images/howpcbisused.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/howpcbisused.png -------------------------------------------------------------------------------- /images/hwprotectionlevels.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/hwprotectionlevels.png -------------------------------------------------------------------------------- /images/hypervisor.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/hypervisor.png -------------------------------------------------------------------------------- /images/hypervisordirect.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/hypervisordirect.png -------------------------------------------------------------------------------- /images/interrupts.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/interrupts.png -------------------------------------------------------------------------------- /images/interruptsasthreads.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/interruptsasthreads.png -------------------------------------------------------------------------------- /images/invertedpt.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/invertedpt.png -------------------------------------------------------------------------------- /images/io.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/io.png -------------------------------------------------------------------------------- /images/iointeractions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/iointeractions.png -------------------------------------------------------------------------------- /images/iots.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/iots.png -------------------------------------------------------------------------------- /images/kernelvuserthread.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/kernelvuserthread.png -------------------------------------------------------------------------------- /images/linuxarch.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/linuxarch.png -------------------------------------------------------------------------------- /images/manytomany.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/manytomany.png -------------------------------------------------------------------------------- /images/manytoone.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/manytoone.png -------------------------------------------------------------------------------- /images/marshalling.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/marshalling.png -------------------------------------------------------------------------------- /images/messagepassing.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/messagepassing.png -------------------------------------------------------------------------------- /images/messagepassingipc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/messagepassingipc.png -------------------------------------------------------------------------------- /images/metadata.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/metadata.png -------------------------------------------------------------------------------- /images/mmgoals.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/mmgoals.png -------------------------------------------------------------------------------- /images/msgq.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/msgq.png -------------------------------------------------------------------------------- /images/mutex.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/mutex.png -------------------------------------------------------------------------------- /images/notation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/notation.png -------------------------------------------------------------------------------- /images/onetoone.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/onetoone.png -------------------------------------------------------------------------------- /images/osbypass.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/osbypass.png -------------------------------------------------------------------------------- /images/pagefaults.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/pagefaults.png -------------------------------------------------------------------------------- /images/pagetables.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/pagetables.png -------------------------------------------------------------------------------- /images/passthrough.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/passthrough.png -------------------------------------------------------------------------------- /images/pcb.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/pcb.png -------------------------------------------------------------------------------- /images/pfn.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/pfn.png -------------------------------------------------------------------------------- /images/pfnx86.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/pfnx86.png -------------------------------------------------------------------------------- /images/pipes.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/pipes.png -------------------------------------------------------------------------------- /images/preemptive.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/preemptive.png -------------------------------------------------------------------------------- /images/priority.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/priority.png -------------------------------------------------------------------------------- /images/process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/process.png -------------------------------------------------------------------------------- /images/processlifecycle.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/processlifecycle.png -------------------------------------------------------------------------------- /images/processvthread.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/processvthread.png -------------------------------------------------------------------------------- /images/producerconsumer.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/producerconsumer.png -------------------------------------------------------------------------------- /images/ptcache.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/ptcache.png -------------------------------------------------------------------------------- /images/pts.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/pts.png -------------------------------------------------------------------------------- /images/rpcrequirements.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/rpcrequirements.png -------------------------------------------------------------------------------- /images/rpcstructure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/rpcstructure.png -------------------------------------------------------------------------------- /images/rr1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/rr1.png -------------------------------------------------------------------------------- /images/rr2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/rr2.png -------------------------------------------------------------------------------- /images/rr3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/rr3.png -------------------------------------------------------------------------------- /images/rr4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/rr4.png -------------------------------------------------------------------------------- /images/segmentation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/segmentation.png -------------------------------------------------------------------------------- /images/segmentationpaging.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/segmentationpaging.png -------------------------------------------------------------------------------- /images/seq.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/seq.png -------------------------------------------------------------------------------- /images/sharedmemory.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/sharedmemory.png -------------------------------------------------------------------------------- /images/sharedmemoryipc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/sharedmemoryipc.png -------------------------------------------------------------------------------- /images/sharedmmmp.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/sharedmmmp.png -------------------------------------------------------------------------------- /images/signals.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/signals.png -------------------------------------------------------------------------------- /images/sockets.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/sockets.png -------------------------------------------------------------------------------- /images/splitdevicedriver.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/splitdevicedriver.png -------------------------------------------------------------------------------- /images/strict.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/strict.png -------------------------------------------------------------------------------- /images/systemcallflowchart.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/systemcallflowchart.png -------------------------------------------------------------------------------- /images/threadds.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/threadds.png -------------------------------------------------------------------------------- /images/timeslice.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/timeslice.png -------------------------------------------------------------------------------- /images/tshandling.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/tshandling.png -------------------------------------------------------------------------------- /images/typicaldeviceaccess.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/typicaldeviceaccess.png -------------------------------------------------------------------------------- /images/unmarshalling.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/unmarshalling.png -------------------------------------------------------------------------------- /images/userkernelprotectionboundary.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/userkernelprotectionboundary.png -------------------------------------------------------------------------------- /images/userlevelvkernellevel.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/userlevelvkernellevel.png -------------------------------------------------------------------------------- /images/vfs.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/vfs.png -------------------------------------------------------------------------------- /images/virtualization.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/virtualization.png -------------------------------------------------------------------------------- /images/weak.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Aniruddha-Tapas/Operating-Systems-Notes/987ea134dfc6cb1b8ab9b6efec359f92865940f9/images/weak.png --------------------------------------------------------------------------------